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" crashes?
This can't just be a result of a gdb bug, because in at least one case
the assertion can be shown to be valid by using printf instead of gdb.
[*] 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=18438
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18769
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?
Never mind, it looks like that was already OK before the patch. I see
that there are pushf and popf instructions in gendef.
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
