From: SourceForge.net <no...@so...> - 2011-08-06 17:06:31
|
Bugs item #3386417, was opened at 2011-08-05 01:03 Message generated for change (Comment added) made by ferrieux You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3386417&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: 47. Bytecode Compiler Group: development: 8.6b2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: miguel sofer (msofer) Assigned to: miguel sofer (msofer) Summary: errorstack leaked on syntax error Initial Comment: When the compiler bails out on a syntax error, the errorstack is leaked. For example, for the script namespace eval x {set syntax {}{}} valgrind reports 0: malloc (vg_replace_malloc.c:236) 1: TclpAlloc (tclAlloc.c:705) 2: Tcl_Alloc (tclCkalloc.c:1046) 3: Tcl_NewListObj (tclListObj.c:225) 4: Tcl_CreateInterp (tclBasic.c:542) 5: Tcl_Main (tclMain.c:639) 6: main (tclAppInit.c:84) -- foo: ==9070== 3,248 (48 direct, 3,200 indirect) bytes in 1 blocks are definitely lost in loss record 136 of 136 ---------------------------------------------------------------------- >Comment By: Alexandre Ferrieux (ferrieux) Date: 2011-08-06 19:06 Message: By the way, though you're not telling, I guess you are using the patch from 2919042 (so that -DPURIFY forces finalization), right ? Since it seems useful for leak hunting, how about a commit ? ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2011-08-06 18:49 Message: Hmm, I'd guess "interactive" is key. Though [history clear] was not enough to purge the offending literal in my tests. Will dig further. ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2011-08-06 16:45 Message: Positively strange ... To repro CFLAGS=-DPURIFY ./configure --disable-shared --enable-symbols Then mig@ari:~/DEVEL/tcl-core/trunk/unix$ cat /tmp/foo namespace eval x {set syntax {}{}} proc exit args {} mig@ari:~/DEVEL/tcl-core/trunk/unix$ cat /tmp/foo | /usr/bin/valgrind --leak-check=yes --num-callers=10 --show-reachable=yes ./tcltest &> /tmp/foo.res Look for 'definitely' in /tmp/foo.res, you'll find it. BUT: the leak does NOT appear if you do /usr/bin/valgrind --leak-check=yes --num-callers=10 --show-reachable=yes ./tcltest /tmp/foo &> /tmp/foo.res So it may have something to do with io??? ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2011-08-06 15:07 Message: Cannot seem to repro with HEAD, even though patch 2919042 applied and TCL_FINALIZE_ON_EXIT set to 1, and single-line script with the above code passed as arg to non-interactive tclsh Note that valgrind --leak-check=full gives many other (larger) leaks, but not this one. Please give details about experimental conditions to help repro ;-) ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2011-08-06 13:45 Message: Good point :) So maybe that literal thing is a red herring. However, what is exactly your way of exiting Tcl so that all finalizations execute ? Are you using the 2919042 trick ? ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2011-08-06 12:50 Message: Unlikely: my valgrind script would show the literal or the options dict being leaked, but not the errorstack (as a ref to it would still be around, namely in the options dict). This is a 'definitely lost' struct ... ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2011-08-06 12:46 Message: Quick analysis shows that an extra ref (to errorstack, but also to other return options) is kept in an options-dict computed by CompileReturnInternal. That dict is soldered into a literal (TclAddLiteralObj), so it looks like the lifecycle of that literal is the culprit. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3386417&group_id=10894 |