This is the mail archive of the cygwin mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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 exists now. 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... jon@tambora / $ gcc signal-stress.c -Wall -O0 -g jon@tambora / $ ./a failed: 2144210386 isn't equal to 2144210386, apparentlySo 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 fails...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 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.
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.
Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |