This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: debugging a cygheap leak
On May 19 20:14, Eric Blake wrote:
> According to Christopher Faylor on 5/1/2008 10:10 AM:
>>> 1 [main] m4 18392
>>> \\?\C:\cygwin\home\eblake\m4-head\build\src\.libs\m4.exe: *** fatal
>>> error - cmalloc would have returned NULL
>>>
>>> Any ideas on how to go about debugging this? It looks like a memory leak
>>> regression in 1.7.0.
>> Build the DLL with --enable-debugging and CFLAGS=-g, if you can isolate
>> the test to just one invocation of m4 then:
>> set CYGWIN_DEBUG=m4
>> and do a backtrace from there.
>
> Thanks. I finally isolated it, and it is a true leak in cygwin1.dll.
> path_conv has some bugs - it fails to zero-initialize various members in
> some constructor paths. It also uses path_conv::check() for two purposes -
> as part of the constructor, but also for subsequent expansion of the object
> with more details. Therefore, in the current code base, it is impossible
> to know whether check() has previously been called, because you can't tell
> whether the pointer is uninitialized or previously allocated.
>
> This patch shows that path_conv::check() is being called more than once, in
> at least one code path triggered by dlopen(). And, since each invocation
> of check() blindly resets wide_path and normalized_path to NULL, this leads
> to cmalloc leaks if the previous call happened to allocate these fields. I
> still haven't managed to trim the m4/libtool testcase into something
> smaller, but hopefully this backtrace helps you spot a way to fix the
> problem.
>
> The correct patch should not need the addition of 'bool built' (hence, I'm
> posting here and not the -patches list, and no ChangeLog); rather, it is to
> demonstrate the bug.
I've applied a patch which should fix that. Please give it a try.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat