From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: tromey@redhat.com
Cc: gdb-patches@sourceware.org
Subject: Re: RFC: one approach to fixing PR 14100
Date: Wed, 08 Aug 2012 18:27:00 -0000 [thread overview]
Message-ID: <201208081827.q78IRV2J013294@glazunov.sibelius.xs4all.nl> (raw)
In-Reply-To: <87r4rpqnng.fsf@fleche.redhat.com> (message from Tom Tromey on Thu, 02 Aug 2012 10:11:47 -0600)
> From: Tom Tromey <tromey@redhat.com>
> Date: Thu, 02 Aug 2012 10:11:47 -0600
>
> PR 14100 concerns a way to crash gdb by C-c during a 'bt'.
>
> The way this happens is that dwarf2_frame_cache initializes the frame's
> prologue_cache. Then, it continues to do some more work, including
> (indirectly) reading target memory.
>
> Then, target_read invokes QUIT, throwing an exception.
> The cleanups are run, and eventually we get to
> frame_cleanup_after_sniffer, which asserts that prologue_cache==NULL.
>
> This fix assumes that what dwarf2_frame_cache is doing is not
> unreasonable, and simply clears the prologue_cache field.
>
> I am not sure whether this is really correct.
>
> Another approach would be to change dwarf2_frame_cache to set the
> prologue_cache at the end of its work rather than at the beginning.
> Then, I suppose, we'd have to document this restriction and audit all
> the other sniffers.
>
> Thoughts?
I'd say the gdb_assert() *is* the documentation of the restriction.
So I'd say the 2nd approach is the correct approach. Setting
prologue_cache at the very end certainly used to be the style that
most frame cache routines used.
> * frame.c (frame_cleanup_after_sniffer): Remove assert.
> Clear frame's prologue_cache.
> ---
> gdb/frame.c | 7 +++++--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/gdb/frame.c b/gdb/frame.c
> index e012f2d..edb379c 100644
> --- a/gdb/frame.c
> +++ b/gdb/frame.c
> @@ -2392,8 +2392,11 @@ frame_cleanup_after_sniffer (void *arg)
> struct frame_info *frame = arg;
>
> /* The sniffer should not allocate a prologue cache if it did not
> - match this frame. */
> - gdb_assert (frame->prologue_cache == NULL);
> + match this frame. We used to assert that prologue_cache was NULL
> + here -- however, that ran afoul of code paths where the
> + prologue_cache was set by the sniffer, but some later processing
> + called QUIT. */
> + frame->prologue_cache = NULL;
Not a big fan of these comments that try to document history. Better
to just state the reason for setting it to NULL.
prev parent reply other threads:[~2012-08-08 18:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-02 16:12 Tom Tromey
2012-08-03 16:03 ` Tom Tromey
2012-08-03 21:02 ` Jan Kratochvil
2012-08-04 1:58 ` Tom Tromey
2012-08-04 6:26 ` Jan Kratochvil
2012-08-06 15:31 ` Tom Tromey
2012-08-06 15:45 ` Jan Kratochvil
2012-08-09 9:42 ` Mark Kettenis
2012-08-09 9:46 ` Jan Kratochvil
2012-08-09 20:12 ` Tom Tromey
2012-08-08 18:27 ` Mark Kettenis [this message]
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=201208081827.q78IRV2J013294@glazunov.sibelius.xs4all.nl \
--to=mark.kettenis@xs4all.nl \
--cc=gdb-patches@sourceware.org \
--cc=tromey@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