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:date:from:to:subject:message-id:in-reply-to
	:references:mime-version:content-type:content-transfer-encoding;
	 q=dns; s=default; b=nFnByridOXj8ituAIh06HBv4IUc2bsLLSGIep42F16I
	0MWbW0+8vg3eTTpDk0TuLlFB3hRQZF0IXtFOHAFEu0fQ0eu82JzhumEfmUm9CaHn
	+KwQoQFhXQUoKoz11tRjqYJYLYjPDbJaNvY0qfFLfQ0ZHKSKKbxC7FPZE7aNZVwM
	=
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:date:from:to:subject:message-id:in-reply-to
	:references:mime-version:content-type:content-transfer-encoding;
	 s=default; bh=FhC8husOUeCQb8rgBMW15GRRWWQ=; b=XYM1FM/6NUbFEiwy4
	cJH6CduekQkyZ9v1xz1wTYOCUIvPxjdO2WMi/4GGjfPdiInarjRo1N6eB69SNL2v
	Xbe37BNvEPDIydK7ZzvUzJk5xyL4Q0+Q1QuK4u6+X+/r3yEERmuR1DEv2fWgKTzQ
	0ltf9s1nnPTFKdEGw+Su+/QCJ8=
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-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2
X-HELO: mailscanner02.zoner.fi
Date: Tue, 24 Feb 2015 20:37:44 +0200
From: Lasse Collin <lasse DOT collin AT tukaani DOT org>
To: cygwin AT cygwin DOT com
Subject: Re: Unexpected EINVAL from pthread_join
Message-ID: <20150224203744.085f5b1e@tukaani.org>
In-Reply-To: <20150224152554.GM437@calimero.vinschen.de>
References: <20150222225437 DOT 271e929b AT tukaani DOT org>	<20150223121445 DOT GL437 AT calimero DOT vinschen DOT de>	<20150223125914 DOT GO437 AT calimero DOT vinschen DOT de>	<20150223140317 DOT GP437 AT calimero DOT vinschen DOT de>	<20150224155458 DOT 33ff024a AT tukaani DOT org>	<20150224152554 DOT GM437 AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Antivirus-Scanner: Clean mail though you should still use an Antivirus
Received-SPF: none
X-IsSubscribed: yes

On 2015-02-24 Corinna Vinschen wrote:
> On Feb 24 15:54, Lasse Collin wrote:
> > Many other pthread functions are similar in sense that they must
> > never return EINTR. A bug similar to the one in pthread::join exist
> > in pthread_mutex::lock. If SA_RESTART isn't used, signals can make
> > multiple threads get a lock on the same mutex at the same time. A
> > test program is attached. Adding cw_sig_restart to the cygwait call
> > in pthread_mutex::lock fixes this.
> 
> Can you collect the info which functions are affected so that lazy me
> just has to apply the cw_sig_restart patches in bulk?

I grepped for cygwait uses earlier but I don't understand the code well
enough to be sure about anything. The following is pretty much
guessing, but hopefully there's something useful still.

These look the most suspicious to me, possibly needing cw_sig_restart:

    thread.h          fast_mutex::lock
    fhandler_tape.cc  fhandler_dev_tape::_lock

When looking for things needing cw_sig_restart, I started to wonder if
cw_sig_eintr is used properly in all cases. Often the caller of
cygwait + cw_sig_eintr will also conditionally call
_my_tls.call_signal_handler, but the following functions don't. The
comment in handle_sigsuspend makes me think that this may be a false
alarm but I mention these just in case.

    exceptions.cc     handle_sigsuspend
    posix_ipc.cc      ipc_mutex_lock
    signal.cc         clock_nanosleep
    signal.cc         sigwaitinfo
    thread.cc         pthread_cond::wait
    thread.cc         semaphore::_timedwait
    thread.cc         semaphore::_wait

In the following functions the situation is kind of reversed. Those
functions call _my_tls.call_signal_handler even though cw_sig_eintr
wasn't specified. cygwait will already have called the signal handler
since cw_sig has been specified via cygwait(DWORD). So I guess in these
functions the signal handler might get called twice.

    fhandler_dsp.cc   fhandler_dev_dsp::Audio_out::waitforspace
    fhandler_dsp.cc   fhandler_dev_dsp::Audio_in::waitfordata

-- 
Lasse Collin  |  IRC: Larhzu @ IRCnet & Freenode

--
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