public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Christopher Faylor <cgf@redhat.com>
To: gdb@sources.redhat.com
Subject: Re: Ctrl-C interrupt problem.
Date: Wed, 15 Nov 2000 12:48:00 -0000	[thread overview]
Message-ID: <20001115154759.D17136@redhat.com> (raw)
In-Reply-To: <200011151127.GAA03724@indy.delorie.com>

On Wed, Nov 15, 2000 at 06:27:38AM -0500, Eli Zaretskii wrote:
>> From: Fabrice Gautier <Fabrice_Gautier@sdesigns.com>
>> Date: Tue, 14 Nov 2000 20:18:11 -0800
>> 
>> Now I hve tried to do some test with natives cygwin programs. The very
>> simple sample below crashes in some circumstances with ctrl-C:
>> 
>> First Ctrl-C - everything is fine:
>> 
>> Program received signal SIGINT, Interrupt.
>> [Switching to thread 325.0x140]
>> 0x77f2b5b4 in ?? ()
>> 
>> 
>> Second Ctrl-C - bad karma:
>> (gdb) c
>> Continuing.
>>       0 [main] gdb 9049 handle_exceptions: Exception:
>> STATUS_ACCESS_VIOLATION
>>     669 [main] gdb 9049 stackdump: Dumping stack trace to gdb.exe.stackdump
>> Segmentation fault (core dumped)
>
>I don't know whether this is connected, but Ctrl-C gets some special
>handling from the NT DOS Box.  I don't know the particulars (Microsoft
>won't distribute NTVDM as Free Software ;-), but it is a known problem
>that NTVDM crashes or silently swallows Ctrl-C presses in some cases.
>
>I don't know if this is relevant for native Win32 console applications
>such as GDB compiled with Cygwin.

gdb should be using the same signal semantics for cygwin as it does on
UNIX.  I'm not aware of any problems handling CTRL-C in normal cygwin
processes but I have seen cases where gdb didn't want to wake up after
hitting a CTRL-C.  This may be because WaitForDebugEvent is not
interruptible by a CTRL-C.  I think that Keith Seitz made this call time
out some time ago to work around this fact, though.

If there is a problem, it needs to be debugged.  If you debug gdb using
gdb you (Fabrice) should be able to figure out where the SIGSEGV is
coming from.  That doesn't necessarily mean that it will be immediately
obvious how to fix it, of course, but at least you'll have more of a
clue as to where gdb is dying.

However, if you are going to be debugging gdb using, gdb, it makes sense
to rebuild a new windows version from CVS.  The gdb released with cygwin
net release is somewhat out-of-date, right now.

cgf

  reply	other threads:[~2000-11-15 12:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-11-14 20:19 Fabrice Gautier
2000-11-15  3:28 ` Eli Zaretskii
2000-11-15 12:48   ` Christopher Faylor [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-11-15 20:46 Fabrice Gautier
2000-11-15 23:10 ` Fernando Nasser
2000-11-16  5:24 ` Mark Salter
2000-11-16  5:48   ` Fernando Nasser
2000-11-15 17:48 Fabrice Gautier
2000-11-15 14:41 Fabrice Gautier
2000-11-14 16:39 Fabrice Gautier
2000-11-14 13:23 Fabrice Gautier
2000-11-10 16:13 Fabrice Gautier

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=20001115154759.D17136@redhat.com \
    --to=cgf@redhat.com \
    --cc=gdb@sources.redhat.com \
    /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).