This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 0/2] Demangler crash handler
- From: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- To: gbenson at redhat dot com
- Cc: tromey at redhat dot com, palves at redhat dot com, fw at deneb dot enyo dot de, mark dot kettenis at xs4all dot nl, gdb-patches at sourceware dot org
- Date: Thu, 22 May 2014 16:40:14 +0200 (CEST)
- Subject: Re: [PATCH 0/2] Demangler crash handler
- Authentication-results: sourceware.org; auth=none
- References: <20140509100656 dot GA4760 at blade dot nx> <201405091120 dot s49BKO1f010622 at glazunov dot sibelius dot xs4all dot nl> <87fvkhjqvs dot fsf at mid dot deneb dot enyo dot de> <53737737 dot 2030901 at redhat dot com> <87ppj8s7my dot fsf at fleche dot redhat dot com> <20140522140904 dot GD15598 at blade dot nx>
> Date: Thu, 22 May 2014 15:09:04 +0100
> From: Gary Benson <gbenson@redhat.com>
>
> Tom Tromey wrote:
> > Pedro> Then stealing a signal handler always has multi-threading
> > Pedro> considerations. E.g., gdb Python code could well spawn a
> > Pedro> thread that happens to call something that wants its own
> > Pedro> SIGSEGV handler... Signal handlers are per-process, not
> > Pedro> per-thread.
> >
> > That is true in theory but I think it is unlikely in practice. And,
> > should it happen -- well, the onus is on folks writing extensions
> > not to mess things up. That's the nature of the beast. And, sure,
> > it is messy, particularly if we ever upstream "import gdb", but even
> > so, signals are just fraught and this is not an ordinary enough
> > usage to justify preventing gdb from doing it.
>
> GDB installs handlers for INT, TERM, QUIT, HUP, FPE, WINCH, CONT,
> TTOU, TRAP, ALRM and TSTP, and some other platform-specific ones
> I didn't recognise. Is there anything that means SIGSEGV should
> be treated differently to all these other signals?
>From that list SIGFPE is probably a bogosity. I don't think the
SIGFPE handler will do the right thing on many OSes and architectures
supported by GDB, since it is unspecified whether the trapping
instruction will be re-executed upon return from the signal handler.
I'd argue that the SIGFPE handler is just as unhelpful as the SIGSEGV
handler you're proposing. Luckily, we don't seem to have a lot of
division-by-zero bugs in the code base.
> > The choice is really between SEGV catching and "somebody else
> > down the road fixes more demangler bugs".
>
> The demangler bugs will get fixed one way or another. The choice is:
> do we allow users to continue to use GDB while the bug they've hit is
> fixed, or, do we make them wait? In the expectation that they will
> put their own work aside while they fix GDB instead?
Unless there is a way to force a core dump (like internal_error()
offers) with the state at the point of the SIGSEGV in it, yes, we need
to make them wait or fix it themselves.
I'd really like to avoid adding a SIGSEGV handler altogether. But I'm
willing to compromise if the signal handler offers to opportunity to
create a core dump. Now doing so in a signal-safe way will be a bit
tricky of course.