find(1) memory leak in cygheap

Corinna Vinschen corinna-cygwin@cygwin.com
Thu Aug 20 08:39:00 GMT 2009


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
frequent.

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.


Thanks again,
Corinna

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

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple



More information about the Cygwin mailing list