#1687 [unset; error] in var trace -> bad mem

obsolete: 8.4a4
closed-fixed
5
2001-12-07
2001-11-21
Don Porter
No

Here's a patch against the HEAD that adds a
test to tests/trace.test. Apply it and test
with ElectricFence or something similar
(TCL_MEM_DEBUG? Purify?) and you should see
a problem trying to access varPtr at line 4577
in CallTraces().

Note that although this patch adds the test to
Tcl 8.4, the same bug is in Tcl 8.3.4 too.

Discussion

  • miguel sofer

    miguel sofer - 2001-11-30

    Logged In: YES
    user_id=148712

    With TCL_MEM_DEBUG the output is:

    [mig@mini unix]$ ./tcltest ../tests/trace.test
    hi guard byte 5 is 0x60 `
    total mallocs 49700
    total frees 44502
    current packets allocated 5198
    current bytes allocated 375815
    maximum packets allocated 5230
    maximum bytes allocated 497758
    high guard failed at 81cb990, ./../generic/tclVar.c 1355
    131 bytes allocated at (./../generic/tclStringObj.c 842)
    Memory validation failure
    Aborted (core dumped)

    A backtrace on the core file does not show CallTraces, it
    appears that the offending call is from Tcl_SetVar2Ex
    (generic/tclVar.c:1355)

    The difference may be due to the fact that I have already
    applied the patch to Bug #484334?

     
  • miguel sofer

    miguel sofer - 2001-11-30

    Logged In: YES
    user_id=148712

    Don could not reproduce that last report of mine, and
    neither can I ...
    It may be that *I* did something stupid, or else mere
    chance.

     
  • Don Porter

    Don Porter - 2001-11-30

    Logged In: YES
    user_id=80530

    I can't get TCL_MEM_DEBUG to report anything,
    but ElectricFence on Linux/Alpha still reports
    a problem at tclVar.c:4577, and on Solaris 8
    it reports the problem at tclVar.c:1416. In each
    case during the [catch] evaluation in test trace-8.9.

     
  • Don Porter

    Don Porter - 2001-12-03

    Logged In: YES
    user_id=80530

    Here's an improved patch, adding a better test
    to the test suite. The prior one depended too
    much on the 'make test' context. The new
    test is more self-contained.

     
  • Don Porter

    Don Porter - 2001-12-03

    Logged In: YES
    user_id=80530

    another update. The bug has unpredictable
    dependencies on context, so it's easiest to
    get reproducible behavior by placing this
    test first.

    Build tcltest with efence and run

    ./tcltest ../tests/trace.test

     
  • Don Porter

    Don Porter - 2001-12-03
     
  • miguel sofer

    miguel sofer - 2001-12-06

    Logged In: YES
    user_id=148712

    (Sorry for the long report; just in case I have trouble
    reproducing it).

    I get (again?) a report of the segfault triggering from
    Tcl_SetVar2Ex (tclVar.c line 1355) trying to DecrRefCount
    the old value of errorInfo.

    I got the core dump from a tclsh linked with efence. The
    details are as follows (linux/i386):

    ./configure --disable-shared --enable-symbols
    make
    gcc -pipe -rdynamic tclAppInit.o -lefence
    -L/CVS/tcl_SF_clean/unix \
    -ltcl8.4g -ldl -lieee -lm -Wl,-rpath,/usr/local/lib
    -o tclsh
    ./tclsh

    and then entering at the tcl command line:

    trace add variable z array {set z(foo) 1 ;#}
    set res "names: [array names z]"
    catch {unset ::z}
    trace variable ::z w {unset ::z; error "memory
    corruption";#}
    list [catch {set ::z 1} msg] $msg

    This caused a segfault; "gdb tclsh core" says:

    Core was generated by `./tclsh'.
    Program terminated with signal 11, Segmentation fault.
    Reading symbols from /lib/libdl.so.2...done.
    Reading symbols from /lib/libm.so.6...done.
    Reading symbols from /lib/libc.so.6...done.
    Reading symbols from /lib/ld-linux.so.2...done.
    Reading symbols from /usr/lib/gconv/ISO8859-1.so...done.
    #0 0x400960b6 in chunk_free (ar_ptr=0x4012ad40,
    p=0x8111241) at malloc.c:3097
    3097 malloc.c: No such file or directory.
    (gdb) bt 20
    #0 0x400960b6 in chunk_free (ar_ptr=0x4012ad40,
    p=0x8111241) at malloc.c:3097
    #1 0x40095f9a in __libc_free (mem=0x8111280) at
    malloc.c:3023
    #2 0x80ea25c in TclpFree (cp=0x8111280 "\202") at
    ./../generic/tclAlloc.c:695
    #3 0x80703a4 in Tcl_Free (ptr=0x8111280 "\202") at
    ./../generic/tclCkalloc.c:1141
    #4 0x805c7fb in FreeStringInternalRep (objPtr=0x81356c0) at
    ./../generic/tclStringObj.c:1812
    #5 0x806254b in Tcl_SetVar2Ex (interp=0x8104510,
    part1=0x80edc1c "errorInfo", part2=0x0,
    newValuePtr=0x81356a8,
    flags=1) at ./../generic/tclVar.c:1355
    #6 0x80620e8 in Tcl_SetVar2 (interp=0x8104510,
    part1=0x80edc1c "errorInfo", part2=0x0,
    newValue=0x812b810 "can't set \"::z\": memory
    corruption", flags=1) at ./../generic/tclVar.c:1133
    #7 0x806d9ec in Tcl_AddObjErrorInfo (interp=0x8104510,
    message=0xbfffea14 "\n while executing\n\"set ::z 1\"",
    length=-1) at ./../generic/tclBasic.c:4721
    #8 0x806b990 in Tcl_LogCommandInfo (interp=0x8104510,
    script=0x810b2d0 "set ::z 1", command=0x810b2d0 "set ::z 1",
    length=9) at ./../generic/tclBasic.c:3118
    #9 0x80a3e6e in TclExecuteByteCode (interp=0x8104510,
    codePtr=0x810b360) at ./../generic/tclExecute.c:3937
    #10 0x8095c51 in TclCompEvalObj (interp=0x8104510,
    objPtr=0x8102cb8, engineCall=0) at
    ./../generic/tclExecute.c:844
    #11 0x806c5f9 in Tcl_EvalObjEx (interp=0x8104510,
    objPtr=0x8102cb8, flags=0) at ./../generic/tclBasic.c:3748
    #12 0x80711eb in Tcl_CatchObjCmd (dummy=0x0,
    interp=0x8104510, objc=3, objv=0x8105fb4)
    at ./../generic/tclCmdAH.c:255
    #13 0x806b62f in TclEvalObjvInternal (interp=0x8104510,
    objc=3, objv=0x8105fb4, command=0x0, length=0, flags=0)
    at ./../generic/tclBasic.c:2935
    #14 0x8096cc6 in TclExecuteByteCode (interp=0x8104510,
    codePtr=0x81272e8) at ./../generic/tclExecute.c:1258
    #15 0x8095c51 in TclCompEvalObj (interp=0x8104510,
    objPtr=0x810cdb8, engineCall=0) at
    ./../generic/tclExecute.c:844
    #16 0x806c5f9 in Tcl_EvalObjEx (interp=0x8104510,
    objPtr=0x810cdb8, flags=0) at ./../generic/tclBasic.c:3748
    #17 0x80acb4e in Tcl_RecordAndEvalObj (interp=0x8104510,
    cmdPtr=0x810cdb8, flags=0) at ./../generic/tclHistory.c:142
    #18 0x80547f4 in Tcl_Main (argc=1, argv=0xbffff974,
    appInitProc=0x805414c <Tcl_AppInit>)
    at ./../generic/tclMain.c:319
    #19 0x8054139 in main (argc=1, argv=0xbffff974) at
    ./../unix/tclAppInit.c:99

     
  • miguel sofer

    miguel sofer - 2001-12-06

    Logged In: YES
    user_id=148712

    Traces of the form
    trace add variable z array {set z(foo) 1 ;#}
    array names z
    were reducing z's refCount due to an inconsistency in the
    criteria for (a) bumping up the array's refCount and then
    (b) reducing it again.

    The enclosed arrayTrace.patch solves this.

     
  • miguel sofer

    miguel sofer - 2001-12-06

    bug fix + test

     
  • miguel sofer

    miguel sofer - 2001-12-07
    • status: open --> closed
     
  • miguel sofer

    miguel sofer - 2001-12-07
    • status: closed --> closed-fixed
     
  • miguel sofer

    miguel sofer - 2001-12-07

    Logged In: YES
    user_id=148712

    Patch committed.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks