[Tcl-bugs] [ tcl-Bugs-2919042 ] Exit reform lost valgrindability

[SourceForge.net <no...@so...>]

Bugs item #2919042, was opened at 2009-12-22 02:06
Message generated for change (Comment added) made by ferrieux
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2919042&group_id=10894

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 42. Memory Preservation
Group: current: 8.6b1
Status: Open
Resolution: None
Priority: 8
Private: No
Submitted By: Alexandre Ferrieux (ferrieux)
Assigned to: Don Porter (dgp)
Summary: Exit reform lost valgrindability

Initial Comment:
The quick-exit reform of Bug 2001201 neglected the "valgrindability" of Tcl executables.
Indeed, it moved Tcl_Finalize out of the default Tcl_Exit path.
The attached patch corrects this by letting the TCL_FINALIZE_ON_EXIT environment variable, when set and not "0", make Tcl_Exit call Tcl_Finalize in the exact same sequence as before the reform.
It should be noted that while useful for leak hunting, this tool shouldn't be used too creatively in threaded builds. The fundamental reason behind the reform (deadlocks and crashes) is here to stay.


----------------------------------------------------------------------

>Comment By: Alexandre Ferrieux (ferrieux)
Date: 2009-12-22 15:24

Message:
OK, proceeding anyway.
The attached 'val2' patch is a superset of the previous one; in addition,
it establishes an exit handler to call FreeMainInterp, a new routine doing
the final DeleteInterp+Release+SetStartupScript(NULL,NULL).
The existing TclInExit() MODULE_SCOPE-visible predicate is used to disable
several panics from the running interpreter (solving the Muenchhausen
effect).

With this patch, and the TCL_FINALIZE_ON_EXIT variable set, valgrind shows
two interesting things (valgring --leak-check==full ./tclsh /dev/null):

   (1) a few bytes are leaked due to the active bytecode and stack frames
being left over (associated with a suppressed panic complaining about
them).

   (2) several big blocks of TclAllocateFreeObjects's  (2400 bytes) are
leaked.

Of course, (1) is expected, pending dedicated work for cleaning up the
running interp. No big deal.

However, (2) is funny in the light of the following comment in
TclAllocateFreeObjects:

     * This has been noted by Purify to be a potential leak. The problem
is
     * that Tcl, when not TCL_MEM_DEBUG compiled, keeps around all
allocated
     * Tcl_Obj's, pointed to by tclFreeObjList, when freed instead of
actually
     * freeing the memory. TclFinalizeObjects() does not ckfree() this
memory,
     * but leaves it to Tcl's memory subsystem finalization to release
it.
     * Purify apparently can't figure that out, and fires a false alarm.

It is funny, because there is no mystery. Purify is not at fault. It just
turns out that in the default -DTCL_ALLOC=0 -UTCL_MEM_DEBUG used in unix,
those blocks are simply malloc'ed with no linking or external referencing.
Another proof of that is that in that case, TclFinalizeMemorySubsystem is
an empty function !

Of course this merits another bugreport; in the meantime please validate
the approach of the current patch.

----------------------------------------------------------------------

Comment By: Alexandre Ferrieux (ferrieux)
Date: 2009-12-22 13:05

Message:
Just tried that. Doesn't work, Tcl_Panic("DeleteInterpProc called with
active evals");
Indeed that's a natural effect of Tcl_Eval("exit")...
What's the preferred way out of that "Muenchhausen effect" ?

----------------------------------------------------------------------

Comment By: Alexandre Ferrieux (ferrieux)
Date: 2009-12-22 12:49

Message:
Ah, valgrindability may be restored, but we still don't delete the main
interp during the finalizing exit sequence. Maybe an exit handler doing
DeleteInterp+Release is due ?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2919042&group_id=10894