From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:49164) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RTgCm-00019I-TR for qemu-devel@nongnu.org; Thu, 24 Nov 2011 15:47:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RTgCl-0006ZR-Q6 for qemu-devel@nongnu.org; Thu, 24 Nov 2011 15:47:36 -0500 Message-ID: <4ECEAD32.3070402@weilnetz.de> Date: Thu, 24 Nov 2011 21:46:42 +0100 From: Stefan Weil MIME-Version: 1.0 References: <20111124102712.GA27170@stefanha-thinkpad.localdomain> <4ECE9AED.3070209@weilnetz.de> In-Reply-To: <4ECE9AED.3070209@weilnetz.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-trivial] [PATCH] os-win32.c : fix memory leak List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: qemu-trivial@nongnu.org, Mark , Zhi Hui Li , qemu-devel@nongnu.org Am 24.11.2011 20:28, schrieb Stefan Weil: > Am 24.11.2011 11:27, schrieb Stefan Hajnoczi: >> On Thu, Nov 24, 2011 at 05:15:30PM +0800, Mark wrote: >>> If you free the string, it will cause the environment variable >>> unavailable. >>> More details please see the following text extracted from manual of >>> "putenv": >>> >>> The libc4 and libc5 and glibc 2.1.2 versions conform to >>> SUSv2: >>> the pointer string given to putenv() is used. In particular, this >>> string becomes part of the environment; changing it later will >>> change the environment. (Thus, it is an error is to call putenv() with >>> an automatic variable as the argument, then return from the >>> calling >>> function while string is still part of the environment.) However, >>> glibc 2.0-2.1.1 differs: a copy of the string is used. On >>> the one >>> hand this causes a memory leak, and on the other hand it violates >>> SUSv2. This has been fixed in glibc 2.1.2. >> I don't think this matters since os-win32.c is only built for mingw, >> which uses the Microsoft C runtime and not glibc. >> >> However, there is no documentation for putenv(3) on MSDN because the >> function has been deprecated :(. So I think the safest thing to do is >> to assume this will leak memory but we are not allowed to free the >> string. > > MS claims that putenv is a POSIX function, so I also expected > that free / f_free is not allowed. > > I now wrote a short test which indicates that g_free would work: > getenv returns a pointer which is completely different from > the one passed to putenv. > > Nevertheless, there is a better solution using _putenv_s. > I'll send a patch. > > Regards, > Stefan Weil > Hi Stefan, I'm afraid I was too fast when I promised a patch with _putenv_s. Function _putenv_s is a good solution, but only if it is supported by MinGW. Older versions of MinGW (Debian Squeeze!) don't support it :-( Therefore I suggest to apply this patch. I hope that my test which was run on XP (32 bit) is sufficient. Cheers, Stefan W. Tested-by: Stefan Weil