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

Re: New tcl-8.5 and 8Kingdoms



Wart wrote:
Hans de Goede wrote:
Michael Thomas wrote:
Did you have to make any changes to 8Kingdoms to get it to build with
Tcl 8.5?  If so please pass along any patches.  I'll try building and
running it myself to see if I can track down the problem.

Nope,

No changes, I also did a diff between the buildlogs, no new compiler
warnings or anything like that.

I did build it with gcc-4.3, as I was working on it not building with
gcc-4.3 too.

I've just committed my latest 8Kingdoms work to cvs, so you can get it
from there, including a patch for the crash you reported (tested using
tcl 8.4).

It looks like it's a result of the stack checking code in the Tcl
library itself.  Turning off the stack checking code by compiling Tcl
with -DTCL_NO_STACK_CHECK=1 makes the problem in 8Kingdoms go away.

With the stack checking turned on, the Tcl scripts in 8Kingdoms fail
with the error "out of stack space (infinite loop?)".  This error is
generated by the stack checking code in tclBasic.c line 3439.

I don't understand enough of this stack checking stuff to debug it any
further, unfortunately.



Okay,

I've investigated this a bit more and the conclusion is simple, disable the completely broken stack checking please.

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 don't know what dinosaur wrote that code, but with things like address randomization, threads (and thus multiple stacks in one address space) etc, the assumptions of the stack checking don't hold foot. Also an any protected mode os, the os should disallow the stack to grow into already allocated memory and the check thus is useless. This will only work in things like dos / embedded systems without much of an OS.

Also someone please educate upstream about the dumbness of this code.

Problem solved, just disable the check, _really_

Regards,

Hans



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