Breakpoints not cleared when stopping debug using J-Link GDB Server

Type: Debugger

Describe the bug

• OS and Version: Windows 10 1809
• VS Code Version: 1.31.1
• C/C++ Extension Version: 0.21.0
• Other extensions you installed (and if the issue persists after disabling them): None

Using gdb to debug a remote target using the J-Link GDB Server and stopping the debug session while the target is running causes an unclean shut down of the debug session. If a new debug session is then launched to the same J-Link GDB Server you are greeted with a message from the GDB server:

Debugger problem discovered:

The debugger has set two breakpoints at the same address 0xXXXXXXXX.

To Reproduce
J-Link GDB Server requires a remote target to debug so unless you happen to have that reproducing it will prove difficult.

Steps to reproduce the behavior:

1. Start the J-Link GDB Server against a target
2. Start a debug session in VS Code
3. When it hits main() continue execution
4. Stop the debugging session
5. Start a new debug session in VS Code
6. Observe the above message dialog from J-Link GDB Server

Additional context
The problem is in how the session is ended. Using engineLogging the following is observed:

1: (5663) <--exec-continue
1: (5666) ->^running
1: (5666) ->*running,thread-id="all"
1: (5666) ->(gdb)
1: (5666) ->&"\n"
1: (5666) ->^done
1: (5669) ->(gdb)
1: (8088) <--gdb-exit
1: (8093) ->^exit
1: (8093) ->&"Cannot execute this command while the target is running.\n"
1: (8093) ->&"Use the \"interrupt\" command to stop the target\n"
1: (8093) ->&"and then try again.\n"
1: (8093) ->=thread-group-exited,id="i1"
1: (8099) <-logout
1: (8099) "C:/arm/sysroot/bin/arm-none-eabi-gdb.exe" exited with code 0 (0x0).

The J-Link GDB Server does not allow you simply exit while the target is running hence no cleanup is performed. If you were to halt the target before stopping the session there are no issues at all.

Start by reproducing the stop sequence with a J-Link GDB Server and a remote target, then inspect the engineLogging output showing gdb-exit while the target is running. Done means stopping a running session performs cleanup so a subsequent session does not report duplicate breakpoints; verify the behavior by repeating the listed steps.