Programmed SIGTRAP, Trace / trappoint trap

I am debugging a piece of (embedded) software. I set a breakpoint on the function, and for some reason, as soon as I reach this breakpoint, and continue , I always return to the function (which is the initialization function, which should be called only once). When I remove the breakpoint and continue , GDB tells me:

Program received signal SIGTRAP, Trace/breakpoint trap.

Since I worked with breakpoints, I assume that I fell into the "interrupt trap". What is a breakpoint trap?

+13
c arm embedded gdb
source share
4 answers

A breakpoint trap means the processor has hit a breakpoint. There are two possibilities why this happens. Most likely, your initialization code gets caught, because your CPU reboots again and hits the breakpoint again. Another possibility is that the code in which you set the breakpoint is actually executed in places other than initialization. Sometimes with aggressive compiler optimizations, it can be difficult to pinpoint exactly which code your breakpoint belongs to, and which execution paths can get there.

+8
source share

Another opportunity I can think of is:

1. Your process runs more than one thread .

For eg - 2 they say x and y.

2. The y thread hits the breakpoint , but you have gdb attached to thread x.

This case is a Trace / breakpoint trap.

+7
source share

I had a problem running linux project in Visual Studio 2015 and remote debugging. My solution is project_properties -> Configuration Properties -> Debugging -> Debug Mode and changing the value from "gdbserver" to "gdb"

+1
source share

If you use V BAT as a backup power source and your backup voltage is below 1.65 V, you get the same problem after connecting to a power source.

In this case, you need to disconnect all power sources and reconnect with the correct voltage level. Then the debugging problem goes away.

-3
source share

All Articles