36

I'm debugging a piece of (embedded) software. I've set a breakpoint on a function, and for some reason, once I've reached that breakpoint and continue I always come back to the function (which is an initialisation function which should only be called once). When I remove the breakpoint, and continue, GDB tells me:

Program received signal SIGTRAP, Trace/breakpoint trap.

Since I was working with breakpoints, I'm assuming I fell in a "breakpoint trap". What is a breakpoint trap?

Shiplu Mokaddim
  • 56,364
  • 17
  • 141
  • 187
Randomblue
  • 112,777
  • 145
  • 353
  • 547
  • This is also the type of question you can post on the [electronics SE](http://electronics.stackexchange.com). – Kortuk Mar 21 '12 at 17:53
  • 2
    @Kortuk In what way this GDB Qn related to electronics? :-o – Pavan Manjunath Mar 21 '12 at 18:17
  • Type `info breakpoints` and make sure all breakpoints are deleted. – Pavan Manjunath Mar 21 '12 at 18:27
  • @PavanManjunath, the embedded got me, and when I dont know a program like GDB, I dont spend too much time worrying about the product, I just watch anything tagged embedded and drop comments occasionally, we do support embedded work. We are probably primarily embedded system developers, although many like myself mean lower end microcontrollers. This is a question that fits on either site, but SO has many more people browsing it, so some advantage to posting here. Electronics is the Electrical Engineering site, used to be Electronics Design, but trademark issues. – Kortuk Mar 21 '12 at 18:27
  • Related http://www.kerneltrap.org/mailarchive/linux-kernel/2008/3/17/1184274 and http://stackoverflow.com/questions/1621059/breakpoints-out-of-nowhere-when-debgging-with-gdb-inside-ntdll – Pavan Manjunath Mar 21 '12 at 18:42
  • See my answer here: https://stackoverflow.com/a/44707500/6362941 (search for "The following helped me:"). – Robin Kuzmin Jun 22 '17 at 19:12

5 Answers5

23

The other possibility i can think of is:

1.Your process is running more than one thread.

For eg - 2 say x & y.

2.Thread y hits the break point but you have attached gdb to thread x.

This case is a Trace/breakpoint trap.

b1tchacked
  • 468
  • 4
  • 12
23

Breakpoint trap just means the processor has hit a breakpoint. There are two possibilities for why this is happening. Most likely, your initialization code is being hit because your CPU is resetting and hitting the breakpoint again. The other possibility would be that the code where you set the breakpoint is actually run in places other than initialization. Sometimes with aggressive compiler optimization it can be hard to tell exactly which code your breakpoint maps to and which execution paths can get there.

TJD
  • 11,800
  • 1
  • 26
  • 34
  • If the CPU resets, would GDB be still alive and attached to the user's executable? – Pavan Manjunath Mar 21 '12 at 18:19
  • 1
    @PavanManjunath, yes it's possible for CPU to reset and then hit the breakpoint without disturbing the GDB session. – TJD Mar 21 '12 at 19:16
  • In some systems, the execution stops at the entry point instead of going directly to main when a debug session is started. So if you see this it may mean that your system crashed and it went to the code entry point. – m4l490n Oct 27 '20 at 16:24
1

I got this problem running linux project in Visual studio 2015 and debugging remotely. My solution is project_properties -> Configuration properties -> Debugging -> Debugging mode and change the value from "gdbserver" to "gdb"

S.Seba
  • 121
  • 1
  • 11
0

If you use V BAT as backup supply and your backup voltage drives lower than 1.65V then you get the same problem after conecting to a power supply.

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

ЯegDwight
  • 24,821
  • 10
  • 45
  • 52
Maik Siebrand
  • 41
  • 3
    This is completely dependant on the microcontroller/microprocessor used. – Dean Mar 16 '13 at 14:07
  • 1
    We have been struggling with this problem for quite a few hours in our BMS with an STM MCU and disconnecting the battery (after reading this answer) solved the problem. :) –  Oct 23 '19 at 09:25
0

I stucked with the same problem and in my case the solution is to decrease SWDs frequency. (I've got soldering staff between mcu and host, not so reliable) I changed 4000k to 100k and problem gone.

Ivan Kryvosheia
  • 183
  • 5