Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Message-ID: <397D6B99.77361071@cygnus.com> Date: Tue, 25 Jul 2000 12:27:37 +0200 From: Corinna Vinschen Reply-To: cygwin X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.14-SMP i686) X-Accept-Language: de, en MIME-Version: 1.0 To: Andrej Borsenkow CC: Cygwin AT Sourceware DOT Cygnus DOT Com Subject: Re: memory leak in setenv()? References: <001201bff612$88df19f0$21c9ca95 AT mow DOT siemens DOT ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andrej Borsenkow wrote: > > If existing value is longer than new, old value is simply overwritten. > But if old value is shorter, new memory chunk is allocated via malloc(), > but old one is never freed. Initially all environment strings are > allocated using strdup() in environ_init(), so who is responsible for > freeing unused memory in this case? Nobody in case of setenv() and unsetenv(). It's a known problem of the environment implementation that freeing environment variables is not easy. The library can't decide if a string is currently in use by the application. As another example take a look into the implementation of setenv/unsetenv in glibc. It does never free environment strings by itself so each call to setenv(NAME, VAL, 1) creates a new memory leak unless it is a known string value once given to setenv. In that case, glibc tries to recycle strings to use memory more efficient. Corinna -- Corinna Vinschen Cygwin Developer Cygnus Solutions, a Red Hat company -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com