blackmagic-debug / blackmagic

In application debugger for ARM Cortex microcontrollers.
GNU General Public License v3.0
3.25k stars 770 forks source link

Crash in free() after `monitor swdp_scan` #222

Closed alexisvl closed 7 years ago

alexisvl commented 7 years ago

I have a mostly reproducible crash on the BMP running a build of the latest master as of this issue (b10971b), and also on v1.6. This happens with a SAM4S target, when I attempt to reconnect to the target after having already debugged it. It doesn't happen every time, particularly if I don't do much, but it seems like the more debugging I do in the first session, the more likely the second is to crash. I'm including GDB transcripts from both sessions debugging my target, and a backtrace of the BMP using an STlink. The BMP was reset with monitor reset halt via its attached STlink immediately prior to the first transcript.

First gdb session: https://pastebin.com/NsmKauM2 Second gdb session, crash: https://pastebin.com/CwRsnPiv

Backtrace of BMP b10971b:

(gdb) bt
#0  blocking_handler () at ../../cm3/vector.c:99
#1  <signal handler called>
#2  0x0800f140 in _free_r ()
#3  0x0800a438 in target_list_free () at target/target.c:84
#4  0x0800297a in adiv5_swdp_scan () at target/adiv5_swdp.c:49
#5  0x08002b20 in cmd_swdp_scan () at command.c:199
#6  0x08002e48 in command_process (t=0x0, cmd=cmd@entry=0x20004ef8 "swdp_scan") at     command.c:113
#7  0x08004e1c in handle_q_packet (len=<optimized out>, packet=0x20000ab4 <pbuf>     "qRcmd,737764705f7363616e") at gdb_main.c:334
#8  0x080050ba in gdb_main_loop (tc=tc@entry=0x20000000 <gdb_controller>,     in_syscall=in_syscall@entry=false) at gdb_main.c:275
#9  0x08005514 in gdb_main () at gdb_main.c:483
#10 0x08006e78 in main (argc=<optimized out>, argv=<optimized out>) at main.c:47

Registers at the time of crash:

(gdb) i reg
r0             0x60f771c    101676828
r1             0x200004a0   536872096
r2             0x20002000   536879104
r3             0x5a0    1440
r4             0x20001a60   536877664
r5             0x260f971c   638555932
r6             0x80000000   -2147483648
r7             0x5a1    1441
r8             0x20000078   536871032
r9             0x20004ef8   536891128
r10            0x9  9
r11            0x40010c14   1073810452
r12            0x20004e48   536890952
sp             0x20004df0   0x20004df0
lr             0xfffffff9   -7
pc             0x800c7cc    0x800c7cc <blocking_handler>
xPSR           0x1000003    16777219
gsmcmullin commented 7 years ago

The failure here is in freeing the breakpoint list. This may be a result of this issue #218 in removing breakpoints from the list.

alexisvl commented 7 years ago

Looks like #218 fixes it. :+1: