Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#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

1 2 > >> (Page 1 of 2)
  • 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
     
1 2 > >> (Page 1 of 2)