[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: New tcl-8.5 and 8Kingdoms

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)



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]