gdb needs to be manually killed after end of debug session

[keton]

Setup

Most recent stable VSCode version debugging ARM Cortex M4 code using arm-none-eabi-gdb connected to JLinkGDBServer as gdbserver

Affected OS

MacOS (tested on ElCapitan, Sierra, High Sierra), Linux (tested on Ubuntu 16.10 and 17.04)

Windows (tested on Windows 10) is unaffected by this issue

What's wrong

First debug session goes fine. After disconnecting from debug or restarting no more debug sessions are possible. In case of restart debug session ends but the new one is not started. Also breakpoints on Linux and MacOS are broken, code execution stops at main but that's it.

Manual debug session ran from terminal works as expected so it's most likely VSCode related issue.

Workaround

arm-none-eabi-gdb process must be manually killed from terminal after each debug session. Alternatively on Linux unnamed empty window that pops under VSCode window may be closed. This allows next debug session to proceed but must be repeated every time.

[pieandcakes]

@keton Can you enable "logging": {"engineLogging": true} in your launch.json and see if gdb is exiting correctly? This might be an issue with arm-non-eabi-gdb or JLinkGDBServer not shutting down. you can also enable "trace":true and "traceResponse": true in the logging block to get more information too. If you don't feel comfortable posting it here, please email it to me with the GitHub issue number and I'll take a look at it.

[keton]

Attached please find trace files. In both one of last lines says 'pause' when I tried to cause a non conditional break-point but it didn't work. Also when it says disconnect it didn't work and I had to manually close "DebuggerTerminal" window on Linux and kill arm-none-eabi-gdb on MacOS.

JLinkGDBServer is launched with -singlerun option which means that it terminates as soon as gdb disconnects from it. It works outside of VSCode and when gdb is manually killed.

linux_trace.txt macos_trace.txt

[pieandcakes]

@keton Can you try and issue '-exec -gdb-set async off' in the debugConsole when you hit your first breakpoint and then start running again and try and pause? I've seen other issues of cross-compiled arm gdb that doesn't seem to be happy about async being on.

[keton]

It has no effect on both Mac and Linux

[resk8]

any updates?

[pieandcakes]

@resk8 I don't have a JLink device and I need additional information to know what the issue is.

[EmbeddedRepublic]

Hi. Do you have a fix for that ?

[EmbeddedRepublic]

Workaround for Windows OS: In your terminal, a tasklist command will reveal that openocd is still running.

In your launch.json, create a postDebugTask that will be called to kill openocd:

launch.json

"configurations": [
      {
        "cwd": "${workspaceFolder}",
        "executable": "./build/Test_LenseDrive.elf",
        "name": "Debug STM32F103 openOCD",
        "request": "launch",
        "type": "cortex-debug",
        "servertype": "openocd",
        "runToEntryPoint": "main",
        "showDevDebugOutput": "raw",
        "gdbTarget": "localhost:3333",
        "gdbPath": "arm-none-eabi-gdb",
        "configFiles": [
          "openocd_configs/stlink.cfg",
          "openocd_configs/stm32l4x.cfg"

        ],
        "postDebugTask": "kill-gdb-server",
        "logging": {"engineLogging": true}
      }
      

Tasks.json

  `{
"version": "2.0.0",
"tasks": [
    {
        "label": "kill-gdb-server",
        "type": "shell",
        "command": "taskkill /IM openocd.exe /F",
        "presentation": {
            "echo": true,
            "reveal": "always",
            "focus": false,
            "panel": "shared",
            "showReuseMessage": true,
            "clear": false
        },
        "problemMatcher": []
    }
    
]

} `

Conclusion: The problem originates from the server side. The gdb client (arm-none-eabi-gdb) is not at fault. You can verify this by using Get-Process arm-none-eabi-gdb on Windows or ps aux | grep arm-none-eabi-gdb on Linux. You will see that it is not active (not running).