Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
From: Chris Faylor <cgf AT cygnus DOT com>
Date: Fri, 1 Sep 2000 16:09:04 -0400
To: cygwin developers <cygwin-developers AT sources DOT redhat DOT com>
Subject: Re: sync with children problem
Message-ID: <20000901160904.A29015@cygnus.com>
Reply-To: cygwin-developers AT sources DOT redhat DOT com
Mail-Followup-To: cygwin developers <cygwin-developers AT sources DOT redhat DOT com>
References: <1975989842 DOT 20000901235524 AT logos-m DOT ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.6i
In-Reply-To: <1975989842.20000901235524@logos-m.ru>; from deo@logos-m.ru on Fri, Sep 01, 2000 at 11:55:24PM +0400

On Fri, Sep 01, 2000 at 11:55:24PM +0400, Egor Duda wrote:
>Hi!
>
>  i've  encountered  a  problem  with program doing fork-exec-waitpid,
>namely  cvs  working  via  ssh.  the worst in situation is that when i
>everything  run under strace, problem vanishes (and i guess this means
>we've  got  some  race  here).  maybe child process exits too soon, or
>something  like  that.  snapshot  taken  from  sourceware  ( DLL build
>2000-08-25-23:55-EST)   shows  the  same  behavior.  currently,  as  a
>workaround, i've applied this patch (that looks more like dirty hack),
>just  to  make  things  work,  but i think that such change can likely
>broke something else. any comments?

Yep.  Sorry but the patch makes no sense.  The only effect of calling
proc_can_be_signalled over your change would be to wait for the
signal handler thread to call 'SetEvent (wait_sig_inited)' in the
unpatched version.

If that is never happening, then there is something seriously wrong
somewhere.

Do you have a simple test case for this scenario, even if it takes
a bunch of repetitions to trigger?

cgf

>Index: sigproc.cc
>===================================================================
>RCS file: /home/duda_admin/cvs-mirror/src/winsup/cygwin/sigproc.cc,v
>retrieving revision 1.32
>diff -c -1 -r1.32 sigproc.cc
>*** sigproc.cc  2000/08/26 03:48:37     1.32
>--- sigproc.cc  2000/09/01 18:57:27
>***************
>*** 215,217 ****
>        sigproc_printf ("it's mine, process_state %x", p->process_state);
>!       return proc_can_be_signalled (p);
>      }
>--- 215,217 ----
>        sigproc_printf ("it's mine, process_state %x", p->process_state);
>!       return 1; // proc_can_be_signalled (p);
>      }
>
>Egor. mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19