Threads

[Ken Brown]

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?

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