[Bug python/28856] Python pretty printer causes stack overflow when printing frame arguments

["cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=28856

--- Comment #9 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Bruno Larsen <blarsen@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c29a6445a981cee5e8eebe3617ef5c049fd3409f

commit c29a6445a981cee5e8eebe3617ef5c049fd3409f
Author: Bruno Larsen <blarsen@redhat.com>
Date:   Mon Jul 25 14:06:37 2022 -0300

    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>

-- 
You are receiving this mail because:
You are on the CC list for the bug.