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

[Stefan Weil <sw@weilnetz.de>]

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 <sw@weilnetz.de>