From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36632 invoked by alias); 22 Jan 2019 20:43:18 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 36622 invoked by uid 89); 22 Jan 2019 20:43:17 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=4.1 required=5.0 tests=BAYES_00,SPAM_BODY,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 spammy=NOTHING, HCc:D*cygwin.com, 201805, 2018-05 X-HELO: fe4.lbl.gov Received: from fe4.lbl.gov (HELO fe4.lbl.gov) (131.243.228.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 22 Jan 2019 20:43:15 +0000 X-Ironport-SBRS: 2.7 Received: from mail-oi1-f200.google.com ([209.85.167.200]) by fe4.lbl.gov with ESMTP; 22 Jan 2019 12:42:59 -0800 Received: by mail-oi1-f200.google.com with SMTP id s204so11659378oib.11 for ; Tue, 22 Jan 2019 12:42:59 -0800 (PST) Return-Path: Received: from mail-ot1-f49.google.com (mail-ot1-f49.google.com. [209.85.210.49]) by smtp.gmail.com with ESMTPSA id r1sm6789305oti.44.2019.01.22.12.42.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Jan 2019 12:42:57 -0800 (PST) Received: by mail-ot1-f49.google.com with SMTP id s5so24930284oth.7 for ; Tue, 22 Jan 2019 12:42:57 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dan Bonachea Date: Tue, 22 Jan 2019 20:43:00 -0000 Message-ID: Subject: Re: Bug: Incorrect signal behavior in multi-threaded processes To: "E. Madison Bray" Cc: cygwin@cygwin.com, gasnet-devel@lbl.gov Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2019-01/txt/msg00182.txt.bz2 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 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