Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Gary Benson <gbenson@redhat.com>
To: Doug Evans <xdje42@gmail.com>
Cc: Mark Kettenis <mark.kettenis@xs4all.nl>,
	       "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH 0/2] Demangler crash handler
Date: Tue, 13 May 2014 10:20:00 -0000	[thread overview]
Message-ID: <20140513102035.GA17805@blade.nx> (raw)
In-Reply-To: <CAP9bCMRmZOcMtdKfZZHVCdYat3MqiaK8-RWGzJ3SQW7MViSr6w@mail.gmail.com>

Doug Evans wrote:
> On Fri, May 9, 2014 at 8:33 AM, Gary Benson <gbenson@redhat.com> wrote:
> > [...]
> > +  if (crash_signal != 0)
> > +    {
> > +      static int warning_printed = 0;
> > +
> > +      if (!warning_printed)
> > +       {
> > +         warning ("internal error: demangler failed with signal %d\n"
> > +                  "Unable to demangle '%s'\n"
> > +                  "This is a bug, "
> > +                  "please report it to the GDB maintainers.",
> > +                  crash_signal, name);
> > +
> > +         warning_printed = 1;
> > +       }
> > +
> > +      result = NULL;
> > +    }
> > +
> > +  return result;
> 
> Applying "Consistency Is Good" to this patch, I wonder if we should
> do something similar to what we do for internal errors.  I'm not
> sure I would use the same flag (grep for internal_problem_modes and
> friends in utils.c), but OTOH I wouldn't want a proliferation of
> options for controlling each particular kind of "crash".
> 
> What do you think?

I did not realize internal_error had the ability to continue over an
error.  Rather than doing something similar to internal_error I can
just update the patch to use it.  I actually prefer this to using
regular warning as the user has to explicity continue over the error.
They cannot miss that something is wrong and that they are now in
uncharted territory, but at the same time they have to option to
try and continue using GDB to debug their program.

I attached an updated patch that uses internal_warning below.  It
might be desirable to create a new warning (demangler_warning) that
would work like internal_warning but not offer the possibility of
saving a not-particularly-useful core dump.  That's a refinement
I'm not sure is necessary, however: this isn't everyday code.

As an aside, would it be worth printing an extra line or two from
internal_vproblem asking the user to report the bug and directing
them to the bug tracker and/or the mailing lists?

Thanks,
Gary

--
diff --git a/gdb/cp-support.c b/gdb/cp-support.c
index 91533e8..a99c827 100644
--- a/gdb/cp-support.c
+++ b/gdb/cp-support.c
@@ -36,6 +36,7 @@
 #include "value.h"
 #include "cp-abi.h"
 #include "language.h"
+#include <signal.h>
 
 #include "safe-ctype.h"
 
@@ -1505,12 +1506,88 @@ cp_lookup_rtti_type (const char *name, struct block *block)
   return rtti_type;
 }
 
+#ifdef SIGSEGV
+
+/* PortabiWrap set/long jmp so that it's more portable.  */
+
+#if defined(HAVE_SIGSETJMP)
+#define SIGJMP_BUF		sigjmp_buf
+#define SIGSETJMP(buf)		sigsetjmp((buf), 1)
+#define SIGLONGJMP(buf,val)	siglongjmp((buf), (val))
+#else
+#define SIGJMP_BUF		jmp_buf
+#define SIGSETJMP(buf)		setjmp(buf)
+#define SIGLONGJMP(buf,val)	longjmp((buf), (val))
+#endif
+
+/* Stack context and environment for demangler crash recovery.  */
+
+static SIGJMP_BUF gdb_demangle_jmp_buf;
+
+/* Signal handler for gdb_demangle.  */
+
+static void
+gdb_demangle_signal_handler (int signo)
+{
+  SIGLONGJMP (gdb_demangle_jmp_buf, signo);
+}
+
+#endif
+
 /* A wrapper for bfd_demangle.  */
 
 char *
 gdb_demangle (const char *name, int options)
 {
-  return bfd_demangle (NULL, name, options);
+  char *result = NULL;
+  int crash_signal = 0;
+
+#ifdef SIGSEGV
+#if defined (HAVE_SIGACTION) && defined (SA_RESTART)
+  struct sigaction sa, old_sa;
+
+  sa.sa_handler = gdb_demangle_signal_handler;
+  sigemptyset (&sa.sa_mask);
+  sa.sa_flags = 0;
+  sigaction (SIGSEGV, &sa, &old_sa);
+#else
+  void (*ofunc) ();
+
+  ofunc = (void (*)()) signal (SIGSEGV, gdb_demangle_signal_handler);
+#endif
+
+  crash_signal = SIGSETJMP (gdb_demangle_jmp_buf);
+#endif
+
+  if (crash_signal == 0)
+    result = bfd_demangle (NULL, name, options);
+
+#ifdef SIGSEGV
+#if defined (HAVE_SIGACTION) && defined (SA_RESTART)
+  sigaction (SIGSEGV, &old_sa, NULL);
+#else
+  signal (SIGSEGV, ofunc);
+#endif
+#endif
+
+  if (crash_signal != 0)
+    {
+      static int error_reported = 0;
+
+      if (!error_reported)
+	{
+	  internal_warning (__FILE__, __LINE__,
+			    _("unable to demangle '%s' "
+			      "(demangler failed with signal %d)"),
+			    name, crash_signal);
+
+	  error_reported = 1;
+	}
+
+      result = NULL;
+    }
+
+  return result;
 }
 
 /* Don't allow just "maintenance cplus".  */


  reply	other threads:[~2014-05-13 10:20 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-09 10:07 Gary Benson
2014-05-09 10:09 ` [PATCH 1/2] " Gary Benson
2014-05-09 10:10 ` [PATCH 2/2] " Gary Benson
2014-05-09 11:20 ` [PATCH 0/2] " Mark Kettenis
2014-05-09 15:33   ` Gary Benson
2014-05-11  5:17     ` Doug Evans
2014-05-13 10:20       ` Gary Benson [this message]
2014-05-13 19:29         ` Tom Tromey
2014-05-14 13:07           ` Gary Benson
2014-05-13 19:39         ` Tom Tromey
2014-05-14  9:15           ` Gary Benson
2014-05-11 20:23     ` Mark Kettenis
2014-05-13 10:21       ` Gary Benson
2014-05-13 16:05         ` Pedro Alves
2014-05-15 13:24           ` Gary Benson
2014-05-15 14:07             ` Pedro Alves
2014-05-15 14:28               ` Gary Benson
2014-05-15 15:25                 ` Pedro Alves
2014-05-16 11:06             ` Pedro Alves
2014-05-10 20:55   ` Florian Weimer
2014-05-11  5:10     ` Doug Evans
2014-05-13 10:22     ` Gary Benson
2014-05-13 18:22       ` Florian Weimer
2014-05-13 18:42         ` Pedro Alves
2014-05-13 19:16           ` Gary Benson
2014-05-13 19:19             ` Pedro Alves
2014-05-14  9:11               ` Gary Benson
2014-05-13 19:20           ` Florian Weimer
2014-05-13 19:22             ` Pedro Alves
2014-05-13 19:22         ` Gary Benson
2014-05-13 19:36           ` Tom Tromey
2014-05-14  9:13             ` Gary Benson
2014-05-14 14:18     ` Pedro Alves
2014-05-14 16:08       ` Andrew Burgess
2014-05-14 18:32         ` Pedro Alves
2014-05-15 13:25           ` Gary Benson
2014-05-15 16:01             ` Pedro Alves
2014-05-15 13:27       ` Gary Benson
2014-05-20 17:05       ` Tom Tromey
2014-05-20 18:40         ` Stan Shebs
2014-05-20 19:36           ` Tom Tromey
2014-05-20 20:23             ` Joel Brobecker
2014-05-22 12:56               ` Gary Benson
2014-05-22 13:09                 ` Joel Brobecker
2014-05-22 14:13                 ` Pedro Alves
2014-05-22 15:57                   ` Gary Benson
2014-05-22 13:18           ` Gary Benson
2014-05-22 14:09         ` Gary Benson
2014-05-22 14:40           ` Mark Kettenis
2014-05-22 20:42             ` 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=20140513102035.GA17805@blade.nx \
    --to=gbenson@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=mark.kettenis@xs4all.nl \
    --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