From: newsham AT lava DOT net (Tim Newsham) Subject: Re: spawn memory leak? 7 Jun 1998 12:40:06 -0700 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit To: newsham AT lava DOT net (Tim Newsham) Cc: cygwin32-developers AT cygnus DOT com > I believe there is a memory leak in the spawn code somewhere. So far > we haven't been able to track it down. We wrote a test case that [...] This bug was tracked down and it looks like Faylor committed the patch already in the last snapshot (according to the change log, I havent seen the code yet). ---- Another spawn related fix -- I added a call to "myself->init_from_exec()" from dcrt0 (after sockets are initialized, else error), to force cygwin to close down any leftover close-on-exec handles that may have made their way from the last process (for example, when using spawn without the overlay option, the file handles are not marked as closed). Note: simply setting the handles as non-inheritable is not enough! I tried this first, and while the handles arent inherited, cygwin still passes down the file descriptor table entries! So... those fd slots will still be unuseable until closed. For those who cry "this only works for cygwin processes!", yes, true, but it is better than not working at all. BUT... there seems to be a way to do close-on-exec even when spawn()'ing non cygwin programs: foreach close-on-exec fd save old handle flags set handle flag to non-inheritable build new fd table for child process without entries for these fd's CreateProcess, passing down new table (not simply passing dup of parents) foreach close-on-exec fd set handle flag to saved value this of course only works on systems that support the SetHandleInformation call, but imo, its better than not supporting it on any system at all. Tim N.