This is the mail archive of the
mailing list for the Cygwin project.
Re: find(1) memory leak in cygheap
On Aug 20 14:09, Haojun Bao wrote:
> I have done some debugging, and the culprit should be dup(2) syscall.
> Here's another test case, this time written in C.
> Note that the cygheap_start and cygheap_max value will be very likely
> different on your computer, so you should use gdb to take a peek into
> cygwin1.dll to get your value. Or else you should remove the reference
> to these memory location.
> The test case will show cygheap is always growing, and at the end it will print
> 1 [main] a 3560 Q:\a.exe: *** fatal error - cmalloc would have returned NULL
Thanks for the testcase! It was pretty easy to find the culprit with
it. Deep in dup(), the strings for the filenames of the new file
descriptor were allocated twice. While I was at it, I also found two
other potential memory leaks, which would just show up much less
This fixes your find testcase as well, and probably (hopefully?) also
the problem reported in http://cygwin.com/ml/cygwin/2009-08/msg00620.html
I applied a patch to CVS and will upload a -60 release asap.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple