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.
--Mike
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
