[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

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

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

--- Comment #28 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Simon Marchi <simark@sourceware.org>:

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

commit 08ac57714cd20e528efe9b4e169f3a2778cf6e30
Author: Simon Marchi <simon.marchi@polymtl.ca>
Date:   Tue Feb 23 13:37:44 2021 -0500

    gdb/dwarf: create and destroy dwarf2_per_bfd's CUs-to-expand queue

    As described in the log of patch "gdb/dwarf: add assertion in
    maybe_queue_comp_unit", it would happen that a call to
    maybe_queue_comp_unit would enqueue a CU in the to-expand queue while
    nothing up the stack was processing the queue.  This is not desirable,
    as items are then left lingering in the queue when we exit the
    dwarf2/read code.  This is an inconsistent state.

    The normal case of using the queue is when we go through
    dw2_do_instantiate_symtab and process_queue.  As depended-on CUs are
    found, they get added to the queue.  process_queue expands CUs until the
    queue is empty.

    To catch these cases where things are enqueued while nothing up the
    stack is processing the queue, change dwarf2_per_bfd::queue to be an
    optional.  The optional is instantiated in dwarf2_queue_guard, just
    before where we call process_queue.  In the dwarf2_queue_guard
    destructor, the optional gets reset.  Therefore, the queue object is
    instantiated only when something up the stack is handling it.  If
    another entry point tries to enqueue a CU for expansion, an assertion
    will fail and we know we have something to fix.

    dwarf2_queue_guard sounds like the good place for this, as it's
    currently responsible for making sure the queue gets cleared if we exit
    due to an error.

    This also allows asserting that when age_comp_units or remove_all_cus
    run, the queue is not instantiated, and gives us one more level of
    assurance that we won't free the DIEs of a CU that is in the
    CUs-to-expand queue.

    gdb/ChangeLog:

            PR gdb/26828
            * dwarf2/read.c (dwarf2_queue_guard) <dwarf2_queue_guard>:
            Instantiate queue.
            (~dwarf2_queue_guard): Clear queue.
            (queue_comp_unit): Assert that queue is
            instantiated.
            (process_queue): Adjust.
            * dwarf2/read.h (struct dwarf2_per_bfd) <queue>: Make optional.

    Change-Id: I8fe3d77845bb4ad3d309eac906acebe79d9f0a9d

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