DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 532IGart2930191
Authentication-Results: delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com
Authentication-Results: delorie.com; spf=pass smtp.mailfrom=cygwin.com
DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 532IGart2930191
Authentication-Results: delorie.com;
	dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=ROixfC8N
X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0C318385AC3D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1743617796;
	bh=07sVN3JzmgcLfvYxNvDmnZqT20UVfUmoG5GVu7cB6OU=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	 From;
	b=ROixfC8Nnf0XKNcOvEvuab3TV3IysYO7yTrmzb8Qu/Dey8u0A2vxbgo22ZcjXV3QQ
	 dqNPvRAx5SfTfByf2OtP5nH6n22xxB+j64/S6p/iGLySJRzc0htIroOIYI1Hygmeva
	 7bMHIM/rAE79cAKrzgg+WqecMr2J2qo3mD8dXVnY=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 783953858408
Date: Wed, 2 Apr 2025 20:15:54 +0200
To: cygwin AT cygwin DOT com
Subject: Re: Crashes in cmake subprocesses since 3.6.0
Message-ID: <Z-1-2raM0AN8aSqD@calimero.vinschen.de>
Mail-Followup-To: cygwin AT cygwin DOT com
References: <CAE6_+UfTZc0UTb29p=WVXsP7p7sMmOfmd6SOLR8SCPScJEXHRA AT mail DOT gmail DOT com>
 <7eaea471-d453-efc7-19cc-58e0ee187af0 AT jdrake DOT com>
 <Z-pgTDoHXm9ip53T AT calimero DOT vinschen DOT de>
 <20250402220125 DOT 5d2e1d28cfa37ad934a94ed9 AT nifty DOT ne DOT jp>
 <20250403015216 DOT 3a3d48efb51820b23856225c AT nifty DOT ne DOT jp>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20250403015216.3a3d48efb51820b23856225c@nifty.ne.jp>
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.30
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
Cc: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>

Hi Takashi,

On Apr  3 01:52, Takashi Yano via Cygwin wrote:
> > Currently, I am looking into this problem.
> > 
> > What I noticed so far is:
> > * The problem occurs after the commit 7ed9adb356df.
> > * This problem is happen when fhandler_fifo_pipe::raw_write() returns
> >   error because cygwait(pipe_mtx, timeout) returns WAIT_FAILED. This seems
> >   to happen due to invalid _cygtls::signal_arrived handle for some reason.
> > * The following patch solves the issue.
> > 
> > diff --git a/winsup/cygwin/local_includes/cygtls.h b/winsup/cygwin/local_includes/cygtls.h
> > index f67e9136c..82a34aeca 100644
> > --- a/winsup/cygwin/local_includes/cygtls.h
> > +++ b/winsup/cygwin/local_includes/cygtls.h
> > @@ -228,6 +228,9 @@ public: /* Do NOT remove this public: line, it's a marker for gentls_offsets. */
> >    bool locked ();
> >    HANDLE get_signal_arrived (bool wait_for_lock = true)
> >    {
> > +    DWORD dummy;
> > +    if (signal_arrived && !GetHandleInformation (signal_arrived, &dummy))
> > +      signal_arrived = NULL;
> >      if (!signal_arrived)
> >        {
> >  	if (wait_for_lock)
> > 
> > Of course, this is not the right thing to do, but this clarifies that the
> > cause is _cygtis::signal_arrived being invalid even though it is not NULL.
> > The reason is not quite sure to me.
> > 
> > Any idea?
> 
> The following patch also can solve the issue. The problem seems
> to be related to fork().

So the invalid signal_arrived occurs in the child?

> Perhaps, the timming of calling _cygtls::fixup_after_fork(), that
> clears signal_arrived to NULL, might not be appropriate?

_cygtls::fixup_after_fork() is called in the middle of fork in the
child.  No other thread should be running in the child at the time.
How's it possible that a raw_write is running?

> diff --git a/winsup/cygwin/fork.cc b/winsup/cygwin/fork.cc
> index 0742ab363..793521314 100644
> --- a/winsup/cygwin/fork.cc
> +++ b/winsup/cygwin/fork.cc
> @@ -446,10 +446,14 @@ frok::parent (volatile char * volatile stack_here)
>        impure_beg = _impure_ptr;
>        impure_end = _impure_ptr + 1;
>      }
> +  HANDLE signal_arrived_back;
> +  signal_arrived_back = _my_tls.signal_arrived;
> +  _my_tls.signal_arrived = NULL;
>    rc = child_copy (hchild, true, !*with_forkables,
>  		   "stack", stack_here, ch.stackbase,
>  		   impure, impure_beg, impure_end,
>  		   NULL);
> +  _my_tls.signal_arrived = signal_arrived_back;

Weird.  But if that helps, wouldn't it make sense to keep
_my_tls.signal_arrived at the same value in the parent (signal handling
shouldn't run anyway at that time) and just set _my_tls.signal_arrived
in the child to NULL after child_copy()?

I.e.

    rc = child_copy (...);
    WriteProcessMemory (hchild, (PVOID) &_my_tls.signal_arrived,
			&null_ptr, sizeof null_ptr, NULL);

Still, I wonder in which thread raw_write is running during fork().


Corinna

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple