find(1) memory leak in cygheap

[Haojun Bao]

On Thu, Aug 20, 2009 at 4:39 PM, Corinna
Vinschen<corinna-cygwin@cygwin.com> wrote:
> 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
>
Great. In fact, I also found this code myself might cause problem in path.h:
(we should test if path is NULL, and free it before the memcpy, and
other member pointers should also be checked and free-ed first, is it
about right?:-)

215  path_conv &operator =(path_conv& pc)
216  {
217    memcpy (this, &pc, sizeof pc);
218    path = cstrdup (pc.path);
219    set_normalized_path (pc.normalized_path);
220    wide_path = NULL;
221    return *this;
222  }

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