On Wed, 2 Apr 2025 22:01:25 +0900
Takashi Yano via Cygwin <cygwin@cygwin.com> wrote:
> Hi Corinna,
>
> On Mon, 31 Mar 2025 11:28:44 +0200
> Corinna Vinschen wrote:
> > On Mar 30 22:58, Jeremy Drake via Cygwin wrote:
> > > On Mon, 31 Mar 2025, Christoph Reiter via Cygwin wrote:
> > >
> > > > Starting with 3.6.0 when cmake calls into make/ninja/gcc there is a
> > > > chance of
> > > > that failing, for example like this:
> > > >
> > > > CMake Error: Generator: build tool execution failed, command was:
> > > > /usr/bin/cmake.exe -E env VERBOSE=1 /usr/bin/make.exe -f Makefile
> > > > cmTC_c87e2/fast
> > > >
> > > > * Problem starts with cygwin 3.6.0
> > >
> > > I've also reproduced this with cygwin 3.7.0-0.19.g6c5537c0298e, but it
> > > doesn't reproduce as readily as with cygwin 3.6.0-1.
> >
> > Yes, I can reproduce fails as well, but I don't see an easy way to
> > debug this. Your testcase just fails but runs along afterwards.
> >
> > I'm completely cmake-illiterate, which isn't a great help either.
> >
> > Two points:
> >
> > - It's unlikely that this occurs only with 3.6.0-1 and later. It's more
> > likely that it occurs on the way from 3.5 to 3.6. Unfortunately the
> > remaining 3.6.0 test builds are only going back to patchlevel 429 or
> > so.
> >
> > Any chance one of you could bisect Cygwin and find out which commit
> > introduced the problem?
> >
> > - Also, since this seems to affect certain cmake versions only, can the
> > cmake maintainers help here, perhaps?
>
> 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().
Perhaps, the timming of calling _cygtls::fixup_after_fork(), that
clears signal_arrived to NULL, might not be appropriate?
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;
__malloc_unlock ();
locked = false;
--
Takashi Yano <takashi.y...@nifty.ne.jp>
--
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
