From: newsham AT lava DOT net (Tim Newsham) Subject: Re: spawn memory leak? 7 Jun 1998 13:45:03 -0700 Message-ID: References: <01BD9273 DOT 355A3300 AT sos> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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.