GDB Breakpoints are set in all files with same name

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.

Pierson Lee (@pieandcakes)

Pierson Lee (@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.

Tobias Loose (@ZobyTwo)

Tobias Loose (@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.

Pierson Lee (@pieandcakes)

Pierson Lee (@pieandcakes) I see, thanks for the explanation.

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.

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.

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

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?

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,
    }
  ]
}

pascal (@psclkhoury)

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

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.

pascal (@psclkhoury)

pascal (@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

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

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

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!

Andrew Wang (@WardenGnaw)

Andrew Wang (@WardenGnaw) Pierson Lee (@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.

Andrew Wang (@WardenGnaw)

Andrew Wang (@WardenGnaw) Pierson Lee (@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.

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.

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

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.

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.

#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?

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

Are there any better solutions available here when a bigger project with mixed languages is in play.

Specifically - I have a larger C++ project that is gradually "oxidising" into Rust. As the C++ side is still the majority of the program, the C++ extension is enabled. The rust-analyzer extension inserts CodeLens debugging invocation points above tests - and you hit this issue massively when every other file is named mod.rs

CodeLens doesn't seem to be massively parameterisable, nor does launch.json seem to apply to anything CodeLens creates - I believe the only way to do this correctly would be if this behaviour was working as the majority of people in this thread expect.

It's worth mentioning that specifically trying to invoke the debugger when you don't have the C++ extension installed prompts you with

Install CodeLLDB, lldb-dap, C/C++ or Native Debug for debugging.

Why the solution is so badly described?

Edit launch.json
Add the following entry

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

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
            }
        }
    ]
}

For anyone that are using cppvsdbg as debugger and having this issue. Please switch to gdb and change the configuration like this. It worked for me.

Navigation Menu

Repository navigation

GDB Breakpoints are set in all files with same name #977

Environment

Reproduce

Settings

20 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

GDB Breakpoints are set in all files with same name #977

Description

Environment

Reproduce

Settings

Activity

ZobyTwo commented on Aug 18, 2017

pieandcakes commented on Aug 18, 2017

ZobyTwo commented on Aug 19, 2017

tobiaskohlbau commented on Aug 28, 2017

mpups commented on Jun 20, 2018

Ju57iCe commented on Oct 12, 2018

rsbondi commented on Mar 19, 2019

psclkhoury commented on Apr 10, 2019

pieandcakes commented on May 29, 2019

Yuri6037 commented on Mar 20, 2020

20 remaining items

WardenGnaw commented on Mar 18, 2022

pierrebai-adsk commented on Mar 23, 2022

davidstone commented on Mar 3, 2023

pierrebai-adsk commented on Mar 3, 2023

psclkhoury commented on Mar 4, 2023

rongzha1 commented on Mar 15, 2023

nussjo commented on Oct 26, 2023

coldav commented on Nov 7, 2023

eii-zhangsong commented on Nov 13, 2023

coldav commented on Nov 13, 2023

tok101 commented on Aug 6, 2024

Turtwiggy commented on Sep 18, 2024

AndrewLipscomb commented on Oct 15, 2025

0xborisgregor commented on Aug 18, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions