Re: find(1) memory leak in cygheap

2009-08-20 Thread Haojun Bao
On Wed, Aug 19, 2009 at 11:04 PM, Haojun Baobaohao...@gmail.com wrote: On Wed, Aug 19, 2009 at 10:03 PM, Christopher Faylorcgf-use-the-mailinglist-ple...@cygwin.com wrote: On Wed, Aug 19, 2009 at 07:47:37PM +0800, Haojun Bao wrote: I found this problem when running updatedb, the find will print

Re: find(1) memory leak in cygheap

2009-08-20 Thread Corinna Vinschen
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

Re: find(1) memory leak in cygheap

2009-08-20 Thread Haojun Bao
On Thu, Aug 20, 2009 at 4:39 PM, Corinna Vinschencorinna-cyg...@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

Re: find(1) memory leak in cygheap

2009-08-20 Thread Corinna Vinschen
On Aug 20 18:23, Haojun Bao wrote: On Thu, Aug 20, 2009 at 4:39 PM, Corinna Vinschencorinna-cyg...@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

Re: find(1) memory leak in cygheap

2009-08-20 Thread Dave Korn
Haojun Bao wrote: 215 path_conv operator =(path_conv pc) 216 { 217memcpy (this, pc, sizeof pc); Ow yuck! I very much hope nobody ever creates derived classes of path_conv that introduce virtual functions into the base class, or we're going to have a very tricky to find bug here.

Re: find(1) memory leak in cygheap

2009-08-20 Thread Corinna Vinschen
Oh, btw., please http://cygwin.com/acronyms/#PCYMTNQREAIYR On Aug 20 13:19, Corinna Vinschen wrote: On Aug 20 18:23, Haojun Bao wrote: 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

Re: find(1) memory leak in cygheap

2009-08-20 Thread Greg Chicares
On 2009-08-20 11:54Z, Dave Korn wrote: [...] (Hmm, now there's an idea. GCC needs an __attribute__ that you can tag onto a class to say it must be a POD-type and get a compiler error if anyone ever adds a virtual function or anything else that would make the layout non-POD.)

Re: find(1) memory leak in cygheap

2009-08-20 Thread Dave Korn
Greg Chicares wrote: On 2009-08-20 11:54Z, Dave Korn wrote: [...] (Hmm, now there's an idea. GCC needs an __attribute__ that you can tag onto a class to say it must be a POD-type and get a compiler error if anyone ever adds a virtual function or anything else that would make the layout

Re: find(1) memory leak in cygheap

2009-08-20 Thread Christopher Faylor
On Thu, Aug 20, 2009 at 04:01:44PM +0100, Dave Korn wrote: Greg Chicares wrote: On 2009-08-20 11:54Z, Dave Korn wrote: [...] (Hmm, now there's an idea. GCC needs an __attribute__ that you can tag onto a class to say it must be a POD-type and get a compiler error if anyone ever adds a virtual

find(1) memory leak in cygheap

2009-08-19 Thread Haojun Bao
I found this problem when running updatedb, the find will print 2 [main] find 2592 C:\cygwin\bin\find.exe: *** fatal error - cmalloc would have returned NULL I have dumped the cygheap using gdb to see what's in it, the size is about 25M, and I use strings.exe to examine the strings in it,

Re: find(1) memory leak in cygheap

2009-08-19 Thread Christopher Faylor
On Wed, Aug 19, 2009 at 07:47:37PM +0800, Haojun Bao wrote: I found this problem when running updatedb, the find will print 2 [main] find 2592 C:\cygwin\bin\find.exe: *** fatal error - cmalloc would have returned NULL I have dumped the cygheap using gdb to see what's in it, the size is