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.b...@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
