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