From:	newsham AT lava DOT net (Tim Newsham)
Subject:	Re: spawn memory leak?
7 Jun 1998 13:45:03 -0700 :
Message-ID:	<m0yim67-0010zOC.cygnus.cygwin32.developers@malasada.lava.net>
References:	<01BD9273 DOT 355A3300 AT sos>
Mime-Version:	1.0
To:	sos AT prospect DOT com DOT ru (Sergey Okhapkin)
Cc:	newsham AT lava DOT net, cygwin32-developers AT cygnus DOT com

> I see another simple solution - functions pinfo::init_from_exec() and 
> hinfo_vec::dup_for_exec() should be removed, and 
> hinfo_vec::linearize_fd_array() should be modified to ignore fds with 
> close_on_exec set. The single line will be modified (hinfo.cc, line 413):
> 
> from
>       if (vec[i].is_open ())
> to
>       if (vec[i].is_open () && !vec[i].h->get_close_on_exec ())

Yes, this is what I had in mind,  but in addition you have to
set the handle flag to non-inherited to prevent the child from
inheriting the handle.  Then you have to set the flag back
to normal afterwards (after the CreateProcess) to let handles
be inherited across fork() operations.

> This will solve a problem with a failing spawn()/exec() also. But one more 
> problem will arise - the os handles of these fds will be inheritted by 
> spawned child :-( Probably, it would be better to leave linearize_fd_array 
> unchanged an handle these fds in a child's delinearization code?

This is what my patch currently ammounts to -- when dcrt0 starts
up, it walks the fd table and closes any fd's that should have
been closed at exec time.  This works perfectly well with cygwin
processes.  Some other people earlier voiced concern that this
doesn't work with non-cygwin programs which is a valid concern (but
not my concern, since I never run non-cygwin processes :)

> Sergey Okhapkin, http://www.lexa.ru/sos

                                       Tim N.

- Raw text -