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=gZ7Y
	EDz7X+ouN4ucJZmJXFo32fyK/oKzhqsgkFwJhT6rEaYMeSO4fk9YtJDxpqk4Qv5r
	NsEjcHOscek6upB2bdvnucFSQq+KGmpvVGUKghNXdBVt8t65XfQbwzUiatw2OcDf
	+0KeAgKcVA2D1vRZyvAphikiKWbjcNkW6qMsZkI=
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=CqAqh4RCnO
	WIIWg4UqYsr8CosYI=; b=acNaJ7NAInNFDRT+i6bISTYTjWUmz9QWU/wGVhlSLD
	XFbKPpmKTXNg4+DxbO77TwLsgzud1iszfR0irfHFqdlgMquhCsK0O61FbTeFyWRm
	uvPG0nDQUk4/3Y5Y91tcRc2G2VrWogbP9PBaOCcZLeHBz6WeWILAUaiN3RLl8Z3z
	U=
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:	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
X-Ironport-SBRS:	2.7
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>
In-Reply-To:	<CAOTD34bXKQSjbce_+qNb-9GaFu88Q3o_Qw0t4oC9yK4+A7eNiA@mail.gmail.com>
From:	Dan Bonachea <dobonachea AT lbl DOT gov>
Date:	Tue, 22 Jan 2019 15:42:19 -0500
Message-ID:	<CAJTO8-ZLqP=_d-zQtFDv=syz4mfsrDRM1YBryrcL_Rp+Wt5q=w@mail.gmail.com>
Subject:	Re: Bug: Incorrect signal behavior in multi-threaded processes
To:	"E. Madison Bray" <erik DOT m DOT bray AT gmail DOT com>
Cc:	cygwin AT cygwin DOT com, gasnet-devel AT lbl DOT 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 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

- Raw text -