Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When DWT is enabled, Orbetto's px4_trace_swo_stm32h7 GDB command results in a SIGTRAP signal and a segmentation fault. #13

Open
fault2000 opened this issue Dec 5, 2024 · 1 comment

Comments

@fault2000
Copy link

fault2000 commented Dec 5, 2024

'm currently trying to implement a function that sends an ITM signal when a DWT trigger occurs, so developers can detect DWT events in Perfetto. However, when I enable DWT in PX4—whether using emdbg's inline pwatch function or a custom program to enable DWT—executing the px4_trace_swo_stm32h7 command to generate trace.swo causes a crash.

I checked if DWT is not enabled, it works fine. The same occurred in the opposite case as well.

Do you have any insights or suggestions on what might be causing this issue?

The detailed error is as follows:

(gdb) px4_trace_swo_stm32h7
Resets core & peripherals using RESET pin.
Temporary breakpoint 1 at 0x8023a0c: file **/platforms/nuttx/NuttX/nuttx/sched/init/nx_start.c, line 340.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x08002dd8 in ?? ()


Fatal signal: Segmentation fault
----- Backtrace -----
0x5b4e82a86891 ???
0x5b4e82b6df09 ???
0x5b4e82b6e05c ???
0x7f5e8ea4251f ???
	./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x5b4e82db4a50 ???
0x5b4e82db9818 ???
0x5b4e82b03a9d ???
0x5b4e82b04127 ???
0x5b4e82b04584 ???
0x5b4e82b058fc ???
0x5b4e82cd0aa1 ???
0x5b4e82cd4da9 ???
0x5b4e82cd4eba ???
0x5b4e82bba7c5 ???
0x5b4e82d4cf81 ???
0x5b4e82bbc71e ???
0x5b4e82bc920b ???
0x5b4e82cb82ed ???
0x5b4e82e29c55 ???
0x5b4e82e2a1f2 ???
0x5b4e82d2f673 ???
0x5b4e82d2fe7a ???
0x5b4e82ac1c62 ???
0x5b4e82ac2051 ???
0x5b4e82ac24ec ???
0x5b4e82d2fcdc ???
0x5b4e82b6ec3c ???
0x5b4e82b6ef59 ???
0x5b4e82b6f50c ???
0x5b4e82da4f6f ???
0x5b4e82b6f63d ???
0x5b4e82b6f7bf ???
0x5b4e82b6dd8f ???
0x5b4e82e29c55 ???
0x5b4e82e2a1f2 ???
0x5b4e82befa74 ???
0x5b4e82bf3434 ???
0x5b4e829f5db9 ???
0x7f5e8ea29d8f __libc_start_call_main
	../sysdeps/nptl/libc_start_call_main.h:58
0x7f5e8ea29e3f __libc_start_main_impl
	../csu/libc-start.c:392
0x5b4e829fb749 ???
0xffffffffffffffff ???
---------------------
A fatal error internal to GDB has been detected, further
debugging is not possible.  GDB will now terminate.

This is a bug, please report it.  For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.

Segmentation fault (core dumped)
@niklaut
Copy link
Collaborator

niklaut commented Dec 5, 2024

Hm, I've also experienced various segfaults in GDB. I haven't found any solution for this yet.
Here's a similar segfault when starting the debug session. Just halting the CPU at a random location can trigger this.

Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 8000 kHz
Reading symbols from /PX4_firmware_private/build/px4_fmu-v5x_default/px4_fmu-v5x_default.elf...
Remote debugging using :3333
0x08184b12 in uORB::DeviceNode::copy (generation=@0x20010d1c: 238718, dst=0x20012890, this=0x2000f950) at /PX4_firmware_private/platforms/common/uORB/uORBDeviceNode.hpp:256
256					if (!is_in_range(current_generation - _queue_size, generation, current_generation - 1)) {
Fatal signal: Segmentation fault
----- Backtrace -----
0x55c21e19b891 ???
0x55c21e282f09 ???
0x55c21e28305c ???
0x7f857984251f ???
	./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x55c21e4c9a50 ???
0x55c21e4ce818 ???
0x55c21e218a9d ???
0x55c21e219127 ???
0x55c21e219584 ???
0x55c21e21a8fc ???
0x55c21e3e5aa1 ???
0x55c21e3e94f4 ???
0x55c21e3e9eba ???
0x55c21e2cf7c5 ???
0x55c21e461f81 ???
0x55c21e2d171e ???
0x55c21e3bdc97 ???
0x55c21e3be2d7 ???
0x55c21e43a130 ???
0x55c21e1cc034 ???
0x55c21e444ed3 ???
0x55c21e302c01 ???
0x55c21e302cd1 ???
0x55c21e3079ec ???
0x55c21e30842a ???
0x55c21e10adb9 ???
0x7f8579829d8f __libc_start_call_main
	../sysdeps/nptl/libc_start_call_main.h:58
0x7f8579829e3f __libc_start_main_impl
	../csu/libc-start.c:392
0x55c21e110749 ???
0xffffffffffffffff ???
---------------------
A fatal error internal to GDB has been detected, further
debugging is not possible.  GDB will now terminate.
This is a bug, please report it.  For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.
Segmentation fault (core dumped)

I think (but not certain) that GDB is crashing on type info lookup, since it depends on the breakpoint location. If you set the breakpoint a little later in the function it might work again. I've also tried different GDB versions (10,11,12,13) and every one of them has this type lookup bug.

I don't know how to fix this, it's not a bug in this repo, it's something deep in GDB and I haven't figured out how to debug that yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants