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?
--
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
