* [PATCH 2/2 v2] Demangler crash handler
@ 2014-05-19 11:48 Gary Benson
2014-05-19 15:01 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Gary Benson @ 2014-05-19 11:48 UTC (permalink / raw)
To: gdb-patches
Cc: Andrew Burgess, Doug Evans, Eli Zaretskii, Florian Weimer,
Mark Kettenis, Pedro Alves, Tom Tromey
Hi all,
This patch is an updated version of patch 2 of the demangler crash
handler I posted last week. Patch 1 of this series [1] remains the
same.
The main change I have made is to cause the crash handler to be
disabled by default. The user must explicitly enable the handler
with "maint set catch-demangler-crashes on". This will simplify
triage of bugs such as PR 16957 [2], a new demangler crash that was
reported on Friday. The user did not supply enough information to
see the offending symbol, and I don't have the necessary compiler
or libraries to reproduce the bug locally. With this patch we can
instruct the user to enter "maint set catch-demangler-crashes on"
and repeat whatever they did to cause the crash in the first place.
We can then easily obtain the first offending symbol GDB encountered.
The other main change I have made from the original patch is to
remove as much code as possible from the signal handler itself
such that only a (sig)longjmp remains. While this is still not
strictly safe, it should be clear if any future problems have been
caused by this because the problem will only occur if the user has
enabled the crash handler.
One final change from my original patch is that this patch uses
internal_warning to offer the same "quit this session/create a
core file" choices as offered for other internal problems.
Is this ok to commit?
Thanks,
Gary
--
[1] https://sourceware.org/ml/gdb-patches/2014-05/msg00109.html
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=16957
--
This patch adds a new maintainence boolean, catch_demangler_crashes.
If set, calls to the demangler are wrapped with a segmentation fault
handler. The first time a segmentation fault is caught the offending
symbol is displayed and internal_warning is called.
The NEWS file entry for this patch is as follows:
* New options
maint set catch-demangler-crashes (on|off)
maint show catch-demangler-crashes
Control whether the debugger should attempt to catch crashes in the
symbol name demangler. The default is not to attempt to catch
crashes. The first time a crash is caught the offending symbol is
displayed and the user is presented with options to terminate the
current session and/or to create a core file.
gdb/
2014-05-19 Gary Benson <gbenson@redhat.com>
* cp-support.c (signal.h): New include.
(catch_demangler_crashes): New flag.
(SIGJMP_BUF): New define.
(SIGSETJMP): Likewise.
(SIGLONGJMP): Likewise.
(gdb_demangle_jmp_buf): New variable.
(gdb_demangle_signal_handler): New function.
(gdb_demangle): If catch_demangler_crashes is set, install the
above signal handler before calling bfd_demangle, and restore
the original signal handler afterwards. Display the offending
symbol and call internal_warning the first time a segmentation
fault is caught.
(_initialize_cp_support): New maint set/show command.
gdb/doc/
2014-05-19 Gary Benson <gbenson@redhat.com>
* gdb.texinfo (Maintenance Commands): Document new
"maint set/show catch-demangler-crashes" option.
diff --git a/gdb/cp-support.c b/gdb/cp-support.c
index 91533e8..d065d1f 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,101 @@ cp_lookup_rtti_type (const char *name, struct block *block)
return rtti_type;
}
+#ifdef SIGSEGV
+
+/* If nonzero, attempt to catch crashes in the demangler and print
+ useful debugging information. */
+
+static int catch_demangler_crashes = 0;
+
+/* Wrap 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;
+
+ if (catch_demangler_crashes)
+ {
+ sa.sa_handler = gdb_demangle_signal_handler;
+ sigemptyset (&sa.sa_mask);
+ sa.sa_flags = 0;
+ sigaction (SIGSEGV, &sa, &old_sa);
+ }
+#else
+ void (*ofunc) ();
+
+ if (catch_demangler_crashes)
+ ofunc = (void (*)()) signal (SIGSEGV, gdb_demangle_signal_handler);
+#endif
+
+ if (catch_demangler_crashes)
+ crash_signal = SIGSETJMP (gdb_demangle_jmp_buf);
+#endif
+
+ if (crash_signal == 0)
+ result = bfd_demangle (NULL, name, options);
+
+#ifdef SIGSEGV
+ if (catch_demangler_crashes)
+ {
+#if defined (HAVE_SIGACTION) && defined (SA_RESTART)
+ sigaction (SIGSEGV, &old_sa, NULL);
+#else
+ signal (SIGSEGV, ofunc);
+#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;
+ }
+ }
+#endif
+
+ return result;
}
/* Don't allow just "maintenance cplus". */
@@ -1585,4 +1675,17 @@ _initialize_cp_support (void)
Usage: info vtbl EXPRESSION\n\
Evaluate EXPRESSION and display the virtual function table for the\n\
resulting object."));
+
+#ifdef SIGSEGV
+ add_setshow_boolean_cmd ("catch-demangler-crashes", class_maintenance,
+ &catch_demangler_crashes, _("\
+Set whether to attempt to catch demangler crashes."), _("\
+Show whether GDB will attempt to catch demangler crashes."), _("\
+If enabled GDB will attempt to catch demangler crashes and\n\
+display the offending symbol."),
+ NULL,
+ NULL,
+ &maintenance_set_cmdlist,
+ &maintenance_show_cmdlist);
+#endif
}
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH 2/2 v2] Demangler crash handler
2014-05-19 11:48 [PATCH 2/2 v2] Demangler crash handler Gary Benson
@ 2014-05-19 15:01 ` Eli Zaretskii
2014-05-19 15:48 ` Gary Benson
0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2014-05-19 15:01 UTC (permalink / raw)
To: Gary Benson
Cc: gdb-patches, aburgess, xdje42, fw, mark.kettenis, palves, tromey
> Date: Mon, 19 May 2014 12:48:02 +0100
> From: Gary Benson <gbenson@redhat.com>
> 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>
>
> The main change I have made is to cause the crash handler to be
> disabled by default. The user must explicitly enable the handler
> with "maint set catch-demangler-crashes on". This will simplify
> triage of bugs such as PR 16957 [2], a new demangler crash that was
> reported on Friday. The user did not supply enough information to
> see the offending symbol, and I don't have the necessary compiler
> or libraries to reproduce the bug locally. With this patch we can
> instruct the user to enter "maint set catch-demangler-crashes on"
> and repeat whatever they did to cause the crash in the first place.
> We can then easily obtain the first offending symbol GDB encountered.
Can't say this option makes sense to me. Isn't there a way to display
the necessary information in a message, even though you catch the
signal?
> maint set catch-demangler-crashes (on|off)
> maint show catch-demangler-crashes
> Control whether the debugger should attempt to catch crashes in the
> symbol name demangler. The default is not to attempt to catch
> crashes. The first time a crash is caught the offending symbol is
> displayed and the user is presented with options to terminate the
> current session and/or to create a core file.
Given this description, it sounds like all the necessary information
is already displayed when the crash is caught. So why would we need
an option?
> gdb/doc/
> 2014-05-19 Gary Benson <gbenson@redhat.com>
>
> * gdb.texinfo (Maintenance Commands): Document new
> "maint set/show catch-demangler-crashes" option.
This part of the patch was absent from what you sent.
> +#ifdef SIGSEGV
AFAIK, SIGSEGV is an ANSI-standard signal, so I don't think you need a
preprocessor conditional here.
> + add_setshow_boolean_cmd ("catch-demangler-crashes", class_maintenance,
> + &catch_demangler_crashes, _("\
> +Set whether to attempt to catch demangler crashes."), _("\
> +Show whether GDB will attempt to catch demangler crashes."), _("\
The "Set" and "Show" lines should be identical except for the initial
word.
Thanks.
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH 2/2 v2] Demangler crash handler
2014-05-19 15:01 ` Eli Zaretskii
@ 2014-05-19 15:48 ` Gary Benson
2014-05-19 16:55 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Gary Benson @ 2014-05-19 15:48 UTC (permalink / raw)
To: Eli Zaretskii
Cc: gdb-patches, aburgess, xdje42, fw, mark.kettenis, palves, tromey
Eli Zaretskii wrote:
> > Date: Mon, 19 May 2014 12:48:02 +0100
> > From: Gary Benson <gbenson@redhat.com>
> > 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>
> >
> > The main change I have made is to cause the crash handler to be
> > disabled by default. The user must explicitly enable the handler
> > with "maint set catch-demangler-crashes on". This will simplify
> > triage of bugs such as PR 16957 [2], a new demangler crash that
> > was reported on Friday. The user did not supply enough
> > information to see the offending symbol, and I don't have the
> > necessary compiler or libraries to reproduce the bug locally.
> > With this patch we can instruct the user to enter "maint set
> > catch-demangler-crashes on" and repeat whatever they did to cause
> > the crash in the first place. We can then easily obtain the first
> > offending symbol GDB encountered.
>
> Can't say this option makes sense to me. Isn't there a way to
> display the necessary information in a message, even though you
> catch the signal?
To clarify, the current situation in GDB is that crashes in the
demangler are not caught:
(gdb) set lang c++
(gdb) maint demangle _Z1-Av23*;cG~Wo2Vu
Segmentation fault (core dumped)
With the patch, that is also the default situation. But with the
patch, with "maint set catch-demangler-crashes on", a signal handler
is installed across calls to the demangler, so that if the demangler
crashes you get something like this:
(gdb) set lang c++
(gdb) maint set catch-demangler-crashes on
(gdb) maint demangle _Z1-Av23*;cG~Wo2Vu
/home/gary/work/archer/demangle-crashcatcher/src/gdb/cp-support.c:1590: internal-warning: unable to demangle '_Z1-Av23*;cG~Wo2Vu' (demangler failed with signal 11)
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y
/home/gary/work/archer/demangle-crashcatcher/src/gdb/cp-support.c:1590: internal-warning: unable to demangle '_Z1-Av23*;cG~Wo2Vu' (demangler failed with signal 11)
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) y
Aborted (core dumped)
> > maint set catch-demangler-crashes (on|off)
> > maint show catch-demangler-crashes
> > Control whether the debugger should attempt to catch crashes in the
> > symbol name demangler. The default is not to attempt to catch
> > crashes. The first time a crash is caught the offending symbol is
> > displayed and the user is presented with options to terminate the
> > current session and/or to create a core file.
>
> Given this description, it sounds like all the necessary information
> is already displayed when the crash is caught. So why would we need
> an option?
Did my above explanation answer this question?
> > gdb/doc/
> > 2014-05-19 Gary Benson <gbenson@redhat.com>
> >
> > * gdb.texinfo (Maintenance Commands): Document new
> > "maint set/show catch-demangler-crashes" option.
>
> This part of the patch was absent from what you sent.
My apologies. And the whole reason I Cc'd you was because the patch
contained documentation changes :) I've inlined that part at the end
of this mail.
> > +#ifdef SIGSEGV
>
> AFAIK, SIGSEGV is an ANSI-standard signal, so I don't think you need a
> preprocessor conditional here.
Ok, I can remove this.
> > + add_setshow_boolean_cmd ("catch-demangler-crashes", class_maintenance,
> > + &catch_demangler_crashes, _("\
> > +Set whether to attempt to catch demangler crashes."), _("\
> > +Show whether GDB will attempt to catch demangler crashes."), _("\
>
> The "Set" and "Show" lines should be identical except for the
> initial word.
Ok, I will change the second to:
+Show whether to attempt to catch demangler crashes."), _("\
Thanks,
Gary
--
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index a6bde12..32f33a9 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -33142,6 +33142,16 @@ Expand symbol tables.
If @var{regexp} is specified, only expand symbol tables for file
names matching @var{regexp}.
+@kindex maint set catch-demangler-crashes
+@kindex maint show catch-demangler-crashes
+@item maint set catch-demangler-crashes [on|off]
+@itemx maint show catch-demangler-crashes
+Control whether @value{GDBN} should attempt to catch crashes in the
+symbol name demangler. The default is not to attempt to catch
+crashes. If enabled, the first time a crash is caught the offending
+symbol is displayed and the user is presented with options to
+terminate the current session and to create a core file.
+
@kindex maint cplus first_component
@item maint cplus first_component @var{name}
Print the first C@t{++} class/namespace component of @var{name}.
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH 2/2 v2] Demangler crash handler
2014-05-19 15:48 ` Gary Benson
@ 2014-05-19 16:55 ` Eli Zaretskii
2014-05-19 19:05 ` Gary Benson
0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2014-05-19 16:55 UTC (permalink / raw)
To: Gary Benson
Cc: gdb-patches, aburgess, xdje42, fw, mark.kettenis, palves, tromey
> Date: Mon, 19 May 2014 16:48:23 +0100
> From: Gary Benson <gbenson@redhat.com>
> Cc: gdb-patches@sourceware.org, aburgess@broadcom.com, xdje42@gmail.com,
> fw@deneb.enyo.de, mark.kettenis@xs4all.nl, palves@redhat.com,
> tromey@redhat.com
>
> > Can't say this option makes sense to me. Isn't there a way to
> > display the necessary information in a message, even though you
> > catch the signal?
>
> To clarify, the current situation in GDB is that crashes in the
> demangler are not caught:
>
> (gdb) set lang c++
> (gdb) maint demangle _Z1-Av23*;cG~Wo2Vu
> Segmentation fault (core dumped)
>
> With the patch, that is also the default situation. But with the
> patch, with "maint set catch-demangler-crashes on", a signal handler
> is installed across calls to the demangler, so that if the demangler
> crashes you get something like this:
>
> (gdb) set lang c++
> (gdb) maint set catch-demangler-crashes on
> (gdb) maint demangle _Z1-Av23*;cG~Wo2Vu
> /home/gary/work/archer/demangle-crashcatcher/src/gdb/cp-support.c:1590: internal-warning: unable to demangle '_Z1-Av23*;cG~Wo2Vu' (demangler failed with signal 11)
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> Quit this debugging session? (y or n) y
>
> /home/gary/work/archer/demangle-crashcatcher/src/gdb/cp-support.c:1590: internal-warning: unable to demangle '_Z1-Av23*;cG~Wo2Vu' (demangler failed with signal 11)
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> Create a core file of GDB? (y or n) y
> Aborted (core dumped)
Yes, I knew all that (because I've read all the deliberations here
about this feature). I'm asking why do we need this option, instead
of having its ON effect by default?
> --- a/gdb/doc/gdb.texinfo
> +++ b/gdb/doc/gdb.texinfo
> @@ -33142,6 +33142,16 @@ Expand symbol tables.
> If @var{regexp} is specified, only expand symbol tables for file
> names matching @var{regexp}.
>
> +@kindex maint set catch-demangler-crashes
> +@kindex maint show catch-demangler-crashes
Please add here
@cindex demangler crashes
Otherwise, this part is OK. Thanks.
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH 2/2 v2] Demangler crash handler
2014-05-19 16:55 ` Eli Zaretskii
@ 2014-05-19 19:05 ` Gary Benson
2014-05-19 20:41 ` Pedro Alves
0 siblings, 1 reply; 9+ messages in thread
From: Gary Benson @ 2014-05-19 19:05 UTC (permalink / raw)
To: Eli Zaretskii
Cc: gdb-patches, aburgess, xdje42, fw, mark.kettenis, palves, tromey
Eli Zaretskii wrote:
> > Date: Mon, 19 May 2014 16:48:23 +0100
> > From: Gary Benson <gbenson@redhat.com>
> > Cc: gdb-patches@sourceware.org, aburgess@broadcom.com, xdje42@gmail.com,
> > fw@deneb.enyo.de, mark.kettenis@xs4all.nl, palves@redhat.com,
> > tromey@redhat.com
> >
> > > Can't say this option makes sense to me. Isn't there a way to
> > > display the necessary information in a message, even though you
> > > catch the signal?
> >
> > To clarify, the current situation in GDB is that crashes in the
> > demangler are not caught:
> >
> > (gdb) set lang c++
> > (gdb) maint demangle _Z1-Av23*;cG~Wo2Vu
> > Segmentation fault (core dumped)
> >
> > With the patch, that is also the default situation. But with the
> > patch, with "maint set catch-demangler-crashes on", a signal
> > handler is installed across calls to the demangler, so that if the
> > demangler crashes you get something like this:
> >
> > (gdb) set lang c++
> > (gdb) maint set catch-demangler-crashes on
> > (gdb) maint demangle _Z1-Av23*;cG~Wo2Vu
> > /home/gary/work/archer/demangle-crashcatcher/src/gdb/cp-support.c:1590: internal-warning: unable to demangle '_Z1-Av23*;cG~Wo2Vu' (demangler failed with signal 11)
> > A problem internal to GDB has been detected,
> > further debugging may prove unreliable.
> > Quit this debugging session? (y or n) y
> >
> > /home/gary/work/archer/demangle-crashcatcher/src/gdb/cp-support.c:1590: internal-warning: unable to demangle '_Z1-Av23*;cG~Wo2Vu' (demangler failed with signal 11)
> > A problem internal to GDB has been detected,
> > further debugging may prove unreliable.
> > Create a core file of GDB? (y or n) y
> > Aborted (core dumped)
>
> Yes, I knew all that (because I've read all the deliberations here
> about this feature). I'm asking why do we need this option, instead
> of having its ON effect by default?
Ah, my apologies. On by default is my preference--it seems to work,
and it doesn't rob performance--but I don't think that will to be
accepted because there's no way to do this without (sig)longjmp, and
that isn't safe to call from a signal handler. A disabled-by-default
catcher is at least somewhat helpful in triaging all these demangler
bugs that are coming in now people are starting to use C++11 features.
> > --- a/gdb/doc/gdb.texinfo
> > +++ b/gdb/doc/gdb.texinfo
> > @@ -33142,6 +33142,16 @@ Expand symbol tables.
> > If @var{regexp} is specified, only expand symbol tables for file
> > names matching @var{regexp}.
> >
> > +@kindex maint set catch-demangler-crashes
> > +@kindex maint show catch-demangler-crashes
>
> Please add here
>
> @cindex demangler crashes
>
> Otherwise, this part is OK. Thanks.
Thank you.
Gary
--
http://gbenson.net/
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH 2/2 v2] Demangler crash handler
2014-05-19 19:05 ` Gary Benson
@ 2014-05-19 20:41 ` Pedro Alves
2014-05-20 2:43 ` Eli Zaretskii
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Pedro Alves @ 2014-05-19 20:41 UTC (permalink / raw)
To: Gary Benson, Eli Zaretskii
Cc: gdb-patches, aburgess, xdje42, fw, mark.kettenis, tromey
Wouldn't a new "set debug demangle on" option, that would make
GDB output:
(gdb) bt / whatever-gdb-command-that-triggers-demangling
demangling _ZN2CV1mEi ... CV::m(int)
demangling _Zwhatever ... <NULL>
be just as helpful, and, even potentially be helpful to debug
scenarios where GDB/libiberty might get the demangling wrong,
but not cause a crash?
Seems like a natural and easy sell to me.
--
Pedro Alves
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH 2/2 v2] Demangler crash handler
2014-05-19 20:41 ` Pedro Alves
@ 2014-05-20 2:43 ` Eli Zaretskii
2014-05-22 10:37 ` Gary Benson
2014-05-25 12:59 ` Florian Weimer
2 siblings, 0 replies; 9+ messages in thread
From: Eli Zaretskii @ 2014-05-20 2:43 UTC (permalink / raw)
To: Pedro Alves
Cc: gbenson, gdb-patches, aburgess, xdje42, fw, mark.kettenis, tromey
> Date: Mon, 19 May 2014 21:41:37 +0100
> From: Pedro Alves <palves@redhat.com>
> CC: gdb-patches@sourceware.org, aburgess@broadcom.com, xdje42@gmail.com,
> fw@deneb.enyo.de, mark.kettenis@xs4all.nl, tromey@redhat.com
>
> Wouldn't a new "set debug demangle on" option, that would make
> GDB output:
>
> (gdb) bt / whatever-gdb-command-that-triggers-demangling
> demangling _ZN2CV1mEi ... CV::m(int)
> demangling _Zwhatever ... <NULL>
>
> be just as helpful, and, even potentially be helpful to debug
> scenarios where GDB/libiberty might get the demangling wrong,
> but not cause a crash?
>
> Seems like a natural and easy sell to me.
Yes, I agree.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 2/2 v2] Demangler crash handler
2014-05-19 20:41 ` Pedro Alves
2014-05-20 2:43 ` Eli Zaretskii
@ 2014-05-22 10:37 ` Gary Benson
2014-05-25 12:59 ` Florian Weimer
2 siblings, 0 replies; 9+ messages in thread
From: Gary Benson @ 2014-05-22 10:37 UTC (permalink / raw)
To: Pedro Alves
Cc: Eli Zaretskii, gdb-patches, aburgess, xdje42, fw, mark.kettenis, tromey
Pedro Alves wrote:
> Wouldn't a new "set debug demangle on" option, that would make
> GDB output:
>
> (gdb) bt / whatever-gdb-command-that-triggers-demangling
> demangling _ZN2CV1mEi ... CV::m(int)
> demangling _Zwhatever ... <NULL>
>
> be just as helpful, and, even potentially be helpful to debug
> scenarios where GDB/libiberty might get the demangling wrong,
> but not cause a crash?
It would be as helpful for obtaining the symbol, although you would
get a lot more output (hundreds of thousands/millions of lines vs one
line). It would not help the user to debug their program because GDB
would still crash.
Thanks,
Gary
--
http://gbenson.net/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 2/2 v2] Demangler crash handler
2014-05-19 20:41 ` Pedro Alves
2014-05-20 2:43 ` Eli Zaretskii
2014-05-22 10:37 ` Gary Benson
@ 2014-05-25 12:59 ` Florian Weimer
2 siblings, 0 replies; 9+ messages in thread
From: Florian Weimer @ 2014-05-25 12:59 UTC (permalink / raw)
To: Pedro Alves
Cc: Gary Benson, Eli Zaretskii, gdb-patches, aburgess, xdje42,
mark.kettenis, tromey
* Pedro Alves:
> Wouldn't a new "set debug demangle on" option, that would make
> GDB output:
>
> (gdb) bt / whatever-gdb-command-that-triggers-demangling
> demangling _ZN2CV1mEi ... CV::m(int)
> demangling _Zwhatever ... <NULL>
>
> be just as helpful, and, even potentially be helpful to debug
> scenarios where GDB/libiberty might get the demangling wrong,
> but not cause a crash?
Here's another idea: You could strcpy the input string to a mapped
file (say, ~/.config/gdb/demangler) and read that on startup, printing
it and adding the offending symbol to a blacklist (say,
~/.config/gdb/demangler.blacklist).
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2014-05-25 12:59 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-19 11:48 [PATCH 2/2 v2] Demangler crash handler Gary Benson
2014-05-19 15:01 ` Eli Zaretskii
2014-05-19 15:48 ` Gary Benson
2014-05-19 16:55 ` Eli Zaretskii
2014-05-19 19:05 ` Gary Benson
2014-05-19 20:41 ` Pedro Alves
2014-05-20 2:43 ` Eli Zaretskii
2014-05-22 10:37 ` Gary Benson
2014-05-25 12:59 ` Florian Weimer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox