Date: Wed, 23 Feb 2005 19:09:01 -0600 (CST) From: =?ISO-8859-1?Q?Se=E1n_C=2E_Farley?= <sean-freebsd@farley.org> To: =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= <des@des.no> Cc: freebsd-hackers@freebsd.org Subject: Re: setenv/unsetenv's known memory leak Message-ID: <20050223140733.T35108@thor.farley.org> In-Reply-To: <863bvnmyrt.fsf@xps.des.no> References: <20050222173013.B26342@thor.farley.org> <863bvnmyrt.fsf@xps.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-919433075-1109189845=:35108 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: <20050223185614.I37069@thor.farley.org> On Wed, 23 Feb 2005, Dag-Erling Sm=F8rgrav wrote: > Se=E1n C. Farley <sean-freebsd@farley.org> writes: >> While playing around with setenv(), I noticed that it can leak memory >> when a program overwrites a variable with a larger value. unsetenv() >> will just leak memory. All of this is documented in their man pages. >> >> The latest PR on this (two PR's mentioned in it are closed): >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dmisc/19406 > > They were closed for a reason. Read their audit trails. > >> I could find no apparent reason for continuing to allow for the >> memory leak. The only reason given to allow it was to permit >> programs to continue to use the environment variable retrieved by >> setenv() after the program had reset or deleted it. > > Wrong. The reason for the leak is that the initial environment array > is not malloc()ed and therefore cannot be free()d or realloc()ed. To > work around this requires a lot of bookkeeping. > > BTW, SUSv3 explicitly states that the application can not expect the > pointer returned by getenv() to remain meaningful after a subsequent > call to getenv(), setenv(), unsetenv() or (on XSI-conformant systems) > putenv(), so that argument falls flat on its face. Thank you. That is good to know. >> Here is a test program along with a patch to stop the leak: >> http://www.farley.org/freebsd/tmp/setenv.tar.bz2 > > You can't possibly have tested it very thoroughly. Try running your > test program with MALLOC_OPTIONS=3DAX in your environment: > > des@xps ~/src/setenv% MALLOC_OPTIONS=3DAX ./testenv > testenv in realloc(): error: junk pointer, too high to make sense > zsh: abort (core dumped) MALLOC_OPTIONS=3DAX ./testenv That is odd. I do not see that error with my changes (old or new) and using MALLOC_OPTIONS. I am running 5-STABLE. I have made a new set of patches based on your and Peter Jeremy's comments (variables on the stack). The first patch is just style changes. The second patch is the actual change. They were tested with MALLOC_OPTIONS=3DAX and dmalloc (not at the same time). The changes are: 1. Tracking of dynamically allocated environment variables. 2. Reallocation/freeing of variables using above tracking to prevent incorrect manipulation of variables allocated on the stack. http://www.farley.org/freebsd/tmp/setenv.tar.bz2 How does this version look? Se=E1n --=20 sean-freebsd@farley.org --0-919433075-1109189845=:35108--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050223140733.T35108>