From: Tom Tromey <tom@tromey.com>
To: Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH] gdb/stack.c: avoid stale pointers when printing frame arguments
Date: Mon, 04 Apr 2022 13:06:29 -0600 [thread overview]
Message-ID: <87y20khdmy.fsf@tromey.com> (raw)
In-Reply-To: <20220328175729.52215-1-blarsen@redhat.com> (Bruno Larsen via Gdb-patches's message of "Mon, 28 Mar 2022 14:57:29 -0300")
>>>>> "Bruno" == Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org> writes:
Bruno> To fix this solution, we must ensure that the frame cache is up to date
Bruno> after printing any arguments, so we cache the frame_id of the pointer
Bruno> that will become stale, and reset that pointer using frame_find_by_id.
Makes sense.
Bruno> We have to use it directly instead of using the simpler
Bruno> scoped_restore_selected_frame because the latter may save a null frame_ID
Bruno> when the saved frame is the current frame, and restoring the null frame
Bruno> wouldn't rebuild the frame cache.
Also it's not the selected frame that is being restored.
Bruno> This commit also adds a testcase that exercises this codepath with 7
Bruno> different triggers, run, continue, step, backtrace, finish, up and down.
Bruno> Some of them can seem to be testing the same thing twice, but since this
Bruno> test relies on stale pointers, there is always a chance that GDB got lucky
Bruno> when testing, so better to test extra.
One thing I've toyed with a couple of times is replacing "frame_info *"
with a "frame_info_ptr" smart pointer that automatically clears itself
when the frame cache is cleared. This would then cause reliable crashes
in scenarios like this -- with the caveat, of course, that some test has
to actually exercise the failing code path.
This got bogged down a bit because I then tried to have frame_info_ptr
automatically reinflate, which turns out to be hard for some reason I
don't fully recall.
Maybe a reinflating frame_info_ptr could be done piecemeal, starting
with the spots you identified in this patch, though...
Bruno> diff --git a/gdb/infrun.c b/gdb/infrun.c
Bruno> index 737710f5bae..bf519737d12 100644
Bruno> --- a/gdb/infrun.c
Bruno> +++ b/gdb/infrun.c
Bruno> @@ -8308,8 +8308,15 @@ print_stop_location (const target_waitstatus &ws)
Bruno> SRC_LINE: Print only source line
Bruno> LOCATION: Print only location
Bruno> SRC_AND_LOC: Print location and source line. */
Bruno> + int frame_cache_count = get_frame_cache_generation ();
Bruno> if (do_frame_printing)
Bruno> print_stack_frame (get_selected_frame (NULL), 0, source_flag, 1);
Bruno> + /* If there are more frame cache generations after we print a stack frame
Bruno> + we may have invalidated the cache with a pretty printer.
Bruno> + If this happened, the safest option is to restart the whole cache,
Bruno> + otherwise GDB may crash because of an use-after-free bug. */
Bruno> + if (frame_cache_count < get_frame_cache_generation ())
Bruno> + reinit_frame_cache ();
Bruno> }
I don't think I understand this bit. If the generation changes, hasn't
the cache already been cleared?
Bruno> + for (struct frame_id fid;
Bruno> fi && (i <= frame_high || frame_high == -1);
Bruno> i++, fi = get_prev_frame (fi))
Better to declare fid where it's first used.
Tom
next prev parent reply other threads:[~2022-04-04 19:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-28 17:57 Bruno Larsen
2022-04-04 19:06 ` Tom Tromey [this message]
2022-04-04 21:42 ` Bruno Larsen
2022-04-05 13:58 ` Tom Tromey
2022-04-05 14:47 ` Bruno Larsen
2022-04-05 16:39 ` Andrew Burgess
2022-04-05 16:54 ` Andrew Burgess
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=87y20khdmy.fsf@tromey.com \
--to=tom@tromey.com \
--cc=gdb-patches@sourceware.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).