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=hF6ZMQAlasfUng9hdBafett7xONT59saqmggaMoqWL/UJDflJnie/
	XNaZGCgoEbxNV8U6i3rt/HjNMiSJ33oVw39IbMb3CGlb3WbXGhqtmbMKAIDeTDTc
	ELUpjymJtV7UYluHRHKCeVG4OTWarQbi6h0rZDI3WFjEEcBBrq4i30=
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=3Al7rQbIZUKQhKwVxnJpky5jaiQ=; b=LTZSNAiglmDo7GduiOPbJnyQd7TI
	UAxXQdIPhs4lV4yzst1U1g3qTeycw5X3qPqfyh+tzeqo2PVLM7CY58HyQXZsyfFJ
	CG95QvuCsCNWPZ65LBLrt+rx8AWLjkbJMkoP5sWZiG5Rht3EF6pw00DtZX83kYwj
	bK04kaId962IuH8=
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: Fri, 24 Oct 2014 11:46:27 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Threads
Message-ID: <20141024094627.GF20607@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <54450835 DOT 3050602 AT cornell DOT edu> <5448E6F9 DOT 8040005 AT dronecode DOT org DOT uk> <5448EEBF DOT 3020706 AT cornell DOT edu> <20141023153730 DOT GC20607 AT calimero DOT vinschen DOT de> <544965F4 DOT 207 AT cornell DOT edu> <5449A638 DOT 3080003 AT cornell DOT edu>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="4f28nU6agdXSinmL"
Content-Disposition: inline
In-Reply-To: <5449A638.3080003@cornell.edu>
User-Agent: Mutt/1.5.23 (2014-03-12)

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

On Oct 23 21:07, Ken Brown wrote:
> On 10/23/2014 4:32 PM, Ken Brown wrote:
> >On 10/23/2014 11:37 AM, Corinna Vinschen wrote:
> >>On Oct 23 08:04, Ken Brown wrote:
> >>>On 10/23/2014 7:31 AM, Jon TURNEY wrote:
> >>>>On 20/10/2014 14:03, Ken Brown wrote:
> >>>>>Or is there some other plausible explanation for "impossible" crashe=
s?
> >>>>>This can't just be a result of a gdb bug, because in at least one ca=
se
> >>>>>the assertion can be shown to be valid by using printf instead of gd=
b.
> >>>>>
> >>>>>[*] By "impossible" I mean that examination of the relevant
> >>>>>variables in
> >>>>>gdb shows that the assertions are in fact true.  Two ongoing
> >>>>>examples are
> >>>>>
> >>>>>    http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D18438
> >>>>>    http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D18769
> >>>>
> >>>>As a suggestion, you might want to also take a careful look at how
> >>>>signal
> >>>>delivery is implemented in cygwin on x86_64
> >>>>
> >>>>I had a vague idea that there was, at some time in the past, a fix
> >>>>made for
> >>>>register corruption on x86_64 after a signal was handled, but I
> >>>>can't find it
> >>>>now, so maybe I imagined it.
> >>>
> >>>Is this what you're thinking of?
> >>>
> >>>   https://cygwin.com/ml/cygwin-cvs/2014-q1/msg00020.html
> >>>
> >>>>But if for e.g. the flags register was getting
> >>>>corrupted when a signal interrupts the main thread, that could
> >>>>perhaps also
> >>>>explain what is being seen.
> >>>
> >>>Yes, flags register corruption is exactly what Eli suggested in the
> >>>other
> >>>bug report I cited.
> >>
> >>The aforementioned patch was supposed to fix this problem and it is
> >>definitely in the current 1.7.32 release...
> >
> >The ChangeLog entry just mentions the FPU control word and the XMM
> >registers, but not the ordinary FLAGS register (or rather EFLAGS for x86
> >and RFLAGS for x86_64, if I'm understanding correctly what I find in
> >Wikipedia).  Did the patch also take care of that?
>=20
> Never mind, it looks like that was already OK before the patch.  I see th=
at
> there are pushf and popf instructions in gendef.

Right.  If there's any indication that this isn't sufficient, please
tell me.  Maybe there's some other kind of CPU state information which
needs to be saved and restored for signal handling?!?


Corinna

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

--4f28nU6agdXSinmL
Content-Type: application/pgp-signature

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

iQIcBAEBAgAGBQJUSh/zAAoJEPU2Bp2uRE+gIs4P/RJLBpDhs5RgnsdLX67tvqvS
qShEBQJTUaz04t0ma08E6K+Icq8AwP9TwC0sniPT8pC4uPLRrojqXOLLeKxsb9gb
99fD/7czrNt2gv+v9P0kgb4B92yvTyey+eyltVsYOoc8khHPMk603BWmxkkYl4jE
W1NTIWuk8IGrd7Wgj4ydvSfcijR1sfRggHxdTKT0ITpWz1pz7z5gMEJHpDUnJ3Do
9qUh3mzQ3k33iaTjpjVLNXE6T+lhE4TbCyqz+km7Ej7UdHnPYj/5fMAp962h/GuH
oMreDnCirlBZ/4FaKs8hmRUr7pVCqFvXnLYoBmMRoU/Mkj422/iYSSUWM0k0Tr5J
1O8tB0wc7tac+vkiyNrAp5Vjz9vCf2Nf6bnpbjt4YBd8s5LfNivFgBkx3kgOUZdj
eavquOmYlZ3njhgGXUBQtfaxxOT/ZQzFiV62QPf4X/IowtonyRpX4FlpyGOuV48I
auWw3ZLQ+oYwFVB6ytRJpexJJtjxVnIQZSIgRQkUEaXDSlsiDRAwXsYl5NRpYYpA
+Bk08wUCbyDAN9qE9TPk/csrD4YsXtu0qDv59Tq354d9OXY7GrvuA+mcwIV2WLjw
9AMCWHRXPiyDW5IbhDRj5dJ8gsccw1PH6ot1kNtR0udVvKcL+4xub9S3gL2caE30
+BPlTGzMk2PKgSUrgEQz
=GSSV
-----END PGP SIGNATURE-----

--4f28nU6agdXSinmL--