Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH: fix memory leak in new setenv code
- X-seq: zsh-workers 24112
- From: Geoff Wing <gcw@xxxxxxx>
- To: Zsh Hackers <zsh-workers@xxxxxxxxxx>
- Subject: Re: PATCH: fix memory leak in new setenv code
- Date: Thu, 22 Nov 2007 13:57:11 +1100
- In-reply-to: <2755.1193848735@dcle12>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- Organization: PrimeNet Computer Consultancy
- References: <2755.1193848735@dcle12>
On Thursday 2007-11-01 03:39 +1100, Oliver Kiddle output:
:I noticed using Solaris libumem and mdb that zsh is leaking memory
:every time an environment variable is modified. I traced this down to
:some relatively recent change to use setenv(3) and the fact that the
:old value was not being freed. I think the patch below is the correct
:fix.
:
:Oliver
:
:--- Src/params.c.orig Wed Oct 31 17:30:57 2007
:+++ Src/params.c Wed Oct 31 17:28:49 2007
:@@ -3998,6 +3998,8 @@
: * the other branch? If so, we don't actually need to
: * store pm->env at all, just a flag that the value was set.
: */
:+ if (pm->env)
:+ zsfree(pm->env);
: pm->env = newenv;
: #else
: /*
:
This can't be right and corrupts my environment (using zsh memory
routines). Running "env" spews out lots of bad stuff.
If we're supposed to be zsfree()ing that, why aren't we doing it
consistently, i.e. around the line which assigns newenv and before
the call to zputenv()? Maybe it should be managed differently?
Regards,
Messages sorted by:
Reverse Date,
Date,
Thread,
Author