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=n06xJ7271v6J0lZGwuYezFASXWDgW6kcFRXms5oJB2Mn88AwcHfOa
	zk/4p6U3N8umsL/WWkeNRNdBUrsjRBPIBe9/n0uZ7x8yJz1oTyen9fs5mVGhvjZO
	GfqHS4CbR9hW15O0b7neBqw7T4jTl0d10uNzfLSrxpuAao9Tbr6UN0=
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=DKBVaPsSEcRzWBpWU2pzKYtaW/w=; b=twFpw5BCMZzJMZbieDMvUhsPjXOR
	DZA0OK9XpGkwsFFnnVlY9NqqTI1JgL7DKlPYZjrL3kvEkAQDEkLo05/eN75zgia7
	COtFt+pEgk4RQ9cwlcfrKI7f0HFlRG79uM1PxSQ1u/d2KoLixS3Dl0Kwts/X1fcg
	El7kjRVdTRlR2A8=
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 15:52:31 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: Threads
Message-ID:	<20141024135231.GL20607@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> <544A327E DOT 9090006 AT dronecode DOT org DOT uk> <20141024125416 DOT GK20607 AT calimero DOT vinschen DOT de>
MIME-Version:	1.0
In-Reply-To:	<20141024125416.GK20607@calimero.vinschen.de>
User-Agent:	Mutt/1.5.23 (2014-03-12)

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

On Oct 24 14:54, Corinna Vinschen wrote:
> On Oct 24 12:05, Jon TURNEY wrote:
> > On 23/10/2014 16:37, Corinna Vinschen wrote:
> > >On Oct 23 08:04, Ken Brown wrote:
> > >>Yes, flags register corruption is exactly what Eli suggested in the o=
ther
> > >>bug report I cited.
> > >
> > >The aforementioned patch was supposed to fix this problem and it is
> > >definitely in the current 1.7.32 release...
> >=20
> > I didn't mean to suggest otherwise, just that perhaps a similar problem
> > exists now.
> >=20
> > So I made the attached test case to explore that.  Maybe I've made an
> > obvious mistake with it, but on the face of it, it seems to demonstrate
> > something...
> >=20
> > jon AT tambora /
> > $ gcc signal-stress.c  -Wall -O0 -g
> >=20
> > jon AT tambora /
> > $ ./a
> > failed: 2144210386 isn't equal to 2144210386, apparently
>=20
> So it checks i and j for equality, fails, and then comes up with
> "42 isn't equal to 42"?  This is weird...
>=20
> > Note there is some odd load dependency. For me, it works fine when it's=
 the
> > only thing running, but when I start up something CPU intensive, it oft=
en
> > fails...
>=20
> That's... interesting.  I wonder if that only occurs in multi-core or
> multi-CPU environments.  The fact that i and j are not the same when
> testing, but then are the same when printf is called looks like a
> out-of-order execution problem.
>=20
> Is it possible that we have to add CPU memory barriers to the sigdelayed
> function to avoid stuff like this?

I discussed this with my college Kai Tietz (many thanks to him from
here), and we came up with a problem in sigdelayed in the 64 bit case:
pushf is called *after* aligning the stack with andq.  This alignment
potentially changes the CPU flag values so the restored flags are
potentially not the flags when entering sigdelayed.

I just applied a patch and created new snapshots on
https://cygwin.com/snapshots/

I couldn't reprocude the problem locally, so I'd be grateful if you
could test if that fixes the problem in your testcase, Jon.

Ken, can you check if this snapshot helps emacs along, too?


Thanks,
Corinna

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

--7vAdt9JsdkkzRPKN
Content-Type: application/pgp-signature

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

iQIcBAEBAgAGBQJUSlmfAAoJEPU2Bp2uRE+go0EP/0GMv7GjQkSvq5mT/x8V5SpF
XzGZBozRqxhbaNAR1/15U5IfiMlrlEzao2MmQUog2+4Ezt1/zIJa65WhoBpAtFNY
IM/rnyRZ9sFZXD4It/Mf4Ul449eDG2c/tnfiW+caIisUzr1Azqrc6t+NBXq0wnwO
vXocFSXTuXW/vryZKM7ys/UUrhMD9LxEFV20Qx0LSccRLkmfY9632K5dFSqOUMgA
haXISZC2vX6QuG/luij56A2F6dl65UyXqDxWdYW1yOs9ZItAYx7WEWTg5ipOoNar
ib+secDQEOdAXCMnJDwm1Z0KjbTsY+/w+2oiFuttGDZefFgF1LJC338IDpDKfNwv
l3M76NHPBC3MBBSxCVi4SK04XNhr4zg4n9mC5tqEwpiWbTEjUhKJDwK8iCb8KSHK
Vlru5wQhRSdyNSheZdqPcmQPVgb5laLFIZsGQOWtTwJhKILEdGkWUByClscBTTmD
H20IXs7PIGawPT+FClNZqy0KVCWq8h6eQleaVu+9iDOibGkzSU1Xne8741wTWgJV
6N5ZeYIDGiDqdCIIIjIGHSxihx3kDXng4M2yThbzLUyT/e8G4MYgVUE5KhqAqmR5
vmF7hZ2fvUXIyg71W90/Hpo2N6cnub8+Zp4ufoP4BWcZ1ZlwymwrQr27L8jU//M8
bhbn/rhFQ/rXmbp9f3eK
=vnFj
-----END PGP SIGNATURE-----

--7vAdt9JsdkkzRPKN--

- Raw text -