This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: catch SIGSEGV in the demangler


Tom> I'm primarily interested in opinions on whether this is even a good
Tom> idea.  I'm on the fence about it myself.

Pedro> Me too.  I'd rather all bugs in the demangler were fixed.  :-)

Yeah.  But there will be future crashes too.

Tom> It's far from clear that it is safe to call throw_exception from a
Tom> signal handler.

Pedro> Yeah.  It's risky.  It uses the heap (malloc/free), so
Pedro> if the wrapped code crashes within malloc or free (e.g.,
Pedro> corrupted heap), then the handler may e.g., deadlock
Pedro> (the handler crashing wouldn't be that bad, since we're
Pedro> already crashing).  It also calls clear_sigint_flag,
Pedro> which with python enabled is probably not very reentrant or
Pedro> async signal safe either, as it calls into python, which I can
Pedro> imagine to be a problem is you wrap all SEGVs throughtout
Pedro> GDB's execution, instead of just over the demangler, which
Pedro> won't normally call into python.

I think Python isn't an issue.  PyOS_InterruptOccurred is reasonably
unobjectionable.  It is a low-level thing, part of Python's own
signal-handling code.

We probably shouldn't call clear_quit_flag in there at all.
It wouldn't be hard to avoid this in the SEGV case at least.
That way a SEGV wouldn't obscure a QUIT.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]