Michael Thomas wrote:
Hans de Goede wrote:
Michael Thomas wrote:
Marcela Maslanova wrote:
I've rebuilt tcl without stack checking. Please try rebuild 8Kingdoms.
I don't think 8Kingdoms needs to be rebuilt to get the fix. It
should get the fix automatically since it's dynamically linked with
the tcl shared library.
TCL upstream has been in contact with me and I have to rectify my
statement about the badness of the code, it still doesn't work with
8Kingdoms, but my initial assesment was wrong, to be precise I take back:
"The stack checking code works by comparing a pointer returned from
malloc with that of an address from a variable in the current stack
frame, assuming that if if stackaddress < heapaddress (on
architectures where the stack grows down) that the stack has grown
into the heap."
I read the TCL stack checking code as "(localIntPtr) < (iPtr)", where
it clearly reads: "(localIntPtr) < (iPtr)->stackBound", completely my
bad! I also take the dinosaur back, I assumed (by my misreading) the
code was trying to determine wether the stack had grown into the heap,
which would only work on really old platforms hence the dinosaur
reference. I'll be spending some time next properly debugging this and
trying to find out whats really going amiss.
Here are some first clue's I've added a simple printf to
TclInterpReady(), which on 8Kingdoms startup prints (lots of times):
stackbound: 0x7fffb4db2244, localint: 0x7fffb57a7564
But then I get:
stackbound: 0x7fffb4db2244, localint: 0x43c04a14
out of stack space (infinite loop?)
Notice how the actualstack is Tera bytes away from the determined
stackbound (this is a 64 bit system, so yes those are real/correct
addresses)
Could this be some problem with interaction with threads? I noticed the
'out of stack space' error first occur as soon as 8Kingdoms launched a
new thread.
Yes, it most likely is, still busy investigating ...
Regards,
Hans
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
