Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Date: Sun, 9 Sep 2001 01:43:50 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: vfork problems on Win98 -- is there a fix? Message-ID: <20010909014350.B1936@redhat.com> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.21i On Sat, Sep 08, 2001 at 10:19:14PM -0700, Andrew Kalman wrote: >I have some more data on my vfork problem ... > >The recursive Makefile calls only two programs outside the Cygwin realm -- >picc.exe (a compiler) and libr.exe (the associated librarian). > >I did a test where I called these two programs from an MS-DOS batch file >using the same command-line arguments as I use in the Makefile, and I looped > >it to run continuously. No memory leaks were observed (Win98 machine). > >I then rank Win2000's Task Manager while I ran the Makefile on that machine. > >Physical Memory was reduced by 22MB over the course of 1 hour, during which >140 libraries were built. After 1 hour (59 minutes to be exact), picc.exe >was unable to write a particular object file, and make terminated >abnormally. During this hour, the shell was invoked by make 140 times, make >was called recursively 140 times, there were 140*50 (number of source files) > >= 7,000 calls to picc.exe, and 140 calls to libr.exe. > >>From this I conclude that there's a memory leak in either make, vfork >>(which >I assume is what allows me to invoke the bash shell from inside make), or >the shell itself. > >Am I right? And as before, is there a fix? I don't know if you are right. I am not aware of any fix. Sorry. If this is important to you then you could build debugging versions of make and the cygwin DLL and figure out where the memory was being consumed. Trying to track down where memory leaks occur is always very tricky but maybe you could put some checks in cygwin's fork and spawn_guts routines as a first step. cgf (Cygwin Engineering Manager) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/