I am trying to debug an iOS app with gdb and when I hit a breakpoint I get this error, and can not continue.
Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to process 190 thread 0x6fa7]
0x000ae150 in dyld_stub_pthread_key_create ()
Does anyone know how I can continue debugging without closing and opening back gdb?
This could happen if your breakpoint address is in the "middle" of the opcode, for example if your asm code looks like this:
0x000C: BLX R3
0x000E: LDR R0, [R6]
and you put breakpoint on address 0x00D, in this case the process will get SIGTRAP on other address than 0x000D, but gdb only knows the 0x00D address from the user input so its just throw SIGTRAP and get stuck.
Also even when you write the right address to gdb, the arm fallback mode of gdb can cause this kind of problems.
set arm fallback-mode (arm|thumb|auto)
GDB uses the symbol table, when available, to determine whether instructions are ARM or Thumb. This command controls GDB’s default behavior when the symbol table is not available. The default is ‘auto’, which causes GDB to use the current execution mode (from the T bit in the CPSR register).
Some times gdb cant get the arm mode of a function automatically, and it falling to the wrong mode. You can check this by disassemble piece of code in gdb and check if you see normal assembly or some bad one. if its bad one then your arm assembly mode is wrong, and you can get false SIGTRAP.
Another advice is not to use gdb in iOS, use lldb. gdb is depreciated, and the only gdb versions available to iOS are ports thats individual people wrote, those ports lack in features (for example some of them don't have the fallback feature at all), and are unreliable.
If the program is legitimately triggering SIGTRAP itself for some odd reason, and relies on that happening, then you can tell gdb to return to the program and execute the program's own SIGTRAP handling by executing:
signal SIGTRAP
This is just like c for continue, except that it continues at the SIGTRAP handler rather than wherever the exception/trap was raised.
In case it is running into this error Received a SIGTRAP: Trace/breakpoint trap even though there are no breakpoints in the program, check the power of Hardware Debugger e.g. J-Link.
In my case, J-Link was powered on but the port wasn't delivering enough power. Changing the port to high-power one fixed this.
