New tcl-8.5 and 8Kingdoms
Hans de Goede
j.w.r.degoede at hhs.nl
Mon Jan 7 21:54:41 UTC 2008
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
More information about the devel
mailing list