'cwd' option is not respected in launch.json

[andreasjhkarlsson]

Bug type: General

• OS and Version: macOS 11.2.3
• VS Code Version: 1.59.1
• C/C++ Extension Version: 1.6.0

After updating to 1.6.0 of this extension the cwd option stopped working for all of my launch.json configs. Example config:

        {
            "name": "TEST",
            "request": "launch",
            "type": "cppdbg",
            "program": "/tmp/a.out",
            "args": [""],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}/components/Media/",
            "environment": [
                //{"name": "ASAN_OPTIONS", "value": "detect_container_overflow=0"} // Uncomment when using address sanitizier
            ], 
            "externalConsole": false,
            "MIMode": "lldb"
        },  

To verify I created a test program like:

#include <unistd.h>
#include <iostream>

int main()
{
char a[2048];
getcwd(a, 2048);
std::cout << a << std::endl;
}

which on 1.6.0 prints the incorrect "/private/tmp" when launching through vscode. If I manually downgrade to 1.5.1 I get the expected output (the actual cwd specified in the launch.json file).

[mikebeaton]

I can confirm that this is specific to cppdbg 1.6.0 - i.e. does not happen with cppdbg [1.4.1-1.5.1] - but that it is not specific to VS Code 1.59.1 - i.e. same problem happens, with cppdbg 1.6.0 only, with vscode (1.57.1-1.58.2].

-exec shell pwd at the vscode Debug Console also shows the same problem, current directory is the location of the program file, not the location specified in cwd.

(Not sure if it is relevant or not, but I am also on macOS, 11.5.)

[elahehrashedi]

quoting from here: microsoft/vscode#27157
"cwd is nothing that VS Code knows about. A debug extension owns the schema for its launch attributes and only some define cwd (and VS Code cannot make any assumptions about the semantics of cwd anyway; it can only guess..."

[mikebeaton]

@elahehrashedi - Thanks for the additional info - so it's a good thing that this issue is on the repository of the cppdbg extension and not of VS Code then, right?

[ennorehling]

It seems that this is still an issue in version 1.8.5 (pre-release). Is there any workaround for this? I just want the debug configuration to launch the program with a current working directory of {$workspaceFolder}, but it seems to always start from the CMake build directory :-(

[mikebeaton]

@WardenGnaw / anyone else?

@elahehrashedi's comment seems to imply that the issue is in the right place.

The behaviour changed between 1.5.1 and 1.6.0; from @ennorehling's comment, it still seems be an issue in 1.8.5; and it seems to be a genuine issue, affecting some people's ability to use the tool effectively.

[arsdever]

I'm facing a similar issue on VS too. I hate cwd set in the launch.vs.json file, but the debugger won't start in that directory. Using msvc_x64_x64 compiler in the CMakeSettings and the default debugger the VS provides.

[b-reich]

Have the same Issue with python and linux.
I think its a vscode problem not a plugin one.

[clumdee]

Same for me. Have the same Issue with python.

[Colengms]

My understanding is that the cwd value is passed along to the debugger, and there is a known issue with lldb-mi (needed to debug with clang+lldb) not propagating the cwd value from its -environment-cd argument to the process being debugged. llvm/llvm-project#29613

[mikebeaton]

@Colengms - That proposed source of the problem doesn't fit with the issue depending on the version of VS Code.

[Colengms]

Hi @mikebeaton . Some code was changed between these versions such that the issue with lldb-mi was exposed. We can use this issue to track implementing a work around, but the ideal fix would come from lldb-mi.

[Bonkt]

Might not be relevant to finding the source of the problem but I thought i would mention that i have similar issues on Ubuntu when running a gdb debug launch

[blindb]

I found that when pressing "debug" button on toolbar, right side of screen, it does not respect launch.js
However F5 and play button on left side in "run and debug" sidebar, in front of configuration drop-down work as expected.

version 1.70.1 on win10

[Uncle-Yuanl]

I found that when pressing "debug" button on toolbar, right side of screen, it does not respect launch.js However F5 and play button on left side in "run and debug" sidebar, in front of configuration drop-down work as expected.

version 1.70.1 on win10

CORRECT！！！！！！！Thank you very much
And the reason follows(please search the url):
https://stackoverflow.com/questions/72037468/different-behavior-when-using-debug-run-button-and-f5-ctrlf5-in-visual-studio-c

[JayAtlis]

This one is hitting me, too. Visual Studio 2022 with latest updated workloads for C/C++ and CMake.
The workaround doesn't work for me either - pressing F5 just launches in debug and "cwd" is still ignored.

Is there any solution?

[tasansal]

We are having the same issue with the Python (3.10) debugger. The cwd key is not respected.

[francescotaioli]

Having the same issue debugging a C++ application. Cwd is completely ignored

[i5hi]

Same issue debugging a rust app with lldb.

[MovingKyu]

in my case, putting"cwd" option in the launch.json does not start debugging at all! when I remove the "cwd" option, then it starts debugging. this is weird. I am using Python debugger

[b-y-f]

I found that when pressing "debug" button on toolbar, right side of screen, it does not respect launch.js However F5 and play button on left side in "run and debug" sidebar, in front of configuration drop-down work as expected.

version 1.70.1 on win10

Same issue
WHy?

[MikeErd]

Just to keep question alive, I can confirm the mentioned behavior by "b-y-f". Starting debug from drop-down-arrow (top right of Studio Code in the tool bar) ignores at least cwd setting in launch.js. Using F5 to start debug session respects the settings in launch.json and therefore work as expected.
At least from my side this behaviour is not expected.

[sean-mcmanus]

@elahehrashedi Is this a build task issue?

[elahehrashedi]

@sean-mcmanus I tested this, and I beleive this is not a task issue.
I don't repro this using "cppvsdbg" or "cppdbg" with "MIMode": "lldb" or "MIMode": "gdb".
We need more info to investigate this issue.

[a-gn]

This is also happening to me in Visual Studio 2022 17.5.1, debugging a CMake target. All programs start in my home folder.

[mikebeaton]

@sean-mcmanus I tested this, and I beleive this is not a task issue. I don't repro this using "cppvsdbg" or "cppdbg" with "MIMode": "lldb" or "MIMode": "gdb". We need more info to investigate this issue.

@elahehrashedi @sean-mcmanus What more info do you need? I am happy to re-check and re-test and gather any info, if it will help.

[sean-mcmanus]

@mikebeaton I don't know. I don't repro the issue. @WardenGnaw Do you have any idea? I'm guessing this is a debugger issue?

[dangffn]

I was having this issue, and noticed there was a cd statement in my .bashrc
After removing that, the debugger worked with the cwd option (VS Code 1.76.0)

[pochtar]

Latest macos, latest vscode. Can confirm: cwd is not respected when clicking on the top-right debug button but it does work when you click debug on the left panel.
Interestingly, both work fine on ubuntu.

[TheBeardedQuack]

Issue seems to be present for rust debugging via lldb, whether activated via F5, or the debug play button.

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "lldb",
            "request": "launch",
            "name": "Debug unit tests in example 'hot_reload'",
            "cargo": {
                "args": [
                    "test",
                    "--no-run",
                    "--example=theme",
                    "--package=tomt_bevycss"
                ],
                "filter": {
                    "name": "theme",
                    "kind": "example"
                }
            },
            "args": [],
            "cwd": "${workspaceFolder}"
        },
    ]
}

Application output snippet:

2023-04-06T19:01:03.523749Z  WARN bevy_asset::asset_server: encountered an error while reading an asset: path not found: /<my-local-drive>/tomt-bevycss/target/debug/examples/assets/sheets/dark_theme.css

Where
${workspaceFolder} = /<my-local-drive>/tomt-bevycss

VSCode: 1.77.1
CodeLLDB: v1.9.0
rust-analyzer: v0.3.1463
C/C++: v1.14.5

System Info
Ubuntu 22.04.2 LTS (Jammy JellyFish)
Kernel 5.15.0-69-generic

Any more details I can provide please let me know.

[willjhenry]

I noticed that it does not work, even when using from the debug panel (top left button) if the "Python Debug Console" is not already open. Once the "Python Debug Console" is open, it will work (if you hit the debug button again).

[willjhenry]

I should add that, in my configuration, I have "console" set to "integratedTerminal"

[KubaO]

Still happens on Visual Studio 2022 17.6.4 :(

This is such a basic feature and it doesn't work ... why?!

[sean-mcmanus]

@KubaO This issue is about the VS Code C++ extension and not Visual Studio 2022. Did you mention the wrong product by mistake?

[KubaO]

Same issue exists in both. Perhaps some code is shared?

[sean-mcmanus]

@KubaO Okay, sounds like it could be some shared debugger code.

[nobane]

Issue seems to be present for rust debugging via lldb, whether activated via F5, or the debug play button.

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "lldb",
            "request": "launch",
            "name": "Debug unit tests in example 'hot_reload'",
            "cargo": {
                "args": [
                    "test",
                    "--no-run",
                    "--example=theme",
                    "--package=tomt_bevycss"
                ],
                "filter": {
                    "name": "theme",
                    "kind": "example"
                }
            },
            "args": [],
            "cwd": "${workspaceFolder}"
        },
    ]
}

Application output snippet:

2023-04-06T19:01:03.523749Z  WARN bevy_asset::asset_server: encountered an error while reading an asset: path not found: /<my-local-drive>/tomt-bevycss/target/debug/examples/assets/sheets/dark_theme.css

Where ${workspaceFolder} = /<my-local-drive>/tomt-bevycss

VSCode: 1.77.1 CodeLLDB: v1.9.0 rust-analyzer: v0.3.1463 C/C++: v1.14.5

System Info Ubuntu 22.04.2 LTS (Jammy JellyFish) Kernel 5.15.0-69-generic

Any more details I can provide please let me know.

I also ran into this issue trying launch cargo to debug rust with lldb, seemingly because Cargo.toml is not in the root of my workspace.

I was able to get the debugger to launch by specifying the Cargo.toml file via --manifest-path:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "lldb",
            "request": "launch",
            "name": "Debug executable 'server'",
            "cargo": {
                "args": [
                    "build",
                    "--manifest-path", "${workspaceFolder}/backend/Cargo.toml",
                    "--bin=server",
                ],
                "filter": {
                    "name": "server",
                    "kind": "bin"
                }
            },
            "args": [],
            "cwd": "${workspaceFolder}/backend"
        },
    ]
}

[dzid26]

For me it doesn't work with play button or F5 !

Setting "setupCommands": [{"text": "cd"}] reveals that cwd points to home directory:

1: (636) <-1003-interpreter-exec console "cd"
1: (650) ->~"Working directory C:\\Users\\dzidm.\n"

This sucks because then there is another issue with ${workspaceRoot} escape characters when trying to pass to miDebuggerArgs.
So the another workaround was to create user variable in setting.json (e.g. "myWorkspaceFolder": "C:/Repo") and then reference it in launch.json, e.g:
"miDebuggerArgs": "-cd ${config:myWorkspaceFolder} bin/main", // ! due to issues with ${workspaceRoot}, you need to create "myWorkspaceFolder": "path" in .vscode/setting.json

[totszwai]

Latest macos, latest vscode. Can confirm: cwd is not respected when clicking on the top-right debug button but it does work when you click debug on the left panel. Interestingly, both work fine on ubuntu.

Which "left panel" are you referring to? It doesn't work for me, none of the VS code ever worked. Is there a workaround for this? Shouldn't Microsoft prioritize this? I mean debugging is one of the most important things in programming and this bug has been open since 2021...

[EmirVildanov]

@KubaO thanks for your advise! It worked for me.