New tcl-8.5 and 8Kingdoms

[Hans de Goede]

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