debugging a cygheap leak

Corinna Vinschen
Tue May 20 10:19:00 GMT 2008

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.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-developers mailing list