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:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=tR3kzdm09Oaivf35o6OZpvaMa3AAaF+x4O6SqfTCsdyQf2f5SHwEL
	A1Dvqky5RJmtHHpiEohzsw+Y7wFV28ifH/SfAxd3Qj3+RrJ1O3HGXl4SJOwOVMOs
	OJ8pl+Y+oBm9rT82Feu8chDl9ffG1s72RM+TIqXbiU73lPEywzcJfA=
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:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	 bh=XYh/ZMhpHx8rb/AGHbwI8Jf2aKA=; b=w1yocV+fCUoV1AaqYpPnb+XpGZYW
	ew3iQa6o9ya7SOXIixAWd3QsUhkL0z5vxl/GFAtlDQSginl/8lHpePBLgcFQKwYM
	i6WaPn/yk4HHSiZfgZXmOOIykD+WtQKTzxUy1s3UfPXm4LUX2Oyn6Al4yDEO40dU
	8zQsmZMlO0cHnpo=
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=-5.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2
X-HELO: calimero.vinschen.de
Date: Tue, 24 Feb 2015 22:20:21 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Unexpected EINVAL from pthread_join
Message-ID: <20150224212021.GQ437@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
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> <20150224203744 DOT 085f5b1e AT tukaani DOT org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="ByWDhVrfOLxO82cA"
Content-Disposition: inline
In-Reply-To: <20150224203744.085f5b1e@tukaani.org>
User-Agent: Mutt/1.5.23 (2014-03-12)

--ByWDhVrfOLxO82cA
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Lasse,

On Feb 24 20:37, Lasse Collin wrote:
> 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.
> >=20
> > Can you collect the info which functions are affected so that lazy me
> > just has to apply the cw_sig_restart patches in bulk?
>=20
> 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.
>=20
> These look the most suspicious to me, possibly needing cw_sig_restart:
>=20
>     thread.h          fast_mutex::lock
>     fhandler_tape.cc  fhandler_dev_tape::_lock
>=20
> 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.
>=20
>     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

The signal code has gone through a couple of iterations so there's a
chance that some places do useless stuff; detritus from former
iterations.

> 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.
>=20
>     fhandler_dsp.cc   fhandler_dev_dsp::Audio_out::waitforspace
>     fhandler_dsp.cc   fhandler_dev_dsp::Audio_in::waitfordata

Cool, thanks for looking so closely.  I wasn't expecting that, rather
just a look through the pthread functions but this is very helpful.
I'll check these code snippets in the next couple of days, maybe even
tomorrow.


Thanks again,
Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--ByWDhVrfOLxO82cA
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJU7OsVAAoJEPU2Bp2uRE+gTcIQAIKCi5y+BElBNtonYQbY3hWw
euyZ7If7xKUmd5ZU/wLL1NubA/qrUAZzMM/JBhVMkjxllzUYAUZHqaLTObHGmHRb
27hKu5gEKpbqHMugkFeKmeEHvpODXKZYvYU/2eogcCbX5Zyv0R2aVwjSlQVJdsZP
OW9TQm7mDiiLzuYMx4SaLhLmXs3Tjpqi9t1J3Kzub6W1d9gDrdHWqU3KMAJPu48s
mjWkjamvkV1EDlw+gCalPeb3PHwJ9cwdGw5Zcze+IGBMIZEGoG8rJ7bDhyH4eGva
E8TlsP8sQDmum/lNFLCYcpSTb0TS0EQmEbfT4T9bQhSEgGNB7yR4GFzOW1rP8H2H
h7kLsoMOgPJ+7ry2TpLjt2NqLNjuU2C8957MrtI7vx4R0iFvaeH8TyYecNpyegKI
8u8eClmm6EEwmdUCjTBdPEI1svmkFF5N/mdSonERPg428559Pte+bzcLIfBgDbD/
x4R/05IN7M4/VqwZau4BUZeqX4B83hjY+FcHlmGSH/AGqnP37j5wod8DvvTDM7j+
ygQiXfuTCJuiPpHJ0RrPix+yim0QGylaOVDc++q8V99RPVnH9RVdRUasEm8FfZ/c
TULHg9iZ3QcprhHN6bPIZFoGFcYnaKRJ2Assoi1R5nNDFv7uV7vWl2uKwFMH7TE7
TGmoamkEDXwd5h8qbfzg
=HB6C
-----END PGP SIGNATURE-----

--ByWDhVrfOLxO82cA--