diff options
author | Tom de Vries <tdevries@suse.de> | 2023-11-28 10:31:25 +0100 |
---|---|---|
committer | Tom de Vries <tdevries@suse.de> | 2023-11-28 10:31:25 +0100 |
commit | f9582a22dba747ff0905f4c1a80d84f677eeb928 (patch) | |
tree | 042f98562a1dc37eb3a6e964f65afb4e942fd138 /gdb/displaced-stepping.c | |
parent | 31477859c0c2a9b79a649be98830afebb9aa1d46 (diff) | |
download | fsf-binutils-gdb-f9582a22dba747ff0905f4c1a80d84f677eeb928.zip fsf-binutils-gdb-f9582a22dba747ff0905f4c1a80d84f677eeb928.tar.gz fsf-binutils-gdb-f9582a22dba747ff0905f4c1a80d84f677eeb928.tar.bz2 |
[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
Diffstat (limited to 'gdb/displaced-stepping.c')
-rw-r--r-- | gdb/displaced-stepping.c | 3 |
1 files changed, 2 insertions, 1 deletions
diff --git a/gdb/displaced-stepping.c b/gdb/displaced-stepping.c index 9d45013..410cfd9 100644 --- a/gdb/displaced-stepping.c +++ b/gdb/displaced-stepping.c @@ -63,7 +63,8 @@ displaced_step_buffers::prepare (thread_info *thread, CORE_ADDR &displaced_pc) for (displaced_step_buffer &candidate : m_buffers) { - bool bp_in_range = breakpoint_in_range_p (thread->inf->aspace, candidate.addr, len); + bool bp_in_range = breakpoint_in_range_p (thread->inf->aspace.get (), + candidate.addr, len); bool is_free = candidate.current_thread == nullptr; if (!bp_in_range) |