From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40679) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RTezB-0002df-5q for qemu-devel@nongnu.org; Thu, 24 Nov 2011 14:29:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RTezA-0000xj-BD for qemu-devel@nongnu.org; Thu, 24 Nov 2011 14:29:29 -0500 Message-ID: <4ECE9AED.3070209@weilnetz.de> Date: Thu, 24 Nov 2011 20:28:45 +0100 From: Stefan Weil MIME-Version: 1.0 References: <20111124102712.GA27170@stefanha-thinkpad.localdomain> In-Reply-To: <20111124102712.GA27170@stefanha-thinkpad.localdomain> 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 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