[Bug gdb/30547] [gdb, s390x, ppc64] segfault in for_each_block

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

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

--- Comment #8 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

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

commit f9582a22dba747ff0905f4c1a80d84f677eeb928
Author: Tom de Vries <tdevries@suse.de>
Date:   Tue Nov 28 10:31:25 2023 +0100

    [gdb] Fix segfault in for_each_block, part 1

    When running test-case gdb.base/vfork-follow-parent.exp on powerpc64
(likewise
    on s390x), I run into:
    ...
    (gdb) PASS: gdb.base/vfork-follow-parent.exp: \
      exec_file=vfork-follow-parent-exit: target-non-stop=on: non-stop=off: \
      resolution_method=schedule-multiple: print unblock_parent = 1
    continue^M
    Continuing.^M
    Reading symbols from vfork-follow-parent-exit...^M
    ^M
    ^M
    Fatal signal: Segmentation fault^M
    ----- Backtrace -----^M
    0x1027d3e7 gdb_internal_backtrace_1^M
            src/gdb/bt-utils.c:122^M
    0x1027d54f _Z22gdb_internal_backtracev^M
            src/gdb/bt-utils.c:168^M
    0x1057643f handle_fatal_signal^M
            src/gdb/event-top.c:889^M
    0x10576677 handle_sigsegv^M
            src/gdb/event-top.c:962^M
    0x3fffa7610477 ???^M
    0x103f2144 for_each_block^M
            src/gdb/dcache.c:199^M
    0x103f235b _Z17dcache_invalidateP13dcache_struct^M
            src/gdb/dcache.c:251^M
    0x10bde8c7 _Z24target_dcache_invalidatev^M
            src/gdb/target-dcache.c:50^M
    ...
    or similar.

    The root cause for the segmentation fault is that linux_is_uclinux gives an
    incorrect result: it should always return false, given that we're running
on a
    regular linux system, but instead it returns first true, then false.

    In more detail, the segmentation fault happens as follows:
    - a program space with an address space is created
    - a second program space is about to be created. maybe_new_address_space
      is called, and because linux_is_uclinux returns true,
maybe_new_address_space
      returns false, and no new address space is created
    - a second program space with the same address space is created
    - a program space is deleted. Because linux_is_uclinux now returns false,
      gdbarch_has_shared_address_space (current_inferior ()->arch ()) returns
      false, and the address space is deleted
    - when gdb uses the address space of the remaining program space, we run
into
      the segfault, because the address space is deleted.

    Hardcoding linux_is_uclinux to false makes the test-case pass.

    We leave addressing the root cause for the following commit in this series.

    For now, prevent the segmentation fault by making the address space a
refcounted
    object.

    This was already suggested here [1]:
    ...
    A better solution might be to have the address spaces be reference counted
    ...

    Tested on top of trunk on x86_64-linux and ppc64le-linux.
    Tested on top of gdb-14-branch on ppc64-linux.

    Co-Authored-By: Simon Marchi <simon.marchi@polymtl.ca>

    PR gdb/30547
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30547

    [1] https://sourceware.org/pipermail/gdb-patches/2023-October/202928.html

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