From:	newsham AT lava DOT net (Tim Newsham)
Subject:	Re: spawn memory leak?
7 Jun 1998 12:40:06 -0700 :
Message-ID:	<m0yikxf-00113JC.cygnus.cygwin32.developers@malasada.lava.net>
References:	<m0yhhst-001185C AT malasada DOT lava DOT net>
Mime-Version:	1.0
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.

- Raw text -