From: cgf AT cygnus DOT com (Christopher Faylor)
Subject: Re: spawn memory leak?
7 Jun 1998 14:26:03 -0700
Message-ID: <199806072056.QAA25465.cygnus.cygwin32.developers@kramden.cygnus.com>
To: newsham AT lava DOT net, sos AT prospect DOT com DOT ru
Cc: cygwin32-developers AT cygnus DOT com

>From: newsham AT lava DOT net (Tim Newsham)
>Date: Sun, 7 Jun 1998 10:31:23 -1000 (HST)
>
>> 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 :)

As Sergey has pointed out, there is no need to walk the file handle
array twice.  This should be handled in the delinearize code.

-Chris