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