Re: [PATCH 0/2] Demangler crash handler

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> 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.