We have a debug stub that speaks RSP that we use on various bare-metal targets. To start running a program from GDB, we typically use a sequence of commands like: file a.out target remote ... load continue But, sometimes the "target remote" command gives an error: /path/to/gdb/inline-frame.c:168: internal-error: inline_frame_this_id: Assertion `frame_id_p (*this_id)' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. What's happening here is that GDB is trying to interpret the target state reported by the stub in response to the '?' request, in order to print something about the current stack frame. But, the stub is reporting whatever the target was doing when the connection was made, and GDB is interpreting the reported PC and stack contents against a program that hasn't been loaded or started to execute yet, and getting quite confused. Looking at the code for inline_frame_this_id, I think all the assertions it contains are incorrect. I think the corresponding sniffer ought to be testing all those situations up front and rejecting the unwinder as not applicable. If that isn't possible, maybe something can catch the error and print some user-friendly message about a mismatch between the program file and target state?
I'm encoutering a very similar result in a different situation. In my case the binary was compiled under windows and has "wrong" slashes in the debug info. So gdb is unable to find source files.
UPDATE: I've patched gdb to simply return from the function inline_frame_this_id, when the assertion would trigger on the next line. This seems to be a "workaround" for me, as it allows me to continue to debug the target. (as opposed to getting stuck in the assertion failed abort? questions loop).
Hi, I am experiencing a similar problem when the stack has been corrupted: $ gdb-multiarch vmlinux GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2 Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from vmlinux... gdb$ target extended-remote :3333 Remote debugging using :3333 memtest (size=<optimized out>, start_phys=<optimized out>, pattern=<optimized out>) at mm/memtest.c:49 49 *p = pattern; gdb$ bt #0 memtest (size=<optimized out>, start_phys=<optimized out>, pattern=<optimized out>) at mm/memtest.c:49 #1 do_one_pass (end=<optimized out>, start=<optimized out>, pattern=<optimized out>) at mm/memtest.c:78 #2 early_memtest (/build/gdb-OxeNvS/gdb-9.2/gdb/inline-frame.c:155: internal-error: void inline_frame_this_id(frame_info*, void**, frame_id*): Assertion `frame_id_p (*this_id)' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. This is a bug, please report it. For instructions, see: <http://www.gnu.org/software/gdb/bugs/>. Aborted (core dumped)
(In reply to Sean Anderson from comment #3) > Hi, > > I am experiencing a similar problem when the stack has been corrupted: > > $ gdb-multiarch vmlinux > GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2 > Copyright (C) 2020 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "x86_64-linux-gnu". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from vmlinux... > gdb$ target extended-remote :3333 > Remote debugging using :3333 > memtest (size=<optimized out>, start_phys=<optimized out>, > pattern=<optimized out>) at mm/memtest.c:49 > 49 *p = pattern; > gdb$ bt > #0 memtest (size=<optimized out>, start_phys=<optimized out>, > pattern=<optimized out>) at mm/memtest.c:49 > #1 do_one_pass (end=<optimized out>, start=<optimized out>, > pattern=<optimized out>) at mm/memtest.c:78 > #2 early_memtest (/build/gdb-OxeNvS/gdb-9.2/gdb/inline-frame.c:155: > internal-error: void inline_frame_this_id(frame_info*, void**, frame_id*): > Assertion `frame_id_p (*this_id)' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > > This is a bug, please report it. For instructions, see: > <http://www.gnu.org/software/gdb/bugs/>. > > Aborted (core dumped) Can you please try master + this patch? It sounds related. https://sourceware.org/pipermail/gdb-patches/2021-August/181385.html It might be a bit easier to grab the patch from here: https://pi.simark.ca/gdb-patches/20210809154122.3468792-1-andrew.burgess@embecosm.com/