[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-trivial] [Qemu-devel] [PATCH] os-win32.c : fix memory leak

From: Stefan Weil
Subject: Re: [Qemu-trivial] [Qemu-devel] [PATCH] os-win32.c : fix memory leak
Date: Thu, 24 Nov 2011 21:46:42 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20111110 Iceowl/1.0b1 Icedove/3.0.11

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

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

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.

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.

Stefan W.

Tested-by: Stefan Weil <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]