#3288 varTraces leak when variable is unset

obsolete: 8.4.11
closed-fixed
46. Traces (50)
9
2005-11-08
2005-11-05
miguel sofer
No

The new test trace-8.9 shows an 18-byte leak:
set end [getbytes]
for {set i 0} {$i < 5} {incr i} {
set apa {a 1 b 2}
set bepa [lrange $apa 0 end]
trace add variable bepa write {error hej}
catch {set bepa a}
unset bepa
set tmp $end
set end [getbytes]
}
expr {$end - $tmp}

This supercedes #1342858, which detected the same leak
but blamed it on [dict].

Discussion

1 2 > >> (Page 1 of 2)
  • miguel sofer
    miguel sofer
    2005-11-07

    Logged In: YES
    user_id=148712

    Test trace-8.9 deleted, trace-13.2-4 added to HEAD and
    8-4-branch.

    When a traced variable is unset, the TraceVarInfo
    (clientData in the VarTrace struct) is leaked. This should
    be fixed directly in 8.4, and possibly together with
    #1056134 in HEAD.

     
  • miguel sofer
    miguel sofer
    2005-11-07

    • milestone: 500308 --> obsolete: 8.4.11
    • summary: varTraces leak on error --> varTraces leak when variable is unset
    • priority: 5 --> 8
     
  • miguel sofer
    miguel sofer
    2005-11-07

    Logged In: YES
    user_id=148712

    Specifically: the code for [unset] does Tcl_EventuallyFree
    the VarTrace, but does not free the contents of its
    clientData field.

    Look for a q&d solution in 8-4, and a redesign for 8.5 (see
    also #1056134) maybe involving api changes: Tcl_TraceVar
    should take also a deletion callback as argument.

     
  • miguel sofer
    miguel sofer
    2005-11-07

    • priority: 8 --> 9
     
  • miguel sofer
    miguel sofer
    2005-11-07

    Logged In: YES
    user_id=148712

    The attached patch solves the issue for 8.4, in an inelegant
    but effective and safe (?) way - assigning to dkf for a
    second opinion on this.

     
  • miguel sofer
    miguel sofer
    2005-11-07

    • assigned_to: msofer --> dkf
     
  • miguel sofer
    miguel sofer
    2005-11-07

    Logged In: YES
    user_id=148712

    Patch replaced with a slightly-less-icky one (thanks kevin
    and joe).

     
  • miguel sofer
    miguel sofer
    2005-11-07

     
    Attachments
  • Logged In: YES
    user_id=79902

    Might be cleaner to introduce a new private function
    (perhaps called TclTraceVarEx) that lets the caller supply
    the VarTrace with the traceProc, clientData and flags fields
    already filled in. That would, in turn, allow the lookup
    code to be handled far more neatly (i.e. by not inlining it
    all in the [trace * variable] subcommand implementation).

    The general strategy (using a single alloc instead of a
    pair) should work well though, given that we cannot change
    the API.

    Still thinking about this...

     
    • status: open --> closed
     
1 2 > >> (Page 1 of 2)