From: Tom Tromey <tromey@redhat.com>
To: Pedro Alves <palves@redhat.com>
Cc: Florian Weimer <fw@deneb.enyo.de>,
Mark Kettenis <mark.kettenis@xs4all.nl>,
gbenson@redhat.com, gdb-patches@sourceware.org
Subject: Re: [PATCH 0/2] Demangler crash handler
Date: Tue, 20 May 2014 17:05:00 -0000 [thread overview]
Message-ID: <87ppj8s7my.fsf@fleche.redhat.com> (raw)
In-Reply-To: <53737737.2030901@redhat.com> (Pedro Alves's message of "Wed, 14 May 2014 15:01:27 +0100")
>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
Pedro> I have to admit I'm not super keen on using signals for this either.
Pedro> For one, not all bugs trigger segmentation faults.
That is true, but the goal of the patch is to cheaply improve gdb's
behavior in some failure modes, not to solve every problem.
I think this is warranted due to known properties of the demangler.
First, it is complicated. Second, it is hard to test well. Third,
there's been a history of new demangler features being rolled out with
insufficient testing, and we can reasonably expect that to continue.
Fourth, the bugs in question have a very severe effect on gdb users --
you simply cannot debug -- whereas the effect on other users of the
demangler is slight (this is why I think we can expect to see more
demangler bugs of a similar nature).
Pedro> Then stealing a signal handler always has multi-threading
Pedro> considerations. E.g., gdb Python code could well spawn a thread
Pedro> that happens to call something that wants its own SIGSEGV
Pedro> handler... Signal handlers are per-process, not 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.
Pedro> Then we'd add a demangle_assert macro to the demangler, similar to
Pedro> gdb_assert, that calls that hook if the assertion fails. And then
Pedro> we could sprinkle the demangler with assertions.
Pedro> I think that'd be easy to do, and I'd think it's much cleaner
Pedro> and robust.
This would be an improvement but it isn't really under consideration.
The demangler isn't the most important thing we're working on, and
nobody is going to spend the time adding assertions to it. And, even if
they did, the crash handler would still useful, just hopefully used
somewhat less. This is because bugs happen even when there are many
assertions in place.
The choice is really between SEGV catching and "somebody else down the
road fixes more demangler bugs".
Tom
next prev parent reply other threads:[~2014-05-20 17:05 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
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 [this message]
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=87ppj8s7my.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=fw@deneb.enyo.de \
--cc=gbenson@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=mark.kettenis@xs4all.nl \
--cc=palves@redhat.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