X-Recipient: archive-cygwin@delorie.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@cygwin.com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe@cygwin.com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin@cygwin.com>
List-Help: <mailto:cygwin-help@cygwin.com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Delivered-To: mailing list cygwin@cygwin.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@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Threads
Message-ID: <20141024135231.GL20607@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <54450835.3050602@cornell.edu> <5448E6F9.8040005@dronecode.org.uk> <5448EEBF.3020706@cornell.edu> <20141023153730.GC20607@calimero.vinschen.de> <544A327E.9090006@dronecode.org.uk> <20141024125416.GK20607@calimero.vinschen.de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="7vAdt9JsdkkzRPKN"
Content-Disposition: inline
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@tambora /
> > $ gcc signal-stress.c  -Wall -O0 -g
> >=20
> > jon@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--
