diff options
author | Bruno Larsen <blarsen@redhat.com> | 2022-07-25 14:06:37 -0300 |
---|---|---|
committer | Bruno Larsen <blarsen@redhat.com> | 2022-10-10 11:57:10 +0200 |
commit | c29a6445a981cee5e8eebe3617ef5c049fd3409f (patch) | |
tree | bdaf7bc8b1e30feb35995b1be6d1e059c680e7fd /missing | |
parent | bd2b40ac129b167f1a709589dee9c009a04a6e21 (diff) | |
download | fsf-binutils-gdb-c29a6445a981cee5e8eebe3617ef5c049fd3409f.zip fsf-binutils-gdb-c29a6445a981cee5e8eebe3617ef5c049fd3409f.tar.gz fsf-binutils-gdb-c29a6445a981cee5e8eebe3617ef5c049fd3409f.tar.bz2 |
gdb/frame: Add reinflation method for frame_info_ptr
Currently, despite having a smart pointer for frame_infos, GDB may
attempt to use an invalidated frame_info_ptr, which would cause internal
errors to happen. One such example has been documented as PR
python/28856, that happened when printing frame arguments calls an
inferior function.
To avoid failures, the smart wrapper was changed to also cache the frame
id, so the pointer can be reinflated later. For this to work, the
frame-id stuff had to be moved to their own .h file, which is included
by frame-info.h.
Frame_id caching is done explicitly using the prepare_reinflate method.
Caching is done manually so that only the pointers that need to be saved
will be, and reinflating has to be done manually using the reinflate
method because the get method and the -> operator must not change
the internals of the class. Finally, attempting to reinflate when the
pointer is being invalidated causes the following assertion errors:
check_ptrace_stopped_lwp_gone: assertion `lp->stopped` failed.
get_frame_pc: Assertion `frame->next != NULL` failed.
As for performance concerns, my personal testing with `time make
chec-perf GDB_PERFTEST_MODE=run` showed an actual reduction of around
10% of time running.
This commit also adds a testcase that exercises the python/28856 bug with
7 different triggers, run, continue, step, backtrace, finish, up and down.
Some of them can seem to be testing the same thing twice, but since this
test relies on stale pointers, there is always a chance that GDB got lucky
when testing, so better to test extra.
Regression tested on x86_64, using both gcc and clang.
Approved-by: Tom Tomey <tom@tromey.com>
Diffstat (limited to 'missing')
0 files changed, 0 insertions, 0 deletions