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=kxBKyK+D2DXb8takVOfW5vzsjOoV+SMFljx46IC8JozII+lo1QzV6
	IanFfAk5A2qAT4ryUT8ORu12qh34UP3t7MUpO9fCtxx2DN5Ga7NMRMzXj8EAwgDh
	IpjTPy0yyw4stp6O9J6hWZ9dcFM6tTHfhS/JsJdFH1Y3ZGa/FNo3UM=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Fri, 21 Nov 2014 15:43:33 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Instability with signals and threads
Message-ID: <20141121144333.GA6633@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <alpine DOT DEB DOT 2 DOT 02 DOT 1411202055420 DOT 8559 AT artax DOT karlin DOT mff DOT cuni DOT cz> <alpine DOT DEB DOT 2 DOT 02 DOT 1411211451420 DOT 108656 AT artax DOT karlin DOT mff DOT cuni DOT cz>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="45Z9DzgjV8m4Oswq"
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1411211451420.108656@artax.karlin.mff.cuni.cz>
User-Agent: Mutt/1.5.23 (2014-03-12)

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


[Please don't CC me, just send mail to the list.  Thank you]


On Nov 21 15:11, Mikulas Patocka wrote:
> > Do you use a DLL built with optimization by any chance?  I wouldn't tak=
e=20
> > the backtraces too serious in that case.  For debugging it helps a lot=
=20
> > to use a Cygwin DLL built without -O2.
>=20
> I use optimization. The stacktrace may contain some other functions that=
=20
> already finished but left the address on the stack.

There may also be functions completely missing on the stack.  I still
suggest to build with -g only.

> > Btw., are you testing on 32 or 64 bit?
>=20
> On 32-bit. The rebuild of cygwin1.dll requires large number of packages t=
o=20
> create the documentation (including tex and java) and I haven't bloated=
=20

Java?!?

> the 64-bit cygwin installation with them yet. I wish it were possible to=
=20
> build the library without documentation and without such big dependecies.

You don't have to build the docs to build the DLL.  The make process
continues even if building the docs fails.

> > I'm testing on 64 bit. I can't reproduce your backtrace, but I can=20
> > reproduce another one, which is related to thread_exit.  At one point=
=20
> > after a couple thousand runs through your testcase I have a variable=20
> > number of threads hanging in thread_exit, and a timer thread which is=
=20
> > unable to send its signal.  the other threads all hang in thread_exit,=
=20
> > waiting for a muto which is taken by a thread which doesn't exist=20
> > anymore.
>=20
> So you can - just for debugging - add a counter to thread local storage=
=20
> that is incremented when muto is taken and decremented when muto is=20
> released. If the thread exists, test the counter, if it is non-zero, prin=
t=20
> the backtrace or attach the debugger.

For instance.

> > That's a very serious downside of the muto implementation not=20
> > being able to recognize being abandoned. I wonder if that shouldn't be=
=20
> > using a real OS mutex.
>=20
> That would hide the problem that a thread is exiting with locked muto, bu=
t=20
> not fix it.

See exit_thread and cgf-000017 in DevNotes.  This setup deliberately
locks the muto and then calls ExitThread.  The signal handler is
supposed to unlock the muto when the __SIGTHREADEXIT signal comes in,
but then it happens that it doesn't for some reason.  It seems the
problem here is that the SIGALRM is filling up the signal pipe so
the __SIGTHREADEXIT signal is not actually delivered.  I have a local
workaround, but it seems to open a can of worms.

I'm going to take a step back for now, and reevaluate what happens
before trying to apply even more hacks.  Ultimately the problem is that
the cygtls area is accessed from other threads (mainly the signal
thread) without locking, and worse, that the lock for the cygtls area is
a member of _cygtls itself.  The latter needs certainly a patch, and I'm
contemplating to extend cygheap::threadlist to become a per-thread
structure containing the _cygtls pointer, the thread ID, the main thread
HANDLE, and the tls muto.  This should allow to serialize access to the
cygtls area in a way which avoids the aforementioned problems without
a complete redesign.


Corinna

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

--45Z9DzgjV8m4Oswq
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUb0+VAAoJEPU2Bp2uRE+gT3YQAJZQtvaeZQBNwZ9FWtOTa4b/
PJUi8p6C0G3eTAub9W6YGupTIuTHhdbsjI1MtQV54dGIfYNclmcTIjZL1cw7sxEZ
ShezcFie1iZ2n99mi0/KASKFbdOTV24jChw28vL+U8io0mQvJnYObqyFgZCaAakC
3ojZdiss7Pm58pVWEkV5cGgJe+xvgDfXiI+S14rLn9ugqtvMgmUdJvzdeLw6jZI8
OruCIAjoKnI4AnLHOYpOr/pQHuh43Is3paWgcl9SKkbjpDeq9kspjyLIuQUIMgHo
FzXB/2OOcExWU3JMJwFVIqkyidgrD3Ni3T5AsHbsnwq44ljIjSoJrqJ6f5A0aBst
SHqvL+WYGP5kZIFHL4RhwaBwi8UIpPHPFd5+t+Rau3sRyz5GM7batRNdfKhhL4lc
2zD/NvCNfiJRRAbvT+YxBlhZG8kqsD1Rrf1QgPtriPjs5TAPdAXnr8h12IzHbKr2
D4oySqkmYoiw6ZxrMh8guAE3GqxA8OiYjnhZzmo05YTZjmPXotBcjbRK+22iedax
GvQkjFVJ1vEuCjNSV3J+Ce3Pp5PyfSW0H2r2RxP/9uG2PGGRfoi+UjS/v9wAznLZ
W0VVL1y0ZoVrn5s++G/942g0ucmCXS6lgYlw7Qf34qTKXIAqjzoJbdr0kz7+jxaE
TPIrb5sU5Ur528B13Omz
=5Qfi
-----END PGP SIGNATURE-----

--45Z9DzgjV8m4Oswq--