Mail Archives: cygwin/2009/08/20/06:24:09
On Thu, Aug 20, 2009 at 4:39 PM, Corinna
Vinschen<corinna-cygwin AT cygwin DOT 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 wil=
l print
>> =A0 1 [main] a 3560 Q:\a.exe: *** fatal error - cmalloc would have retur=
ned NULL
>
> Thanks for the testcase! =A0It was pretty easy to find the culprit with
> it. =A0Deep in dup(), the strings for the filenames of the new file
> descriptor were allocated twice. =A0While 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 =3D(path_conv& pc)
216 {
217 memcpy (this, &pc, sizeof pc);
218 path =3D cstrdup (pc.path);
219 set_normalized_path (pc.normalized_path);
220 wide_path =3D 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
- Raw text -