delorie.com/archives/browse.cgi | search |
X-Recipient: | archive-cygwin AT delorie DOT com |
DomainKey-Signature: | a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id |
:list-unsubscribe:list-subscribe:list-archive:list-post | |
:list-help:sender:mime-version:references:in-reply-to:from:date | |
:message-id:subject:to:cc:content-type; q=dns; s=default; b=XCy4 | |
sMS3HPPyedw1KrR45eIW+xt1/AIRQGU1ipv4ybtPuNakgkZjnSFpqnGOrAned5GJ | |
SxGke2j26/xgrRHanDIsgRCrmIFGQ3OukFoaF2RL4jGryjYYAyuNlReouWUBIyuK | |
dAH9ziBtY0p7/SJHB4EOnoVkfgYdavMOjlXYmpA= | |
DKIM-Signature: | v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id |
:list-unsubscribe:list-subscribe:list-archive:list-post | |
:list-help:sender:mime-version:references:in-reply-to:from:date | |
:message-id:subject:to:cc:content-type; s=default; bh=oQwCHd9dDP | |
kkfIu8PVP4V9r9/Qc=; b=VzM2blVX2wDwZNVvLCQ+8USSEw4Lc0whpY5nukMwHB | |
/Hn6wjuCDw9y5h6FgBMOWQDKKAVQtccd90dscQjp42xVhB+jsoqUDGOjn8N9RFY3 | |
UVWDED/00deD+22n0CvTVe5yxyVjvhpYxORxhHLm6jW/cqtEqsMK73zyFFmGkmOC | |
g= | |
Mailing-List: | contact cygwin-help AT cygwin DOT com; run by ezmlm |
List-Id: | <cygwin.cygwin.com> |
List-Subscribe: | <mailto:cygwin-subscribe AT cygwin DOT com> |
List-Archive: | <http://sourceware.org/ml/cygwin/> |
List-Post: | <mailto:cygwin AT cygwin DOT com> |
List-Help: | <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs> |
Sender: | cygwin-owner AT cygwin DOT com |
Mail-Followup-To: | cygwin AT cygwin DOT com |
Delivered-To: | mailing list cygwin AT cygwin DOT com |
Authentication-Results: | sourceware.org; auth=none |
X-Spam-SWARE-Status: | Yes, score=6.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPAM_BODY,SPF_PASS autolearn=no version=3.3.2 spammy=madison, bray, Bray, dying |
X-HELO: | mail-it1-f180.google.com |
DKIM-Signature: | v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6kED029qpAzJLgFIoMl9TqGYlQdjmky5Xham+E9iHXE=; b=NOcg7ZBl/3MUpCY4qiJuGZ/VWXJyURF6HoGdMay7lgUurkn4vwGPTd7STS0Kqdnui6 QOP3AwIlvMtk2CHIzuE6SiRqls6vhO1jUEbfrCP1yZYo0iw/0D5XnrEOLfGyg74rcJqj VJGJHWoj+2bFa+ptoK054JojX/fxB0HZ6rP65aThOaFkSeH1bqdd3EXej0CvwwH8DoZ1 2dRglorI24aHrMdijvoR3esHNhB2gMrrcXaFBr6V8Tuf1sKuRd81gkl9pXYa/jfjO/Zb DUk8sb9TD01dwQdCzhid1qNFyn4E/9ihcvVXJMQogwnAnzZOE2tc8ebCTjxTWGtuyyWS bSfA== |
MIME-Version: | 1.0 |
References: | <CAJTO8-bD0jPR3Vyr84Z_4BUdh3pPiZ-9ekeMBFUOFJRn5e0wQQ AT mail DOT gmail DOT com> <CAOTD34bXKQSjbce_+qNb-9GaFu88Q3o_Qw0t4oC9yK4+A7eNiA AT mail DOT gmail DOT com> <CAJTO8-ZLqP=_d-zQtFDv=syz4mfsrDRM1YBryrcL_Rp+Wt5q=w AT mail DOT gmail DOT com> |
In-Reply-To: | <CAJTO8-ZLqP=_d-zQtFDv=syz4mfsrDRM1YBryrcL_Rp+Wt5q=w@mail.gmail.com> |
From: | "E. Madison Bray" <erik DOT m DOT bray AT gmail DOT com> |
Date: | Wed, 23 Jan 2019 13:44:11 +0100 |
Message-ID: | <CAOTD34Z_gYcf_X3RDVqL61ME0ZDfti=ToPqm9cxoyTOisz94qg@mail.gmail.com> |
Subject: | Re: Bug: Incorrect signal behavior in multi-threaded processes |
To: | Dan Bonachea <dobonachea AT lbl DOT gov> |
Cc: | cygwin AT cygwin DOT com, gasnet-devel AT lbl DOT gov |
X-IsSubscribed: | yes |
On Tue, Jan 22, 2019 at 9:43 PM Dan Bonachea <dobonachea AT lbl DOT gov> wrote: > > 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. Thank you for the clarification, that does make sense. Per my previous message, the problem with SIGSEGV in particular is (IMO a somewhat serious problem) caused by the fact that Windows apparently does not recognize the stacks allocated for pthreads as valid stacks, so it bypasses SEH entirely, and exceptions like segfaults in threads do not get handled well by Cygwin. I'm less clear on what the problem is with other signals, but it might also be related somehow (though the SIGSEGV problem is obviously more severe since it just results in the process immediately dying (with exit code 0 no less :( > On Tue, Jan 22, 2019 at 6:16 AM E. Madison Bray <erik DOT m DOT bray AT gmail DOT 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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |