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
