This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: debugging a cygheap leak
- From: Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>
- To: cygwin-developers at cygwin dot com
- Date: Thu, 1 May 2008 12:10:52 -0400
- Subject: Re: debugging a cygheap leak
- References: <4819B647.3000805@byu.net>
- Reply-to: cygwin-developers at cygwin dot com
On Thu, May 01, 2008 at 06:23:35AM -0600, Eric Blake wrote:
> The m4 development head has a test where it repeatedly loads and unloads a
> dynamic module using libtool to wrap dlopen() and friends. This is working
> fine under 1.5.x, with no memory growth after the first reload. But in
> 1.7.0, memory usage continually grows, then the test is crashing after
> about 1700 iterations with a call to api_fatal,
>
> 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. But with my self-built cygwin1.dll and cygwin1.dbg, I
> don't know where to set a breakpoint to catch it - trying 'b api_fatal'
> fails. Meanwhile, I'll continue trying to come up with a STC that doesn't
> involve the entire m4/libtool wrapper around dlopen.
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.
cgf