GDB Breakpoints are set in all files with same name

[ZobyTwo]

When setting a breakpoint in a file with a particular name, breakpoints are set in all files with that file name at the same line.

Environment

Win 10
VSCode 1.15 stable build
C/C++ 0.12.2
No other extension installed.
Gdb 7.6.1 is from mingw32
Gcc 5.3.0 is from mingw32

Reproduce

Create the following project layout:

src
 |- main.c
 |- folder
    |- main.c

That is, there are two main.c files. One directly in src:

int foo();
int main(int argc, char *argv[])
{
    int a = 0;
    a += 3;
    a *= 4;

    foo();

    return 0;
}

The other in src/folder:

int foo()
{
    int b = 14;
    int d = 13;
    b += d - b * d;
    return b + d;
}

In both files, line 5 contains executable code.

Compile from within src:

gcc main.c folder/main.c -g -O0 -o a.exe

Add launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceRoot}/src/a.exe",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceRoot}",
            "environment": [],
            "externalConsole": true,
            "MIMode": "gdb",
            "miDebuggerPath": "C:\\MinGW\\bin\\gdb.exe",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ]
        }
    ]
}

Set breakpoint in src/main.c at line 5. Launch debugger, it breaks in main, hit continue and it will break in foo (which it should not).

The above setup:

Breakpoints.zip

Settings

    "debug.allowBreakpointsEverywhere": true

c_cpp_properties.json is not in use and launch.json is given above.

[ZobyTwo]

@pieandcakes Could you please elaborate on why this is considered a request for a feature?

From my perspective, this looks like a bug, really. I have a project with a few hundred *.c files with the same name (they are mostly generated by another tool) and this makes it very hard to debug them because the debugger breaks at seemingly random places - additional to the line where I did set a breakpoint.

[pieandcakes]

@ZobyTwo When we send the bindings for the breakpoints we are currently only sending the filename. As such, it is "by design" even though it is unintended. There have been changes in MIEngine to allow support of this. I'll mark it as a bug also but either way it will require work on my part to get it to work.

[ZobyTwo]

@pieandcakes I see, thanks for the explanation.

[tobiaskohlbau]

I've the same bug/lack of feature as I use cpptools to debug an ARM Processor with multiple cores. As each core gets it's own main.cpp (entrypoint) vscode breaks on every line. Would be nice if this feature/bug could be implemented/resolved.

[ghost]

Is the bug has been resolved ?

[mpups]

Seems to still be a problem (at least in 8.1-0ubuntu3). I tried to get round this by setting the full path name of the file but GDB doesn't like this either. I guess it is not using realpath internally to disambiguate files.

[Ju57iCe]

Any ETA or roadmap on this? The breakpoint features seem frozen for so long - data breakpoints, log points.

[rsbondi]

When we send the bindings for the breakpoints we are currently only sending the filename

I have a possibly related issue based on the quote, the object file is built with prefix_filename so it is missing the breakpoint in filename.c(red, looks set but not hit), is this a symptom of the same issue? Is there a workaround?

[psclkhoury]

I am having the same issue but with the vs debugger and it's quite annoying.

We have a big repository and some files have the same name but in a different path.

When I put a breakpoint in Folder1/Folder2/Util.cpp, all the Util.cpp will break regardless of their paths. This makes the debugger unusable.

This is my launch.json

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Loader",
      "type": "cppvsdbg",
      "request": "launch",
      "program": "c:/SomeExecutable.exe",
      "stopAtEntry": false,
      "cwd": "${workspaceFolder}",
      "externalConsole": true,
    }
  ]
}

[pieandcakes]

@psclkhoury It is on our list for current work planning.

[ghost]

Any updates on this bug?
Thanks!

[Yuri6037]

Hello, I also have this problem under Ubuntu Server 18.04. I hope this will be fixed very soon as it's getting really annoying...
However I don't get it under Windows MSVC.

[Trass3r]

Also got bitten by this on v1.0.1

[psclkhoury]

3 years later still no fix? @pieandcakes Will you accept a PR for this or is it in the closed source part of the code?

[Trass3r]

I think it's all open source by now.

[WardenGnaw]

You can now specify breakpoints to use full path in v1.1.0 via sourceFileMap.

Example:

"sourceFileMap": {
   "<compiler-path>": {
      "editorPath": "<source-path>",
      "useForBreakpoints": true
   }
}

[psclkhoury]

@WardenGnaw Can you give a better example on how to use this? Do I have to do this for each breakpoint I set or what? What are <compiler-path> and <source-path>?

I don't agree with the solution. By default I should be able to set a breakpoint and the full path should be sent to the debug engine without any extra action.

This seems more like a workaround than a fix.

[WardenGnaw]

<compile-path> is the path that GDB returns when a breakpoint is hit.
<source-path> is the path that you want to see in the editor.

For scenarios where you do not build on a different machine or move the source files before compiling, <compile-path> and <source-path> will be exactly the same.

With the following, all breakpoints (except the first one the debug adapter uses to break at entry) will be fully qualified.
E.g.

"sourceFileMap": {
   "C:\Path\To\Project\Root": {
      "editorPath": "C:\Path\To\Project\Root",
      "useForBreakpoints": true
   }
}

By default I should be able to set a breakpoint and the full path should be sent to the debug engine without any extra action.

We decided not make this a default because there are projects that users have debug bits but do not have the source code. This would cause the breakpoint bind to fail.

Here is the related code in the Debug Adapter:
https://github.com/microsoft/MIEngine/blob/73db59d89b8f0fbfdaa3cee1423e674e092ffc0f/src/MIDebugEngine/Engine.Impl/Breakpoints.cs#L114-L118

[psclkhoury]

@WardenGnaw I tried:

"sourceFileMap": {
     "${workspaceFolder}": {
         "editorPath": "${workspaceFolder}",
         "useForBreakpoints": true
    }
}

And I got an error:

I then tried to put the real path instead of ${workspaceFolder} (so c:/path/to/root) and the breakpoint was set in all files with the same name.

We decided not make this a default because there are projects that users have debug bits but do not have the source code. This would cause the breakpoint bind to fail.

I think most users will never have to deal with that, so it do not understand why the default is chosen according to that very rare scenario.
If someone has debug bits then maybe they can change some setting or add something to the launch.json to make it work, and the normal use cases should work without any user configuration.

[WardenGnaw]

Can you enable logging by adding the following to your launch.json and share the -break-insert logs in Debug Console?

"logging": {
   "engineLogging": true
}

When doing that, you can filter and check to see if MIEngine is telling GDB to bind with the specific path for files under that path.

Here's an example of two files with the same name foo.cpp in associated folders called A/B under the project D:/Projects/cpp

If it only shows something like -break-insert -f filename.cpp:15, then it could not resolve the path you provided in sourceFileMap.

[psclkhoury]

I do not see any logging with break-insert after enabling the engineLogging. I only see this which has the correct path.

[Trass3r]

We decided not make this a default because there are projects that users have debug bits but do not have the source code. This would cause the breakpoint bind to fail.

I can't follow. If you don't have the source code you can't set a breakpoint from the code editor, only manually via the breakpoints view and that user input should be passed on as-is.

Anyway can't the debug adapter decide on its own if a full path is ok, like with File.Exists or whatever?

[psclkhoury]

@WardenGnaw Can we reopen this issue? The solution is not working for me.

[josuegomes]

Why the solution is so badly described?

1. Edit launch.json
2. Add the following entry

           "sourceFileMap": {
                "${workspaceFolder}": {
                    "editorPath": "${workspaceFolder}",
                    "useForBreakpoints": "true"
                }
            }

3. If you want addition logs to confirm the configuration add this entry

            "logging": {
                "engineLogging": true
            }

For reference this is my complete launch.json (sensitive data removed):

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "g++ - Build and debug",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/build/app",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ],
            "preLaunchTask": "make",
            "miDebuggerPath": "/usr/bin/gdb",
            "sourceFileMap": {
                "${workspaceFolder}": {
                    "editorPath": "${workspaceFolder}",
                    "useForBreakpoints": "true"
                }
            },
            "logging": {
                "engineLogging": true
            }
        }
    ]
}

[lp35]

Hi,

Bug has reappeared in the latest releases, as recently reported in #692 and #7913. Could you reopen this ticket?

[amih90]

any updates? still reproducing

[WardenGnaw]

I am unable to reproduce this issue in v1.8.4, as mentioned in #977 (comment), you need the following to enable breakpoints as full paths instead of just filename.

            "sourceFileMap":{
                "${workspaceRoot}": {
                    "editorPath": "${workspaceRoot}",
                    "useForBreakpoints": true
                }
            }

@amih90 Can you share your launch.json if you do have the snippet above?

[psclkhoury]

I am unable to reproduce this issue in v1.8.4, as mentioned in #977 (comment), you need the following to enable breakpoints as full paths instead of just filename.

            "sourceFileMap":{
                "${workspaceRoot}": {
                    "editorPath": "${workspaceRoot}",
                    "useForBreakpoints": true
                }
            }

@amih90 Can you share your launch.json if you do have the snippet above?

@WardenGnaw @sean-mcmanus I tried the suggested solution but it doesn't work for me.
The ${workspaceFolder} is being replaced by the vscode editor path.

I also tried to enter the explicit ${workspaceFolder} (c:/path/to/repo) but also did not work. The breakpoints were still being attached in all files having the same name.

I still don't understand why this is not fixed on the extension side by sending the full path to the debugger, instead of on the user side with us having to fiddle with our launch.json. It would be a much better and more robust solution.
Can someone please clarify why?

This is the breakpoint I set:

It got transformed to that after I started debugging:

And of course the file was not found.

This is my launch.json:

"configurations": [
    {
      "name": "Start App",
      "type": "cppvsdbg",
      "request": "launch",
      "cwd": "some/dir",
      "program": "my/executable.exe",
      "stopAtEntry": false,
      "console": "newExternalWindow",
      "requireExactSource": true,
      "sourceFileMap": {
        "${workspaceRoot}": {
          "editorPath": "${workspaceRoot}",
          "useForBreakpoints": true
        }
      }
    },
]

[WardenGnaw]

@psclkhoury I apologize since I did not read your initial message at #977 (comment) but only read your message starting at #977 (comment). I assumed that your issue was specifically for GDB not the vsdebugger.

I have re-opened this issue for cppvdbg at #9054

[pierrebai-adsk]

I'm getting the same problems with the latest VSCode and native Windows debugger.

[davidstone]

It seems pretty strange that I can use the VS Code UI to set a breakpoint by clicking on a line number in a specific file and that has the effect of setting a breakpoint in a different file by default. I feel like a better experience would not require a multi-line json configuration to do the thing that 100% of users using this interface are trying to do. It also looks like I need to modify the setting of every configuration I have in my launch.json

[pierrebai-adsk]

We have multiple projects, multiple libraries in multiple file repos. Having to list every single one in every entries in the launch.json is super-cumbersome. No single other IDE, development tools require such contortions just to properly set a breakpoint. As pointed out by someone else, the explanation why this is not the default behaviour makes no sense: if they don't have the source code, then they surely are not creating breakpoints in the editor!

[psclkhoury]

@WardenGnaw @pieandcakes can you guys at least respond and clarify why you don't want to fix it?
This issue is more than 6 years old and has been reported so many times already.
If you use the extension yourselves for any meaningful c++ work you would know how annoying it is, and you probably would have fixed it already.

[rongzha1]

@WardenGnaw @pieandcakes can you guys at least respond and clarify why you don't want to fix it? This issue is more than 6 years old and has been reported so many times already. If you use the extension yourselves for any meaningful c++ work you would know how annoying it is, and you probably would have fixed it already.

totally agree. Hope to fix it , not a work around.

[nussjo]

still experiencing the issue. Makes debugging virtually impossible because the breakpoint in the other file with the same name is hit periodically and roughly 1000 times more often. How such a behavior that is obviously a bug can exist for over 6 years and not be fixed is a mystery to me.

[coldav]

I agree, this reduces the effectiveness of an otherwise really good system - although the workaround is helpful.

[eii-zhangsong]

I am also getting this problem these days. It really took me some time to find out it's a bug from the editor. Hope it could be fixed to save time of other developers. Thank you.

[coldav]

I am also getting this problem these days. It really took me some time to find out it's a bug from the editor. Hope it could be fixed to save time of other developers. Thank you.

The SourceFileMap workaround does work though, so i'd recommend adding this to your config.

[tok101]

#977 (comment)

This method is OK for a workspace with only one directory, but not for a workspace with multiple directories. For a workspace with multiple directories, this error will be reported:

Variable ${workspaceFolder} can not be resolved in a multi folderworkspace.Scope this variable using ":" and a workspace folder name.

I tried my best to follow the instructions and make the changes, but it didn't work.
Is there any way to solve this?

[Turtwiggy]

If I use an alternative to launch.json e.g. vscode-cmake-tool , is my debugger forever broken on files named the same thing? Pls no