Re: Bug: Incorrect signal behavior in multi-threaded processes

[Dan Bonachea <dobonachea@lbl.gov>]

Hi Corinna and Madison, thanks for your responses.

To clarify, I'm reasonably confident the problem I'm reporting has
NOTHING to do with pthread_barrier. Our real application which
exhibits very similar symptoms does not use pthread_barrier *at all*;
pthread_barrier was merely the most convenient/concise synchronization
mechanism to produce deterministic output behavior in the minimal
example.

Indeed, when I comment out the pthread_barrier code entirely from the
example program (causing unselected non-primordial threads to exit and
the primordial thread to stall in pthread_join), I see substantially
the same misbehaviors.

Thanks,
-Dan Bonachea

On Tue, Jan 22, 2019 at 6:16 AM E. Madison Bray <erik.m.bray@gmail.com> wrote:
>
> On Sun, Jan 20, 2019 at 9:34 PM Dan Bonachea wrote:
> >
> > I'm writing to report some POSIX compliance problems with Cygwin
> > signal handling in the presence of multiple pthreads that our group
> > has encountered in our parallel scientific computing codes.
> >
> > A minimal test program is copied below and also available here:
> > https://upc-bugs.lbl.gov/bugzilla/attachment.cgi?id=589
> >
> > I believe the test program is fully compliant with ISO C 99 and POSIX
> > 1003.1-2016. In a nutshell, it registers one signal handler, spawns a
> > number of pthreads, and then synchronously generates a signal from
> > exactly one thread while others sit in a pthread_barrier_wait. The
> > "throwing" thread and signal number can be varied from the command
> > line, and diagnostic output indicates what happened.
> >
> > As a basis for comparison, here are a few examples of the test program
> > running on x86_64/Linux-3.10.0(Scientific Linux 7.4)/gcc-4.8.5
> > demonstrating what I believe to be the *correct*/POSIX-required
> > behavior:
>
> Thank you for the detailed analysis of this problem.  I haven't
> personally encountered a problem like this in any of my own code,
> though I'm not relying on pthread_barrier, or signal handlers being
> run from specific threads.  This is relevant to my interests though,
> so time permitting I might look into it just out of curiosity of
> nothing else.  The behavior with SIGSEGV in particular is very
> reminiscent (possibly same as) a problem I reported last year, but
> never got around to fixing (except for the local workaround I used):
> https://cygwin.com/ml/cygwin/2018-05/msg00333.html
>
> I wonder if the same problem applies to thread-local stacks.  Indeed,
> I ran your test program in gdb with arguments (1, 11) with a
> breakpoint in myfault_altstack_handler [1] and wound up there.  But
> since the segfault did not come from Cygwin itself (me.andreas is a
> "san" fault handler for the current exception being handled by Cygwin,
> but this is only set for exceptions generated by Cygwin itself (with
> its __try/__except blocks).  In this case it's 0x0 so the exception is
> not handled and the process just runs off into the weeds until it
> (quickly) runs out of "vectored continue handlers" and so the process
> exits (at the Windows level, without Cygwin controlling its shutdown).
>
> For the other cases I'm not as sure what's going on, but possibly
> related problems.
>
> [1] https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/exceptions.cc;h=205ad850e4c7b69954fadd1efe3ae9ff65e5f806;hb=HEAD#l594

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