From: Jon TURNEY <jon.turney@dronecode.org.uk>
To: Ken Brown <kbrown@cornell.edu>, cygwin@cygwin.com
Subject: Re: Threads
Date: Thu, 23 Oct 2014 11:31:00 -0000 [thread overview]
Message-ID: <5448E6F9.8040005@dronecode.org.uk> (raw)
In-Reply-To: <54450835.3050602@cornell.edu>
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. 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.
(More generally, it doesn't have to be another thread which is causing
these problems, it could be some form of interrupt)
--
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
next prev parent reply other threads:[~2014-10-23 11:31 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-20 13:04 Threads Ken Brown
2014-10-20 16:43 ` Threads Corinna Vinschen
2014-10-20 19:03 ` Threads Corinna Vinschen
2014-10-20 19:58 ` Threads Ken Brown
2014-10-21 11:17 ` Threads Corinna Vinschen
2014-10-21 12:27 ` Threads Ken Brown
2014-10-23 11:31 ` Jon TURNEY [this message]
2014-10-23 12:04 ` Threads Ken Brown
2014-10-23 15:37 ` Threads Corinna Vinschen
2014-10-23 18:07 ` Threads Achim Gratz
2014-10-23 20:32 ` Threads Ken Brown
2014-10-24 1:07 ` Threads Ken Brown
2014-10-24 9:46 ` Threads Corinna Vinschen
2014-10-24 11:05 ` Threads Jon TURNEY
2014-10-24 12:54 ` Threads Corinna Vinschen
2014-10-24 13:52 ` Threads Corinna Vinschen
2014-10-26 11:58 ` Threads Ken Brown
2014-10-28 10:44 ` Threads Jon TURNEY
2014-10-28 11:40 ` Threads Corinna Vinschen
2014-10-28 13:47 ` Threads Ken Brown
2014-10-28 14:19 ` [GOLDSTARS] Threads Corinna Vinschen
2014-10-28 17:39 ` Andrew Schulman
2014-10-29 10:00 ` Corinna Vinschen
-- strict thread matches above, loose matches on Subject: below --
2014-10-26 13:20 Threads Angelo Graziosi
2014-10-26 21:38 ` Threads Ken Brown
2014-10-27 10:21 ` Threads Corinna Vinschen
2000-02-04 6:32 Threads M Dipperstein
2000-02-04 8:06 ` Threads Mumit Khan
1997-03-19 10:28 Threads Davind Maharaj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5448E6F9.8040005@dronecode.org.uk \
--to=jon.turney@dronecode.org.uk \
--cc=cygwin@cygwin.com \
--cc=kbrown@cornell.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).