SIGTRAP despite no set breakpoints; hidden hardware breakpoint?

If adding and removing hardware breakpoints does not help, check the interrupt vector.

On Cortex-M microcontrollers all handler entries should have an odd address (ARM Cortex-M FAQ). If they don't, then a UsageFault of type INVSTATE is triggered and the MCU is halted. GDB interprets this as a SIGABRT.

If one of the entries has an even address, then check if the handler function has the .thumb_func and .type directives (NXP Avoid hardfault, HardFault and .thumb_func).

Example for a HardFault_Handler:

.thumb_func
.type HardFault_Handler, %function
HardFault_Handler:
  TST LR, #4
  ITE EQ
  MRSEQ R0, MSP
  MRSNE R0, PSP
  B hard_fault_handler_c

The following helped me:

# Ones I hit the SIGTRAP:
(gdb) f 0  # Show the current stack frame of the current thread.
#0  0x4003ed70 in pthread_create@@GLIBC_2.4 () from /opt/CodeSourcery/arm-2011.09/arm-none-linux-gnueabi/libc/lib/libpthread.so.0

# The fragment of interest is the current address: 0x4003ed70.
# Set the hardware assisted breakpoint at the current address:
(gdb) hbreak *0x4003ed70

# Continue execution (without hitting SIGTRAP):
(gdb) c
# Continuing.

Ok. Long answer: Hardware breakpoints are usually set by writing to some special CPU registers. This is done by gdb. If gdb dies, it can left those installed in CPU. I guess your implementation (of gdb) does not either clear or examine those, when it connects to your target. To locate them, you would need to list the contents of hardware breakpoints registers on your CPU (don't know how to do this on STM32). Workaround would be (informed guess) be this: set few HW breakpoints (typically there are only a few, seldom more than 8) using gdb, then remove all of them. This should overwrite and then clean those hw registers. Once you do set those breakpoints (before removing them), do "continue" (just in case, as gdb sets breakpoints only at that time).

SIGTRAP should be a breakpoint instruction that's being run.

Debug this by inspecting your instruction pointer, it's most likely pointed at an address that contains the BKPT instruction (you'll have to look up what the actual code is).

From there you'll have to work backwards based on the stack and instruction pointer and see if you're where you expect to be. There could be a number of things causing this, from GDB inserting a breakpoint instruction that it failed to clear, to memory corruption.