* [PATCH 1/2] [gdb/tui] Fix segfault in tui_find_disassembly_address
@ 2023-09-05 15:03 Tom de Vries
2023-09-05 15:03 ` [PATCH 2/2] [gdb/tui] Only handle code sections in tui_find_backward_disassembly_start_address Tom de Vries
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Tom de Vries @ 2023-09-05 15:03 UTC (permalink / raw)
To: gdb-patches
PR29040 describes a FAIL for test-case gdb.threads/next-fork-other-thread.exp
and target board unix/-m32.
The FAIL happens due to the test executable running into an assert, which is
caused by a forked child segfaulting, like so:
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00000000 in ?? ()
...
I tried to reproduce the segfault with exec next-fork-other-thread-fork, using
TUI layout asm.
I set a breakpoint at fork and ran to the breakpoint, and somewhere during the
following session I ran into a gdb segfault here in
tui_find_disassembly_address:
...
/* Disassemble forward. */
next_addr = tui_disassemble (gdbarch, asm_lines, new_low, max_lines);
last_addr = asm_lines.back ().addr;
...
due to asm_lines being empty after the call to tui_disassemble, while
asm_lines.back () assumes that it's not empty.
I have not been able to reproduce that segfault in that original setting, I'm
not sure of the exact scenario (though looking back it probably involved
"set detach-on-fork off").
What likely happened is that I managed to reproduce PR29040, and TUI (attempted
to) display the disassembly for address 0, which led to the gdb segfault.
When gdb_print_insn encounters an insn it cannot print because it can't read
the memory, it throws a MEMORY_ERROR that is caught by tui_disassemble.
The specific bit that causes the gdb segfault is that if gdb_print_insn throws
a MEMORY_ERROR for the first insn in tui_disassemble, it returns an empty
asm_lines.
FWIW, I did manage to reproduce the gdb segfault as follows:
...
$ gdb -q \
-iex "set pagination off" \
/usr/bin/rustc \
-ex "set breakpoint pending on" \
-ex "b dl_main" \
-ex run \
-ex "up 4" \
-ex "layout asm" \
-ex "print \$pc"
...
<TUI>
...
$1 = (void (*)()) 0x1
(gdb)
...
Now press <up>, and the segfault triggers.
Fix the segfault by handling asm_lines.empty () results of tui_disassemble in
tui_find_disassembly_address.
I've written a unit test that exercises this scenario.
Tested on x86_64-linux.
PR tui/30823
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30823
---
gdb/tui/tui-disasm.c | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/gdb/tui/tui-disasm.c b/gdb/tui/tui-disasm.c
index f0b55769d71..03c78aa1291 100644
--- a/gdb/tui/tui-disasm.c
+++ b/gdb/tui/tui-disasm.c
@@ -41,6 +41,8 @@
#include "objfiles.h"
#include "cli/cli-style.h"
#include "tui/tui-location.h"
+#include "gdbsupport/selftest.h"
+#include "inferior.h"
#include "gdb_curses.h"
@@ -203,6 +205,8 @@ tui_find_disassembly_address (struct gdbarch *gdbarch, CORE_ADDR pc, int from)
instruction fails to disassemble we will take the address of the
previous instruction that did disassemble as the result. */
tui_disassemble (gdbarch, asm_lines, pc, max_lines + 1);
+ if (asm_lines.empty ())
+ return pc;
new_low = asm_lines.back ().addr;
}
else
@@ -244,6 +248,8 @@ tui_find_disassembly_address (struct gdbarch *gdbarch, CORE_ADDR pc, int from)
/* Disassemble forward. */
next_addr = tui_disassemble (gdbarch, asm_lines, new_low, max_lines);
+ if (asm_lines.empty ())
+ break;
last_addr = asm_lines.back ().addr;
/* If disassembling from the current value of NEW_LOW reached PC
@@ -522,3 +528,36 @@ tui_disasm_window::display_start_addr (struct gdbarch **gdbarch_p,
*gdbarch_p = m_gdbarch;
*addr_p = m_start_line_or_addr.u.addr;
}
+
+#if GDB_SELF_TEST
+namespace selftests {
+namespace tui {
+namespace disasm {
+
+static void
+run_tests ()
+{
+ if (current_inferior () != nullptr)
+ {
+ struct gdbarch *gdbarch = current_inferior ()->gdbarch;
+
+ /* Check that tui_find_disassembly_address robustly handles the case of
+ being passed a PC for which gdb_print_insn throws a MEMORY_ERROR. */
+ SELF_CHECK (tui_find_disassembly_address (gdbarch, 0, 1) == 0);
+ SELF_CHECK (tui_find_disassembly_address (gdbarch, 0, -1) == 0);
+ }
+}
+
+} /* namespace disasm */
+} /* namespace tui */
+} /* namespace selftests */
+#endif /* GDB_SELF_TEST */
+
+void _initialize_tui_disasm ();
+void
+_initialize_tui_disasm ()
+{
+#if GDB_SELF_TEST
+ selftests::register_test ("tui-disasm", selftests::tui::disasm::run_tests);
+#endif
+}
base-commit: b6ac461ace19ba19aaf135a028df4e67e47e21d7
--
2.35.3
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH 2/2] [gdb/tui] Only handle code sections in tui_find_backward_disassembly_start_address
2023-09-05 15:03 [PATCH 1/2] [gdb/tui] Fix segfault in tui_find_disassembly_address Tom de Vries
@ 2023-09-05 15:03 ` Tom de Vries
2023-09-27 16:15 ` Kevin Buettner
2023-09-26 15:22 ` [PING][PATCH 1/2] [gdb/tui] Fix segfault in tui_find_disassembly_address Tom de Vries
2023-09-27 16:10 ` [PATCH " Kevin Buettner
2 siblings, 1 reply; 8+ messages in thread
From: Tom de Vries @ 2023-09-05 15:03 UTC (permalink / raw)
To: gdb-patches
After adding a unit test in gdb/tui/tui-disasm.c excercising
tui_find_disassembly_address, I decided to try to extend it using addresses
around section borders.
The new test was very slow (when using gdb as inferior, as is done in
gdb.gdb/unittest.exp), due to disassembling entire non-code sections.
Fix this this by limiting tui_find_backward_disassembly_start_address to
SEC_CODE sections.
FWIW, compared to other self-tests it's still somewhat slow:
...
(gdb) maint selftest
...
Command execution time: 1.535391 (cpu), 1.571246 (wall)
(gdb) maint selftest tui-disasm
...
Command execution time: 0.482022 (cpu), 0.482028 (wall)
...
This is for calling gdb_print_insn ~550 times.
Tested on x86_64-linux.
---
gdb/tui/tui-disasm.c | 50 +++++++++++++++++++++++++++++++++++++-------
1 file changed, 43 insertions(+), 7 deletions(-)
diff --git a/gdb/tui/tui-disasm.c b/gdb/tui/tui-disasm.c
index 03c78aa1291..c31ab5b0680 100644
--- a/gdb/tui/tui-disasm.c
+++ b/gdb/tui/tui-disasm.c
@@ -46,6 +46,8 @@
#include "gdb_curses.h"
+#include <unordered_set>
+
struct tui_asm_line
{
CORE_ADDR addr;
@@ -164,6 +166,15 @@ tui_disassemble (struct gdbarch *gdbarch,
static CORE_ADDR
tui_find_backward_disassembly_start_address (CORE_ADDR addr)
{
+ struct obj_section *section = find_pc_section (addr);
+ /* Don't handle addresses not in a known section. */
+ if (section == nullptr)
+ return addr;
+
+ /* Only handle sections with only code. */
+ if ((section->the_bfd_section->flags & SEC_CODE) == 0)
+ return addr;
+
struct bound_minimal_symbol msym, msym_prev;
msym = lookup_minimal_symbol_by_pc_section (addr - 1, nullptr,
@@ -174,13 +185,8 @@ tui_find_backward_disassembly_start_address (CORE_ADDR addr)
else if (msym_prev.minsym != nullptr)
return msym_prev.value_address ();
- /* Find the section that ADDR is in, and look for the start of the
- section. */
- struct obj_section *section = find_pc_section (addr);
- if (section != NULL)
- return section->addr ();
-
- return addr;
+ /* Use the start of the section. */
+ return section->addr ();
}
/* Find the disassembly address that corresponds to FROM lines above
@@ -545,6 +551,36 @@ run_tests ()
being passed a PC for which gdb_print_insn throws a MEMORY_ERROR. */
SELF_CHECK (tui_find_disassembly_address (gdbarch, 0, 1) == 0);
SELF_CHECK (tui_find_disassembly_address (gdbarch, 0, -1) == 0);
+
+ /* Poke around the edges of sections. */
+ gdbarch_iterate_over_objfiles_in_search_order
+ (target_gdbarch (),
+ [gdbarch] (objfile *obj)
+ {
+ std::unordered_set<CORE_ADDR> visited;
+
+ /* Already done above. */
+ visited.insert (0);
+
+ for (obj_section *osect : obj->sections ())
+ {
+ CORE_ADDR first_addr = osect->addr ();
+ CORE_ADDR last_addr = osect->endaddr () - 1;
+
+ for (auto addr_ : { first_addr, last_addr })
+ for (int offset = -1; offset <= 1; ++offset)
+ {
+ CORE_ADDR addr = addr_ + offset;
+ if (visited.find (addr) != visited.end ())
+ continue;
+
+ tui_find_disassembly_address (gdbarch, addr, 1);
+ tui_find_disassembly_address (gdbarch, addr, -1);
+ visited.insert (addr);
+ }
+ }
+ return false;
+ }, nullptr);
}
}
--
2.35.3
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] [gdb/tui] Only handle code sections in tui_find_backward_disassembly_start_address
2023-09-05 15:03 ` [PATCH 2/2] [gdb/tui] Only handle code sections in tui_find_backward_disassembly_start_address Tom de Vries
@ 2023-09-27 16:15 ` Kevin Buettner
2023-09-28 18:23 ` Tom de Vries
0 siblings, 1 reply; 8+ messages in thread
From: Kevin Buettner @ 2023-09-27 16:15 UTC (permalink / raw)
To: Tom de Vries via Gdb-patches; +Cc: Tom de Vries
On Tue, 5 Sep 2023 17:03:39 +0200
Tom de Vries via Gdb-patches <gdb-patches@sourceware.org> wrote:
> Fix this this by limiting tui_find_backward_disassembly_start_address to
> SEC_CODE sections.
What will happen when a user attempts to use the TUI to look at / debug
dynamically generated code?
Kevin
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] [gdb/tui] Only handle code sections in tui_find_backward_disassembly_start_address
2023-09-27 16:15 ` Kevin Buettner
@ 2023-09-28 18:23 ` Tom de Vries
0 siblings, 0 replies; 8+ messages in thread
From: Tom de Vries @ 2023-09-28 18:23 UTC (permalink / raw)
To: Kevin Buettner, Tom de Vries via Gdb-patches
On 9/27/23 18:15, Kevin Buettner wrote:
> On Tue, 5 Sep 2023 17:03:39 +0200
> Tom de Vries via Gdb-patches <gdb-patches@sourceware.org> wrote:
>
>> Fix this this by limiting tui_find_backward_disassembly_start_address to
>> SEC_CODE sections.
>
> What will happen when a user attempts to use the TUI to look at / debug
> dynamically generated code?
>
Hi, and thanks for the review(s).
Hm, I don't know, good question.
Maybe it will be possible to detect these cases and expand the search,
and by default do a more narrow search.
I'm not familiar with the dynamically generated code scenarios and
support in gdb, so I'm dropping this for now.
Thanks,
- Tom
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PING][PATCH 1/2] [gdb/tui] Fix segfault in tui_find_disassembly_address
2023-09-05 15:03 [PATCH 1/2] [gdb/tui] Fix segfault in tui_find_disassembly_address Tom de Vries
2023-09-05 15:03 ` [PATCH 2/2] [gdb/tui] Only handle code sections in tui_find_backward_disassembly_start_address Tom de Vries
@ 2023-09-26 15:22 ` Tom de Vries
2023-09-27 16:10 ` [PATCH " Kevin Buettner
2 siblings, 0 replies; 8+ messages in thread
From: Tom de Vries @ 2023-09-26 15:22 UTC (permalink / raw)
To: gdb-patches
On 9/5/23 17:03, Tom de Vries via Gdb-patches wrote:
> PR29040 describes a FAIL for test-case gdb.threads/next-fork-other-thread.exp
> and target board unix/-m32.
>
> The FAIL happens due to the test executable running into an assert, which is
> caused by a forked child segfaulting, like so:
> ...
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 0x00000000 in ?? ()
> ...
>
> I tried to reproduce the segfault with exec next-fork-other-thread-fork, using
> TUI layout asm.
>
> I set a breakpoint at fork and ran to the breakpoint, and somewhere during the
> following session I ran into a gdb segfault here in
> tui_find_disassembly_address:
> ...
> /* Disassemble forward. */
> next_addr = tui_disassemble (gdbarch, asm_lines, new_low, max_lines);
> last_addr = asm_lines.back ().addr;
> ...
> due to asm_lines being empty after the call to tui_disassemble, while
> asm_lines.back () assumes that it's not empty.
>
> I have not been able to reproduce that segfault in that original setting, I'm
> not sure of the exact scenario (though looking back it probably involved
> "set detach-on-fork off").
>
> What likely happened is that I managed to reproduce PR29040, and TUI (attempted
> to) display the disassembly for address 0, which led to the gdb segfault.
>
> When gdb_print_insn encounters an insn it cannot print because it can't read
> the memory, it throws a MEMORY_ERROR that is caught by tui_disassemble.
>
> The specific bit that causes the gdb segfault is that if gdb_print_insn throws
> a MEMORY_ERROR for the first insn in tui_disassemble, it returns an empty
> asm_lines.
>
> FWIW, I did manage to reproduce the gdb segfault as follows:
> ...
> $ gdb -q \
> -iex "set pagination off" \
> /usr/bin/rustc \
> -ex "set breakpoint pending on" \
> -ex "b dl_main" \
> -ex run \
> -ex "up 4" \
> -ex "layout asm" \
> -ex "print \$pc"
> ...
> <TUI>
> ...
> $1 = (void (*)()) 0x1
> (gdb)
> ...
> Now press <up>, and the segfault triggers.
>
> Fix the segfault by handling asm_lines.empty () results of tui_disassemble in
> tui_find_disassembly_address.
>
> I've written a unit test that exercises this scenario.
>
> Tested on x86_64-linux.
>
Ping for both patches in the series.
Thanks,
- Tom
> PR tui/30823
> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30823
> ---
> gdb/tui/tui-disasm.c | 39 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
>
> diff --git a/gdb/tui/tui-disasm.c b/gdb/tui/tui-disasm.c
> index f0b55769d71..03c78aa1291 100644
> --- a/gdb/tui/tui-disasm.c
> +++ b/gdb/tui/tui-disasm.c
> @@ -41,6 +41,8 @@
> #include "objfiles.h"
> #include "cli/cli-style.h"
> #include "tui/tui-location.h"
> +#include "gdbsupport/selftest.h"
> +#include "inferior.h"
>
> #include "gdb_curses.h"
>
> @@ -203,6 +205,8 @@ tui_find_disassembly_address (struct gdbarch *gdbarch, CORE_ADDR pc, int from)
> instruction fails to disassemble we will take the address of the
> previous instruction that did disassemble as the result. */
> tui_disassemble (gdbarch, asm_lines, pc, max_lines + 1);
> + if (asm_lines.empty ())
> + return pc;
> new_low = asm_lines.back ().addr;
> }
> else
> @@ -244,6 +248,8 @@ tui_find_disassembly_address (struct gdbarch *gdbarch, CORE_ADDR pc, int from)
>
> /* Disassemble forward. */
> next_addr = tui_disassemble (gdbarch, asm_lines, new_low, max_lines);
> + if (asm_lines.empty ())
> + break;
> last_addr = asm_lines.back ().addr;
>
> /* If disassembling from the current value of NEW_LOW reached PC
> @@ -522,3 +528,36 @@ tui_disasm_window::display_start_addr (struct gdbarch **gdbarch_p,
> *gdbarch_p = m_gdbarch;
> *addr_p = m_start_line_or_addr.u.addr;
> }
> +
> +#if GDB_SELF_TEST
> +namespace selftests {
> +namespace tui {
> +namespace disasm {
> +
> +static void
> +run_tests ()
> +{
> + if (current_inferior () != nullptr)
> + {
> + struct gdbarch *gdbarch = current_inferior ()->gdbarch;
> +
> + /* Check that tui_find_disassembly_address robustly handles the case of
> + being passed a PC for which gdb_print_insn throws a MEMORY_ERROR. */
> + SELF_CHECK (tui_find_disassembly_address (gdbarch, 0, 1) == 0);
> + SELF_CHECK (tui_find_disassembly_address (gdbarch, 0, -1) == 0);
> + }
> +}
> +
> +} /* namespace disasm */
> +} /* namespace tui */
> +} /* namespace selftests */
> +#endif /* GDB_SELF_TEST */
> +
> +void _initialize_tui_disasm ();
> +void
> +_initialize_tui_disasm ()
> +{
> +#if GDB_SELF_TEST
> + selftests::register_test ("tui-disasm", selftests::tui::disasm::run_tests);
> +#endif
> +}
>
> base-commit: b6ac461ace19ba19aaf135a028df4e67e47e21d7
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] [gdb/tui] Fix segfault in tui_find_disassembly_address
2023-09-05 15:03 [PATCH 1/2] [gdb/tui] Fix segfault in tui_find_disassembly_address Tom de Vries
2023-09-05 15:03 ` [PATCH 2/2] [gdb/tui] Only handle code sections in tui_find_backward_disassembly_start_address Tom de Vries
2023-09-26 15:22 ` [PING][PATCH 1/2] [gdb/tui] Fix segfault in tui_find_disassembly_address Tom de Vries
@ 2023-09-27 16:10 ` Kevin Buettner
2023-09-28 20:57 ` Tom de Vries
2 siblings, 1 reply; 8+ messages in thread
From: Kevin Buettner @ 2023-09-27 16:10 UTC (permalink / raw)
To: Tom de Vries via Gdb-patches; +Cc: Tom de Vries
Hi Tom,
On Tue, 5 Sep 2023 17:03:38 +0200
Tom de Vries via Gdb-patches <gdb-patches@sourceware.org> wrote:
> Fix the segfault by handling asm_lines.empty () results of tui_disassemble in
> tui_find_disassembly_address.
>
> I've written a unit test that exercises this scenario.
>
> Tested on x86_64-linux.
>
> PR tui/30823
> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30823
I don't know this area very well, but your explanation and patch look
reasonable to me.
Reviewed-by: Kevin Buettner <kevinb@redhat.com>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] [gdb/tui] Fix segfault in tui_find_disassembly_address
2023-09-27 16:10 ` [PATCH " Kevin Buettner
@ 2023-09-28 20:57 ` Tom de Vries
2023-09-29 10:08 ` Tom de Vries
0 siblings, 1 reply; 8+ messages in thread
From: Tom de Vries @ 2023-09-28 20:57 UTC (permalink / raw)
To: Kevin Buettner, Tom de Vries via Gdb-patches
On 9/27/23 18:10, Kevin Buettner wrote:
> Hi Tom,
>
> On Tue, 5 Sep 2023 17:03:38 +0200
> Tom de Vries via Gdb-patches <gdb-patches@sourceware.org> wrote:
>
>> Fix the segfault by handling asm_lines.empty () results of tui_disassemble in
>> tui_find_disassembly_address.
>>
>> I've written a unit test that exercises this scenario.
>>
>> Tested on x86_64-linux.
>>
>> PR tui/30823
>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30823
>
> I don't know this area very well, but your explanation and patch look
> reasonable to me.
>
> Reviewed-by: Kevin Buettner <kevinb@redhat.com>
Thanks for the review.
I've committed this, but I now see there's a new warning:
...
gdb/tui/tui-disasm.c: In function ‘CORE_ADDR
tui_find_disassembly_address(gdbarch*, CORE_ADDR, int)’:
gdb/tui/tui-disasm.c:293:7: warning: ‘last_addr’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
if (last_addr < pc)
^~
...
I'll take a look.
Thanks,
- Tom
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] [gdb/tui] Fix segfault in tui_find_disassembly_address
2023-09-28 20:57 ` Tom de Vries
@ 2023-09-29 10:08 ` Tom de Vries
0 siblings, 0 replies; 8+ messages in thread
From: Tom de Vries @ 2023-09-29 10:08 UTC (permalink / raw)
To: Kevin Buettner, Tom de Vries via Gdb-patches
On 9/28/23 22:57, Tom de Vries wrote:
> On 9/27/23 18:10, Kevin Buettner wrote:
>> Hi Tom,
>>
>> On Tue, 5 Sep 2023 17:03:38 +0200
>> Tom de Vries via Gdb-patches <gdb-patches@sourceware.org> wrote:
>>
>>> Fix the segfault by handling asm_lines.empty () results of
>>> tui_disassemble in
>>> tui_find_disassembly_address.
>>>
>>> I've written a unit test that exercises this scenario.
>>>
>>> Tested on x86_64-linux.
>>>
>>> PR tui/30823
>>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30823
>>
>> I don't know this area very well, but your explanation and patch look
>> reasonable to me.
>>
>> Reviewed-by: Kevin Buettner <kevinb@redhat.com>
>
> Thanks for the review.
>
> I've committed this, but I now see there's a new warning:
> ...
> gdb/tui/tui-disasm.c: In function ‘CORE_ADDR
> tui_find_disassembly_address(gdbarch*, CORE_ADDR, int)’:
> gdb/tui/tui-disasm.c:293:7: warning: ‘last_addr’ may be used
> uninitialized in this function [-Wmaybe-uninitialized]
> if (last_addr < pc)
> ^~
> ...
>
> I'll take a look.
I've submitted a fix here (
https://sourceware.org/pipermail/gdb-patches/2023-September/202849.html ).
Thanks,
- Tom
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2023-09-29 10:08 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-09-05 15:03 [PATCH 1/2] [gdb/tui] Fix segfault in tui_find_disassembly_address Tom de Vries
2023-09-05 15:03 ` [PATCH 2/2] [gdb/tui] Only handle code sections in tui_find_backward_disassembly_start_address Tom de Vries
2023-09-27 16:15 ` Kevin Buettner
2023-09-28 18:23 ` Tom de Vries
2023-09-26 15:22 ` [PING][PATCH 1/2] [gdb/tui] Fix segfault in tui_find_disassembly_address Tom de Vries
2023-09-27 16:10 ` [PATCH " Kevin Buettner
2023-09-28 20:57 ` Tom de Vries
2023-09-29 10:08 ` Tom de Vries
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).