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
	=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Date: Tue, 24 Feb 2015 20:37:44 +0200
From: Lasse Collin <lasse.collin@tukaani.org>
To: cygwin@cygwin.com
Subject: Re: Unexpected EINVAL from pthread_join
Message-ID: <20150224203744.085f5b1e@tukaani.org>
In-Reply-To: <20150224152554.GM437@calimero.vinschen.de>
References: <20150222225437.271e929b@tukaani.org>	<20150223121445.GL437@calimero.vinschen.de>	<20150223125914.GO437@calimero.vinschen.de>	<20150223140317.GP437@calimero.vinschen.de>	<20150224155458.33ff024a@tukaani.org>	<20150224152554.GM437@calimero.vinschen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Received-SPF: none

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