From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 23 04:01:13 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F40C716A4CE for ; Wed, 23 Feb 2005 04:01:12 +0000 (GMT) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 783A043D49 for ; Wed, 23 Feb 2005 04:01:12 +0000 (GMT) (envelope-from sean-freebsd@farley.org) Received: from thor.farley.org (thor.farley.org [IPv6:2001:470:1f01:290:1::5]) by mail.farley.org (8.13.1/8.13.1) with ESMTP id j1N41AZS081013 for ; Tue, 22 Feb 2005 22:01:10 -0600 (CST) (envelope-from sean-freebsd@farley.org) Received: from localhost (localhost [127.0.0.1]) by thor.farley.org (8.13.1/8.13.1) with ESMTP id j1N41CII027963 for ; Tue, 22 Feb 2005 22:01:12 -0600 (CST) (envelope-from sean-freebsd@farley.org) Date: Tue, 22 Feb 2005 22:01:12 -0600 (CST) From: =?ISO-8859-1?Q?Se=E1n_C=2E_Farley?= To: freebsd-hackers@freebsd.org Message-ID: <20050222173013.B26342@thor.farley.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1396765616-1109117000=:26342" Content-ID: <20050222220040.T27937@thor.farley.org> Subject: setenv/unsetenv's known memory leak X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2005 04:01:13 -0000 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-1396765616-1109117000=:26342 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: <20050222180603.T26686@thor.farley.org> 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 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. If a program can be assumed to have a persistent pointer, it should be considered memory that should be freed by the program later. Yes? Obviously, this is not the case with the setenv()/unsetenv() API. Also, if the pointer is used by a program after it has been overwritten, the program will be using the wrong value if the value was expanded in size. After updating an environment variable, the value will be wrong (freed memory or incorrect value) regardless if the leak is plugged or not. It stands to reason that fixing the leak should not be harmful. In checking a different system, I verified that Linux does not exhibit this leak. Here is a test program along with a patch to stop the leak: http://www.farley.org/freebsd/tmp/setenv.tar.bz2 Se=E1n --=20 sean-freebsd@farley.org --0-1396765616-1109117000=:26342--