X-Recipient: archive-cygwin@delorie.com X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org MIME-Version: 1.0 In-Reply-To: <20090820083926.GJ32408@calimero.vinschen.de> References: <20090819140322.GB8713@ednor.casa.cgf.cx> <20090820083926.GJ32408@calimero.vinschen.de> Date: Thu, 20 Aug 2009 18:23:51 +0800 Message-ID: Subject: Re: find(1) memory leak in cygheap From: Haojun Bao To: cygwin@cygwin.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com 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 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