New tcl-8.5 and 8Kingdoms

Michael Thomas wart at kobold.org
Mon Jan 7 21:44:59 UTC 2008


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




More information about the fedora-devel-list mailing list