This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: find(1) memory leak in cygheap

On Thu, Aug 20, 2009 at 4:39 PM, Corinna
Vinschen<> 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
> 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:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]