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
