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=hYnz
	SP+NMmfHiKZQLHSSXPJ7xwHBQv3c6onlK+cqPDEPft7BnTW0YMkiV10MxhKYE04q
	Ts2GPuKPub+N/24ZH0qTCa8LFKDlZmRR8/uvGAX/MO3P5kmVkHq1p0T7L76Pia+J
	oUzvissVF/cDs2Xi36gYt3fcoahE5uIKM0Rvo9s=
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=kLWRfY37fp
	OzlFAj5aPkOM4FRRc=; b=GVtRjyZbWSYKFLxbGNjV5clVI9xQocXWCSBVs29m8x
	D0Y6xtfsQm++VHIHfbHFvwHIez8+aA2gNoXTcTW508o9XjdcLaLpk4SrQE0y1OBu
	8uO6YzlkfX9Cku9bdhtJnNq9zCzLQHS7o71JZDxSZhfRYJZe2upSLokpfX7YMq2A
	w=
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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=interests, wound, controlling, curiosity
X-HELO:	mail-it1-f181.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=MHwzb9v3nGzPj77h21vi1REALSjkdtLTAqf5P3GoVXU=; b=lmUn6XeMJRVcVL3+YvwL2LdrrWmsCdp9qkYctTYrfs11mTV4NEvTzUtpegfbL4juOj QUJa0ZzlluqV34CCS3Em8thpaeYBYGr/v0wmuzW0n/863Ns3oRC03gnw8W7/ZxE6edC1 rOfOxYMWDgA0z/dp0eTkdNstRexIBx0FWlxnt6KmZKNmECvC26kD0G56sbsYsCi8PwQz /1PXBhE93qS9+OqenJyUn5xGFWjRTMUpwT+lxUIWVCiEqy2g+EDHpjLIZGJaOYrvXJ+J +sA+XG3lCf1R5YnnDqXUA8WDCCPh82ZWk1oPdY8CXy8bbWcZ9zfuk2sDoWMJPIUB9FNv gkBw==
MIME-Version:	1.0
References:	<CAJTO8-bD0jPR3Vyr84Z_4BUdh3pPiZ-9ekeMBFUOFJRn5e0wQQ AT mail DOT gmail DOT com>
In-Reply-To:	<CAJTO8-bD0jPR3Vyr84Z_4BUdh3pPiZ-9ekeMBFUOFJRn5e0wQQ@mail.gmail.com>
From:	"E. Madison Bray" <erik DOT m DOT bray AT gmail DOT com>
Date:	Tue, 22 Jan 2019 12:16:39 +0100
Message-ID:	<CAOTD34bXKQSjbce_+qNb-9GaFu88Q3o_Qw0t4oC9yK4+A7eNiA@mail.gmail.com>
Subject:	Re: Bug: Incorrect signal behavior in multi-threaded processes
To:	cygwin AT cygwin DOT com
Cc:	gasnet-devel AT lbl DOT gov, Dan Bonachea <dobonachea AT lbl DOT gov>
X-IsSubscribed:	yes

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 -