microsoft / microsoft/vscode-cpptools

GDB remote breakpoint not behaving as expected since 0.18.0

Open
#2,538 2 comments 0 reactions 1 assignee View on GitHub

@WardenGnaw is already working on this.

Since Sep 24, 2018.

debugger
Dominant language
TypeScript
Stars
6.2k
Forks
1.7k
Avg merge
14h 46m
Merged PRs (30d)
61

Description

Type: Debugger

Describe the bug

  • OS and Version: Debian 8.10 (in a Docker container)
  • VS Code Version: 1.24.1
  • C/C++ Extension Version: 0.18.0

After updating to the latest extension I am unable to use the debugger. The breakpoint is hit; but the UI doesn't do anything. "Continue" has no effect. Can "stop" debugging.

If I set stopAtEntry to false. App runs but "Pause" has no effect.

To Reproduce
Steps to reproduce the behavior:

  1. Build and deploy application.
  2. Start gdbserver on remote host.
  3. Start Debugging.

Additional context
The debugee is an embedded arm device running Debian Wheezy and "GNU gdbserver (GDB) 7.4.1-debian".

The cross-compiler and gdb is also "old".

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceRoot}/app",
            "miDebuggerServerAddress": "device:9091",
            "args": [],
            "stopAtEntry": true,
            "cwd": "${workspaceRoot}",
            "environment": [],
            "externalConsole": true,
            "linux": {
                "MiMode": "gdb",
                "miDebuggerPath": "/opt/arm-fsl-linux-gnueabi/bin/arm-fsl-linux-gnueabi-gdb"
                "logging": {
                    "engineLogging": true
                }
            }
        }
    ]
}

If I revert to any previous 0.17.x version of the extension breakpoints work.

My initial pass over the engine logging the only difference I see, prior to the breakpoint-hit is the addition of -f when setting the breakpoint.

-break-insert -f main

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.