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.

Beginne damit, die Stop-Sequenz mit einem J-Link GDB Server und einem Remote-Target zu reproduzieren, und untersuche anschließend die engineLogging-Ausgabe, die gdb-exit anzeigt, während das Target läuft. Fertig ist die Arbeit, wenn das Stoppen einer laufenden Sitzung eine Bereinigung durchführt, sodass eine nachfolgende Sitzung keine doppelten Breakpoints meldet; verifiziere das Verhalten, indem du die aufgeführten Schritte wiederholst.