Menu
▾
▴
[Tcl-bugs] [ tcl-Bugs-1850424 ] core dump on FreeBSD stack overflow
|
From: SourceForge.net <no...@so...> - 2007-12-21 01:28:59
|
Bugs item #1850424, was opened at 2007-12-13 21:15 Message generated for change (Settings changed) made by msofer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1850424&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: 48. Threading Group: None Status: Open Resolution: None Priority: 8 Private: No Submitted By: Joe Mistachkin (mistachkin) Assigned to: miguel sofer (msofer) Summary: core dump on FreeBSD stack overflow Initial Comment: These tests were run against the Tcl/Tk 8.5.0 RC3 bits: ftp://ftp.tcl.tk/pub/tcl/tcl8_5/tcl8.5.0rc3-src.tar.gz The Unix stack checking no longer appears to work correctly on my 32-bit FreeBSD x86 box. proc test { a } { regsub -all -- {^(.*)$} $a {abc\0def} result return [test $result] } test "this is cool." Bus error (core dumped) *** Error code 138 % proc foo { a } { return [foo $a] } % foo 2 Bus error (core dumped) *** Error code 138 ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2007-12-20 22:28 Message: Logged In: YES user_id=148712 Originator: NO Something nastier is amiss with 8.5 and pthreads, apparently independent of the stack checking: in a build with TCL_NO_STACK_CHECK I get under gdb (gdb) run Starting program: /home/miguel/tcl8.5.0/unix/./tcltest % source ../tests/compExpr-old.test Program received signal SIGBUS, Bus error. 0x4820ff5e in _get_curthread () from /usr/lib/libc_r.so.4 (gdb) bt 10 #0 0x4820ff5e in _get_curthread () from /usr/lib/libc_r.so.4 #1 0x48209913 in pthread_getspecific () from /usr/lib/libc_r.so.4 #2 0x814e5d1 in TclpGetAllocCache () at /home/miguel/tcl8.5.0/unix/../unix/tclUnixThrd.c:844 #3 0x812f97e in TclpAlloc (reqSize=1024) at /home/miguel/tcl8.5.0/unix/../generic/tclThreadAlloc.c:291 #4 0x807508f in Tcl_AttemptAlloc (size=1024) at /home/miguel/tcl8.5.0/unix/../generic/tclCkalloc.c:1071 #5 0x80a6fc6 in ParseExpr (interp=0x81bac08, start=0x829b788 "(1==0)+-1", numBytes=9, opTreePtr=0xbfb001bc, litList=0x82cf7d0, funcList=0x82cbff0, parsePtr=0x82eede0, parseOnly=0) at /home/miguel/tcl8.5.0/unix/../generic/tclCompExpr.c:628 ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2007-12-20 12:47 Message: Logged In: YES user_id=148712 Originator: NO It seems like there is a bug in getrlimit: [miguel@jupiter ~/tcl8.5.0/unix]$ ulimit -s 1048576 [miguel@jupiter ~/tcl8.5.0/unix]$ ./tclsh rawStackSize from TclpThreadGetStackSize is 0 rawStackSize from getrlimit is 1073741824 stackSize from GetStackSize is 1073709056 Note tht the 0 from TclpThreadGetStackSize is "correct" - bug workaround for 1815573. But this is what is killing this system - setting 'initialized=1' in TclpThreadGetStackSize (ie, relying on pthread_attr_getstacksize also for the initial thread) fixes things. So the issue now seems to be that we have conflicting bugs in linux and freebsd for determining the size of the initial thread's stack: on linux pthread_attr_getstacksize returns garbage, on freebsd getrlimit does. ---------------------------------------------------------------------- Comment By: Joe Mistachkin (mistachkin) Date: 2007-12-14 07:22 Message: Logged In: YES user_id=113501 Originator: YES Same thing under plain tclsh, here is my ulimit output: core file size (blocks, -c) unlimited data seg size (kbytes, -d) 1048576 file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 11095 pipe size (512 bytes, -p) 1 stack size (kbytes, -s) 1048576 cpu time (seconds, -t) unlimited max user processes (-u) 5547 virtual memory (kbytes, -v) unlimited ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2007-12-14 06:56 Message: Logged In: YES user_id=148712 Originator: NO (Assuming that is or behaves like bash's ulimit builtin) You seem to have a 1GB stack limit under 'make shell', which is a bit largeish. What does 'ulimit -s' at the shell prompt report? Do you still get the core dump if you run your test script under plain tclsh (as opposed to 'make shell')? ---------------------------------------------------------------------- Comment By: Joe Mistachkin (mistachkin) Date: 2007-12-13 23:51 Message: Logged In: YES user_id=113501 Originator: YES This is from make shell. Here is the output from your commands: % sh -c "ulimit -s" 1048576 % sh -c "ulimit -S" unlimited ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2007-12-13 22:30 Message: Logged In: YES user_id=148712 Originator: NO (This may be neither here nor there, but ...) Was that in a 'make shell' shell, or plain ./tclsh? The difference is that make seems to change the process limits: mig@uh:/home/CVS/tcl_SF_clean/unix$ ./tclsh % sh -c "ulimit -s" 8192 % sh -c "ulimit -S" unlimited % mig@uh:/home/CVS/tcl_SF_clean/unix$ make shell LD_LIBRARY_PATH=`pwd`:${LD_LIBRARY_PATH}; export LD_LIBRARY_PATH; \ TCL_LIBRARY="/home/CVS/tcl_SF_clean/library"; export TCL_LIBRARY; \ ./tclsh % sh -c "ulimit -s" unlimited % sh -c "ulimit -S" unlimited ---------------------------------------------------------------------- Comment By: Joe Mistachkin (mistachkin) Date: 2007-12-13 21:16 Message: Logged In: YES user_id=113501 Originator: YES FYI, this is the threaded debug build. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1850424&group_id=10894 |