public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Gary Benson <gbenson@redhat.com>
To: gdb-patches@sourceware.org
Cc: Andrew Burgess <aburgess@broadcom.com>,
	Doug Evans <xdje42@gmail.com>,
	       Eli Zaretskii <eliz@gnu.org>,
	Florian Weimer <fw@deneb.enyo.de>,
	       Mark Kettenis <mark.kettenis@xs4all.nl>,
	       Pedro Alves <palves@redhat.com>,
	Tom Tromey <tromey@redhat.com>
Subject: [PATCH 0/2 v3] Demangler crash handler
Date: Wed, 04 Jun 2014 10:08:00 -0000	[thread overview]
Message-ID: <20140604100755.GA7570@blade.nx> (raw)

Hi all,

This patch is an updated version of the demangler crash handler I
posted two weeks ago.  There are two main changes from the previous
version:

 1) The signal handler creates a core file before returning.
    This ensures that a core file is created at the correct
    location.

 2) I have switched the crash handler to be enabled by default.
    I think this is appropriate now that a core file is always
    created.

To make this work correctly I have had to add a new class of
internal problem, which I've called demangler_warning.  This
has the same behaviour as internal_warning except that it does
not prompt the user to create a core file because that's already
been done.  I know Doug didn't want this but it's necessary to
avoid either overwriting the useful core file with a non-useful
one or confusing the user with a second, non-useful core file.

I've split this patch into two parts for ease of discussion.  The
first patch adds the new internal problem functionality, and the
second patch is the crash handler itself.  This differs from the
previous version by the addition of core file generation and in
that it calls demangler_warning instead of internal_warning.

I would push both patches as one commit.  The news file entries
for the commit would be:

  * New options
  
  maint set catch-demangler-crashes (on|off)
  maint show catch-demangler-crashes
    Control whether GDB should attempt to catch crashes in the symbol
    name demangler.  The default is to attempt to catch crashes.  If
    enabled, the first time a crash is caught, a core file is created,
    the offending symbol is displayed and the user is presented with
    the option to terminate the current session.
  
  maint set demangler-warning quit (yes|no|ask)
    When GDB catches a crash in the symbol name demangler it can offer
    the user the opportunity to both quit GDB and create a core file of
    the current GDB session.  These options control whether or not to
    do either of these.  The default is to create a core file and to ask
    the user whether to quit.
  
  * New commands
  
  maint demangler-warning
    Cause GDB to call the internal function demangler_warning and
    hence behave as though an internal error in the demangler has
    been detected.

Is this ok to commit?

Thanks,
Gary

--
http://gbenson.net/

             reply	other threads:[~2014-06-04 10:08 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-04 10:08 Gary Benson [this message]
2014-06-04 10:09 ` [PATCH 1/2 v3] Add new internal problem for demangler warnings Gary Benson
2014-06-04 10:18   ` Eli Zaretskii
2014-06-04 13:34     ` Gary Benson
2014-06-04 10:10 ` [PATCH 2/2 v3] Demangler crash handler Gary Benson
2014-06-04 10:20   ` Eli Zaretskii
2014-06-04 13:36     ` Gary Benson
2014-06-04 13:41       ` Eli Zaretskii
2014-06-04 14:28         ` Gary Benson
2014-06-04 15:24           ` Doug Evans
2014-06-04 18:25             ` Gary Benson
2014-06-05  1:11               ` Doug Evans
2014-06-05  2:54                 ` Eli Zaretskii
2014-06-04 16:05   ` Doug Evans
2014-06-04 18:34     ` Gary Benson
2014-06-04 10:21 ` [PATCH 0/2 " Eli Zaretskii
2014-06-04 13:41   ` Gary Benson
2014-06-04 13:49     ` Eli Zaretskii
2014-06-04 14:28       ` Gary Benson
2014-06-04 10:28 ` Mark Kettenis
2014-06-04 13:34   ` Gary Benson
2014-06-04 14:54     ` Andrew Burgess
2014-06-04 15:52       ` Doug Evans
2014-06-04 15:57       ` Gary Benson

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=20140604100755.GA7570@blade.nx \
    --to=gbenson@redhat.com \
    --cc=aburgess@broadcom.com \
    --cc=eliz@gnu.org \
    --cc=fw@deneb.enyo.de \
    --cc=gdb-patches@sourceware.org \
    --cc=mark.kettenis@xs4all.nl \
    --cc=palves@redhat.com \
    --cc=tromey@redhat.com \
    --cc=xdje42@gmail.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).