PATCH: memory leak in anonoymous functions

PATCH: memory leak in anonoymous functions

[Peter Stephenson]

Found by valgrind.  It's reporting lots of possible leaks, but they're
very hard to track down.  For example,

		save = (!(state->prog->flags & EF_HEAP) &&
			!strcmp(opat, right) && pprog != dummy_patprog2);

		if (!(pprog = patcompile(right, (save ? PAT_ZDUP : PAT_STATIC),
					 NULL))) {
		    zwarnnam(fromtest, "bad pattern: %s", right);
		    return 2;
		}
		else if (save)
		    state->prog->pats[npat] = pprog;

That pprog might be leaked, it says.  Er, yeah, right.

It's also very suspicious of parameters, particularly complicated uses
like tied parameters and autoloaded parameters.

Index: Src/exec.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/exec.c,v
retrieving revision 1.185
diff -p -u -r1.185 exec.c
--- Src/exec.c	27 Nov 2010 19:46:32 -0000	1.185
+++ Src/exec.c	3 Dec 2010 23:14:32 -0000
@@ -4159,6 +4159,10 @@ execfuncdef(Estate state, UNUSED(int do_
 
 	    execshfunc(shf, args);
 	    ret = lastval;
+
+	    freeeprog(shf->funcdef);
+	    zsfree(shf->filename);
+	    zfree(shf, sizeof(*shf));
 	    break;
 	} else {
 	    /* is this shell function a signal trap? */

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: PATCH: memory leak in anonoymous functions

[Bart Schaefer]

On Dec 3, 11:20pm, Peter Stephenson wrote:
}
} 		save = (!(state->prog->flags & EF_HEAP) &&
} 			!strcmp(opat, right) && pprog != dummy_patprog2);
} 
} 		if (!(pprog = patcompile(right, (save ? PAT_ZDUP : PAT_STATIC),
} 					 NULL))) {
} 		    zwarnnam(fromtest, "bad pattern: %s", right);
} 		    return 2;
} 		}
} 		else if (save)
} 		    state->prog->pats[npat] = pprog;
} 
} That pprog might be leaked, it says.  Er, yeah, right.

Well, if save is false but patcompile() returns non-null, then pprog
is never assigned anywhere.  But if save is false then patcompile() was
called with PAT_STATIC and there's nothing to free.  It's not very
surprising that a compile-time analysis wouldn't figure that out, but
valgrind does runtime analysis ...

Which would mean that state->prog->pats[] is what's being leaked ...,
sometime after evalcond() returns?