This is the mail archive of the
mailing list for the Cygwin project.
- From: Ken Brown <kbrown at cornell dot edu>
- To: cygwin at cygwin dot com
- Date: Sun, 26 Oct 2014 07:58:47 -0400
- Subject: Re: Threads
- Authentication-results: sourceware.org; auth=none
- 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> <20141024135231 dot GL20607 at calimero dot vinschen dot de>
On 10/24/2014 9:52 AM, Corinna Vinschen wrote:
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 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...
I didn't mean to suggest otherwise, just that perhaps a similar problem
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
$ gcc signal-stress.c -Wall -O0 -g
failed: 2144210386 isn't equal to 2144210386, apparently
So it checks i and j for equality, fails, and then comes up with
"42 isn't equal to 42"? This is weird...
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 often
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.
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
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.
I tried Jon's testcase. With cygwin-1.7.33-0.1, it failed within a few minutes.
With cygwin-1.7.33-0.2, I ran it for over an hour with no problem, with the
system heavily loaded. So it looks good so far.
Ken, can you check if this snapshot helps emacs along, too?
The people who have been reporting frequent crashes are aware of the fix. Now I
just have to wait and hope I don't hear from them for a few days.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple