FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 01-06-2008, 02:34 PM
Hans de Goede
 
Default 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


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-07-2008, 09:42 AM
Marcela Maslanova
 
Default New tcl-8.5 and 8Kingdoms

I've rebuilt tcl without stack checking. Please try rebuild 8Kingdoms.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-07-2008, 07:45 PM
Michael Thomas
 
Default New tcl-8.5 and 8Kingdoms

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.


--Wart

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-07-2008, 08:41 PM
Hans de Goede
 
Default New tcl-8.5 and 8Kingdoms

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)


Regards,

Hans

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-07-2008, 08:44 PM
Michael Thomas
 
Default New tcl-8.5 and 8Kingdoms

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-07-2008, 08:54 PM
Hans de Goede
 
Default New tcl-8.5 and 8Kingdoms

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 05:36 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org