On Wed, 2 Apr 2025 20:15:54 +0200
Corinna Vinschen wrote:
> 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?
Yes.
> > 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);
This does not work (ERROR_PARTIAL_COPY), however, the following
works.
diff --git a/winsup/cygwin/fork.cc b/winsup/cygwin/fork.cc
index 0742ab363..e11a7d507 100644
--- a/winsup/cygwin/fork.cc
+++ b/winsup/cygwin/fork.cc
@@ -450,10 +450,15 @@ frok::parent (volatile char * volatile stack_here)
"stack", stack_here, ch.stackbase,
impure, impure_beg, impure_end,
NULL);
+ SIZE_T nb;
+ _cygtls tls1;
+ tls1 = _my_tls;
+ tls1.signal_arrived = NULL;
+ WriteProcessMemory (hchild, (PVOID) &_my_tls, &tls1, sizeof (tls1), &nb);
__malloc_unlock ();
locked = false;
- if (!rc)
+ if (!rc || nb != sizeof (tls1))
{
this_errno = get_errno ();
error ("pid %u, exitval %p", pi.dwProcessId, ch.exit_code);
> Still, I wonder in which thread raw_write is running during fork().
Weird enough, raw_write() is called in the main thread (_main_tls).
Any chance, fixup_after_fork() is not called?
--
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
