#3875 core dump on FreeBSD stack overflow

obsolete: 8.5.0
closed-fixed
miguel sofer
9
2008-01-26
2007-12-14
Joe Mistachkin
No

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

Discussion

  • Joe Mistachkin
    Joe Mistachkin
    2007-12-14

    Logged In: YES
    user_id=113501
    Originator: YES

    FYI, this is the threaded debug build.

     
  • miguel sofer
    miguel sofer
    2007-12-14

    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

     
  • miguel sofer
    miguel sofer
    2007-12-14

    • labels: 105676 --> 105682
    • assigned_to: dgp --> msofer
     
  • Joe Mistachkin
    Joe Mistachkin
    2007-12-14

    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

     
  • miguel sofer
    miguel sofer
    2007-12-14

    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')?

     
  • Joe Mistachkin
    Joe Mistachkin
    2007-12-14

    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

     
  • miguel sofer
    miguel sofer
    2007-12-20

    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.

     
  • miguel sofer
    miguel sofer
    2007-12-21

    • priority: 5 --> 8
     
  • miguel sofer
    miguel sofer
    2007-12-21

    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

     
  • miguel sofer
    miguel sofer
    2007-12-21

    • labels: 105682 --> 49. Threading
     
  • miguel sofer
    miguel sofer
    2007-12-21

    Logged In: YES
    user_id=148712
    Originator: NO

    (1) a note on the previous comment: that same stack trace occurs independently of TCL_NO_STACK_CHECK. The comment seems to suggest (wrongly) that it happened only if stack check was disabled

    (2) More symptoms of thread problems:
    - on netbsd, see Emiliano's 'make test' problems at http://paste.tclers.tk/653
    - on freebsd (mistachkin's machine) we have segfaults/bus errors on append.test, compExpr-old.test, error.test, expr.test, fileName.test, opt.test, reg.test and stack.test
    In both cases non-threaded Tcl8.5.0 tests cleanly.

     
  • miguel sofer
    miguel sofer
    2007-12-21

    • priority: 8 --> 9
     
  • miguel sofer
    miguel sofer
    2007-12-21

    • milestone: --> obsolete: 8.5.0
     
  • miguel sofer
    miguel sofer
    2008-01-11

    • status: open --> pending-fixed
     
  • miguel sofer
    miguel sofer
    2008-01-11

    Logged In: YES
    user_id=148712
    Originator: NO

    The stack check is fixed in HEAD afaik; there are still some thread issues as shown in the stack trace below, even with stack checking disabled: they seem to be completely independent of the stack checking. The behaviour however does change when it is enabled.

    Opened #1869390 for the remaining issues.

     
    • status: pending-fixed --> closed-fixed
     
  • Logged In: YES
    user_id=1312539
    Originator: NO

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).