#5048 Trying to increment refCount of previously disposed object

obsolete: 8.4.19
open
nobody
None
5
2012-06-05
2012-06-05
John
No

Related to 3528929

#0 0x68092373 in pthread_testcancel () from /usr/lib/libpthread.so
#1 0x68083171 in sigaction () from /usr/lib/libpthread.so
#2 0x6807d1f5 in pthread_kill () from /usr/lib/libpthread.so
#3 0x6807cbc4 in raise () from /usr/lib/libpthread.so
#4 0x68226213 in abort () from /lib/libc.so.5
#5 0x6811939c in Tcl_PanicVA (format=0x68145a48 "Trying to increment refCount of previously disposed object.",
argList=0x17e <Address 0x17e out of bounds>)
at /.amd_mnt/lab-home1/exports/home/jhexan/bin/tcl-debug/tcl/unix/../generic/tclPanic.c:106
#6 0x681193c0 in Tcl_Panic (arg1=0x17e <Address 0x17e out of bounds>)
at /.amd_mnt/lab-home1/exports/home/jhexan/bin/tcl-debug/tcl/unix/../generic/tclPanic.c:134
#7 0x68118c5a in Tcl_DbIncrRefCount (objPtr=0x1d40a720, file=0x17e <Address 0x17e out of bounds>, line=382)
at /.amd_mnt/lab-home1/exports/home/jhexan/bin/tcl-debug/tcl/unix/../generic/tclObj.c:2632
#8 0x680ea291 in TclExecuteByteCode (interp=0x805a020, codePtr=0x1aea8020)
at /.amd_mnt/lab-home1/exports/home/jhexan/bin/tcl-debug/tcl/unix/../generic/tclExecute.c:1830
#9 0x680f34d8 in TclCompEvalObj (interp=0x805a020, objPtr=0xc6d8420)
at /.amd_mnt/lab-home1/exports/home/jhexan/bin/tcl-debug/tcl/unix/../generic/tclExecute.c:1107
#10 0x680bd274 in Tcl_EvalObjEx (interp=0x805a020, objPtr=0xc6d8420, flags=0)
at /.amd_mnt/lab-home1/exports/home/jhexan/bin/tcl-debug/tcl/unix/../generic/tclBasic.c:4618
#11 0x682599ed in Itcl_EvalMemberCode ()
from /nfs/lab-ccservers/primary5/jhexan_lab/fwtest/bin/lib/itcl3.3/i386-FreeBSD5/libitcl3.4.so
#12 0x6825a886 in Itcl_ExecMethod () from /nfs/lab-ccservers/primary5/jhexan_lab/fwtest/bin/lib/itcl3.3/i386-FreeBSD5/libitcl3.4.so
#13 0x680ba9e8 in TclEvalObjvInternal (interp=0x805a020, objc=3, objv=0x805c14c, command=0x0, length=0, flags=0)
at /.amd_mnt/lab-home1/exports/home/jhexan/bin/tcl-debug/tcl/unix/../generic/tclBasic.c:3219
#14 0x680ea8d0 in TclExecuteByteCode (interp=0x805a020, codePtr=0x1aed4020)
at /.amd_mnt/lab-home1/exports/home/jhexan/bin/tcl-debug/tcl/unix/../generic/tclExecute.c:1582
#15 0x680f34d8 in TclCompEvalObj (interp=0x805a020, objPtr=0xd9110a0)
at /.amd_mnt/lab-home1/exports/home/jhexan/bin/tcl-debug/tcl/unix/../generic/tclExecute.c:1107
#16 0x680bd274 in Tcl_EvalObjEx (interp=0x805a020, objPtr=0xd9110a0, flags=0)
at /.amd_mnt/lab-home1/exports/home/jhexan/bin/tcl-debug/tcl/unix/../generic/tclBasic.c:4618
#17 0x682599ed in Itcl_EvalMemberCode ()
from /nfs/lab-ccservers/primary5/jhexan_lab/fwtest/bin/lib/itcl3.3/i386-FreeBSD5/libitcl3.4.so
#18 0x6825a886 in Itcl_ExecMethod () from /nfs/lab-ccservers/primary5/jhexan_lab/fwtest/bin/lib/itcl3.3/i386-FreeBSD5/libitcl3.4.so
#19 0x680ba9e8 in TclEvalObjvInternal (interp=0x805a020, objc=101, objv=0x1b40ce20,
command=0x1b40ca20 "SetRadiusAttributes 0 1 string true true true 0 4 addr true true true 0 5 int true true true 0 6 int true true true 0 7 string true true true 0 8 addr true true true 0 9 addr true true true 0 12 int t"..., length=452, flags=0)
at /.amd_mnt/lab-home1/exports/home/jhexan/bin/tcl-debug/tcl/unix/../generic/tclBasic.c:3219
#20 0x680bc546 in Tcl_EvalEx (interp=0x805a020,
script=0x1b40ca20 "SetRadiusAttributes 0 1 string true true true 0 4 addr true true true 0 5 int true true true 0 6 int true true true 0 7 string true true true 0 8 addr true true true 0 9 addr true true true 0 12 int t"..., numBytes=452, flags=262144)
at /.amd_mnt/lab-home1/exports/home/jhexan/bin/tcl-debug/tcl/unix/../generic/tclBasic.c:4011

Discussion

  • Don Porter

    Don Porter - 2012-06-05

    Appears you're working with the released 8.4.19 then.

     
  • Don Porter

    Don Porter - 2012-06-05

    So the panic message is clear enough. #7 is calling
    for the refcount on (Tcl_Obj *) 0x1d40a720 to be incremented,
    but that pointer is pointing to memory that's already been freed.
    Somehow the program is keeping a pointer around longer than it's valid.

    Can you shed any light on what that (Tcl_Obj *) value is?

     
  • Don Porter

    Don Porter - 2012-06-05

    #8 seems to be the execution of one of the INST_LOAD_ARRAY
    instructions, and the panic happening while trying to incr the
    refcount of the value of one element variable of an array while
    pushing that value onto the stack. That suggests something
    is already seriously broken, if a Tcl variable is holding a (Tcl_Obj *)
    value that's been freed. Someone somewhere's not been
    housekeeping their refcounts properly is my guess.

     
  • John

    John - 2012-06-05

    0x1d40a720: 0x61616161

    This is the tcl stack, if it's of any help:

    Thread 10, frame 12 is in
    Itcl class '' method ''
    Thread 10, frame 13 is executing command:
    DestroyRow 11 RadiusAttributes
    Thread 10, frame 18 is in
    Itcl class '' method ''
    Thread 10, frame 19 is executing command:
    SetRadiusAttributes 0 1 string true true true 0 4 addr true true true 0 5 int true true true 0 6 int true true true 0 7 string true true true 0 8 addr true true true 0 9 addr true true true 0 12 int true true true 0 13 int true true true 0 25 string true true true 0 31 string true true true 0 30 string true true true -v sandvine.com 0 40 int true true true 0 44 string true true true 0 61 int true true true 0 78 string true true true -v measurements
    Thread 10, frame 23 is executing command:
    eval SetRadiusAttributes {0 1 string true true true 0 4 addr true true true 0 5 int true true true 0 6 int true true true 0 7 string true true true 0 8 addr true true true 0 9 addr true true true 0 12 int true true true 0 13 i}
    Thread 10, frame 28 is in
    Itcl class '' method ''
    Thread 10, frame 31 is executing command:
    ::idevice126852 mapRat {0 1 string true true true 0 4 addr true true true 0 5 int true true true 0 6 int true true true 0 7 string true true true 0 8 addr true true true 0 9 addr true true true 0 12 int true true true 0 13 i}
    Thread 10, frame 37 is executing command:
    uplevel {set aval [$m_pdb_this $m_pdb_tofn($va) $aval]}
    Thread 10, frame 40 is executing body of "proc catch"
    Thread 10, frame 41 is executing command:
    catch {set aval [$m_pdb_this $m_pdb_tofn($va) $aval]} e ei ec
    Thread 10, frame 46 is in
    Itcl class '' method ''
    Thread 10, frame 50 is executing command:
    chain -radiusAttributesTable {0 1 string true true true 0 4 addr true true true 0 5 int true true true 0 6 int true true true 0 7 string true true true 0 8 addr true true true 0 9 addr true true true 0 12 int true true true 0 13 i}
    Thread 10, frame 55 is executing command:
    foreach NULL-POINTER NULL-POINTER {\$125 = 0x1adcfe20 \"\ set na \[split \$n /\]\ if \{ \[llength \$na\] == 2 \} \{\ \", ' ' <repeats 12 times>, \"SetFlowVariables \[string range \[lindex \$na 0\] 1 end\] -\[lindex \$na 1\] \$v\ \} elseif \{ \$n eq \\\"-radiusDomain\\\" \} \{\ \"...}
    Thread 10, frame 60 is in
    Itcl class '' method ''
    Thread 10, frame 63 is executing command:
    ::idevice126852 configure -numFlows 10 -radiusEnabled false -radiusAttributesTable {0 1 string true true true 0 4 addr true true true 0 5 int true true true 0 6 int true true true 0 7 string true true true 0 8 addr true true true 0 9 addr true true true 0 12 int true true true 0 13 i} -startSrcIp 11.0.0.1 -numSrcIp 1 -startDstIp 1.0.0.1 -numDstIp 1 -startSrcIp6 2008:0:500:0:: -numSrcIp6 16777216 -startDstIp6 2008:0:400:0:: -numDstIp6 131072
    Thread 10, frame 67 is executing command:
    eval ::idevice126852 {\$152 = 0x1b4a1020 \"configure -numFlows 10 -radiusEnabled false -radiusAttributesTable \{0 1 string true true true 0 4 addr true true true 0 5 int true true true 0 6 int true true true 0 7 string true true true 0 8 addr t\"...}
    Thread 10, frame 72 is in
    Itcl class '' method ''
    Thread 10, frame 75 is executing command:
    ::svTraffic::svTraffic::svTrafficProcess3 tipDevice configure -numFlows 10 -radiusEnabled false -radiusAttributesTable {0 1 string true true true 0 4 addr true true true 0 5 int true true true 0 6 int true true true 0 7 string true true true 0 8 addr true true true 0 9 addr true true true 0 12 int true true true 0 13 i} -startSrcIp 11.0.0.1 -numSrcIp 1 -startDstIp 1.0.0.1 -numDstIp 1 -startSrcIp6 2008:0:500:0:: -numSrcIp6 16777216 -startDstIp6 2008:0:400:0:: -numDstIp6 131072
    Thread 10, frame 79 is executing command:
    eval ::svTraffic::svTraffic::svTrafficProcess3 tipDevice configure {\$182 = 0x1b49d020 \"-numFlows 10 -radiusEnabled false -radiusAttributesTable \{0 1 string true true true 0 4 addr true true true 0 5 int true true true 0 6 int true true true 0 7 string true true true 0 8 addr true true t\"...}
    Thread 10, frame 84 is in
    Itcl class '' method ''
    Thread 10, frame 85 is executing command:
    fullSocketReconfigure NULL-POINTER
    Thread 10, frame 90 is in
    Itcl class '' method ''
    Thread 10, frame 91 is executing command:
    updateRunningConfig false

    One thing to note is this call, fullSocketReconfigure NULL-POINTER. Somehow we're calling that method with a null pointer (should be a list), I wonder if that's what triggers the crash.

     
  • Don Porter

    Don Porter - 2012-06-05

    I've got no idea what all that means.

     
  • Don Porter

    Don Porter - 2012-06-05

    If you can determine what value, or what array element variable
    is the one triggering the panic, that might give you a clue where
    to look for the programming errors.

     
  • John

    John - 2012-06-05

    The crash happens in this code snippet bellow, on 'DestroyRow' call. Not sure how this can help track down the bug in the C code.

    foreach row [lsort -dict -decr [array names m_attrRow]] \ {
    DestroyRow $row RadiusAttributes
    }

     
  • Don Porter

    Don Porter - 2012-06-05

    Is [DestroyRow] a proc? If so, what is its body?

     
  • John

    John - 2012-06-05

    itcl::body ItableMgr::DestroyRow { row {tableId 0} } \ {
    set count 0
    set nRemoved $m_nRemoved
    pdb::DestroyRow $m_tablePaths($tableId) $row
    while {$nRemoved == $m_nRemoved} \ {
    incr count
    if {$count >= 1000} \ {
    error "ItableMgr did not receive destroy notification for row $row table $tableId"
    }

    after 1
    update
    }
    }

     
  • Don Porter

    Don Porter - 2012-06-05

    ok, so in that body, where is the panic?
    And if the answer is another command that
    has a body, where in that one? And so on until
    we get to the actual bytecode triggering the panic.

     
  • John

    John - 2012-06-05

    The panic actually happens on that first line that I sent you. Nothing gets executed in ItableMgr::DestroyRow.

     
  • Don Porter

    Don Porter - 2012-06-05

    According to the C stack trace, the panic happens
    while executing an INST_LOAD_ARRAY instruction.
    I'm looking for the reading of an array variable that's
    been compiled to bytecode.

     
  • John

    John - 2012-06-06

    Could it be $m_tablePaths($tableId) in ItableMgr::DestroyRow? Frame #8 is trying to execute ItableMgr::DestroyRow, but I'm not sure which tcl variable in there is causing the crash. All I get from gdb is that the object is pointing to freed up memory.

    Do you know what the significance of this is?
    #7 file=0x17e <Address 0x17e out of bounds>

     
  • John

    John - 2012-06-07

    So turns out the panic happens when reading array m_tablePaths for element "RadiusAttributes". The refcount for the array is 2, but the element that's being accessed is already freed up. How can I backtrack from here to figure out the spot where the refCount is messed up.

     
  • Don Porter

    Don Porter - 2012-06-11

    The line #7 output suggest memory corruption may
    (also) be at work here. Running your tests with
    --enable-symbols=all builds of Tcl and Itcl may help
    locate things sooner, with memory debugging tools
    turned on.

    Knowing what variable is holding the freed value might
    also be helpful if you can locate where else that value
    is manipulated in the program you might find the program
    error in refCounting. On the other hand, if memory corruption
    is at work, that might be the real issue and the refcount symptom
    just an illusion.

     
  • Alexandre Ferrieux

    Note that if the offending object and refcount are stable across runs, gdb's "watch" command is handy:

    gdb> print &obj->refCount
    0x12345678
    gdb> watch *(int *)0x12345678

    Sure, the program will run extremely slowly, but you'll catch all decrements/increments to the specific object's refcount.

     
  • John

    John - 2012-06-20

    With --enable-symbols=all, I can't seem to hit the crash. What else gets enabled with this flag, is it possible that the memory corruption/refCounting issue is avoided in this case. What is the performance impact of having this debugging enabled?

     
  • John

    John - 2012-06-21

    I also tried to avoid using that m_tablePaths array, and this seemed to avoid the crash while running the script. However, a similar crash happened when I stopped the script and tried to destroy the itcl object and m_tablePaths, which I think narrows the problem to only this array.

    This is what the tcl code surrounding m_tablePaths looks like:

    itcl::class ItableMgr \ {
    private variable m_tablePaths

    itcl::body ItableMgr::AddTable { tableId} \ {
    ...
    set m_tablePaths($tableId) $tablePath
    ...
    }

    itcl::body ItableMgr::DestroyRow { row {tableId 0} } \ {
    ...
    pdb::DestroyRow $m_tablePaths($tableId) $row
    ...
    }

    itcl::body ItableMgr::CreateRow { row {tableId 0} } \ {
    ...
    pdb::CreateRow $m_tablePaths($tableId) $row
    ...
    }

    }

    itcl::class Idevice12685 \ {
    inherit ItableMgr
    public method SetRadiusAttributes { args } \ {
    ...
    foreach row $tableRow \ {
    DestroyRow $row RadiusAttributes
    }
    ...
    foreach row $tableRow \ {
    CreateRow $row RadiusAttributes
    }

    }
    }

    AddTable is only called once to associate tableId with a tablePath. DestroyRow/CreateRow is then called repeatedly. There's nothing else that touches m_tablePaths.

     

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

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks