From owner-freebsd-current@FreeBSD.ORG Fri Apr 20 00:31:21 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A5F9116A406 for ; Fri, 20 Apr 2007 00:31:21 +0000 (UTC) (envelope-from sean-freebsd@farley.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id 7422013C45D for ; Fri, 20 Apr 2007 00:31:21 +0000 (UTC) (envelope-from sean-freebsd@farley.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l3K0Fe2x040228 for ; Thu, 19 Apr 2007 19:15:40 -0500 (CDT) (envelope-from sean-freebsd@farley.org) Date: Thu, 19 Apr 2007 19:14:56 -0500 (CDT) From: "Sean C. Farley" To: freebsd-current@freebsd.org Message-ID: <20070419175902.R44041@thor.farley.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Fix for memory leak in setenv/unsetenv (take 2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 00:31:21 -0000 I have a new patch[1] that fixes memory leaks caused by repeated calls to setenv() with varying-sized values or unsetenv(). The web page has a better description about it. I tested this with -STABLE with various applications. Also, to help check it further, I wrote a few regression tests for it. Notes/questions I have: 1. Would making it more IEEE Std 1003.1-compliant be desired? a. FreeBSD's setenv() allows an '=' in the name and value to comply with other standards while this standard disallows it. b. FreeBSD's unsetenv() does not have a return value while this standard returns an int. For the changes I made, this would be beneficial. 2. The "feature"--it is under the BUGS section :)--of keeping all pointers returned by previous calls to getenv() valid regardless of any calls to setenv() is still there. Keeping this requirement prevents a complete fix. 3. I previously thought about having the implementation initialize itself upon the library loading or called within crt1.c. The problem with a library-load time method is that changes made to the environ variable do not persist at the execution of main(). The issue with calling it within crt1.c is that FreeBSD's malloc() would need to call __findenv_environ() to find MALLOC_OPTIONS when it is initialized to prevent a recursion into each other. jasone@ helped me look at this. 4. Ignore dmalloc defines for now; they will be removed. Basically, the patch contains sysenv.c and a change to the Makefile to remove building of putenv.c and setenv.c. To increase the speed of putenv(), I have moved it into sysenv.c to make use of some internal (static) functions. I have just started with it, but I may leave it alone. Please let me know if you see any bugs. Sean 1. http://www.farley.org/freebsd/tmp/setenv-6/ -- sean-freebsd@farley.org