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.