Debugger fails to start when environment variables contain newlines

[bspeice]

Checklist

• The issue is about this extension and NOT about a fork.
• Check the known issues list.
• The latest version of the extension was used.
• It is not related to remote-vscode or I checked the following issue
• Imagine yourself into my position and think how hard to debug the issue without insufficient information.
  I understand that you have privacy concerns and I expect you to understand that this extension is developed for free.
  Thanks.

Describe the bug

Please see also microsoft/vscode-cmake-tools#2686

Environment variables with newlines in them cause problems for the Microsoft GDB adapter (screenshot attached, please also see microsoft/vscode-cmake-tools#2442 and microsoft/vscode-cmake-tools#2515).

To Reproduce

Attempt to debug a test using the gutter "play" button in an environment where environment variables contain newlines. In my project fork, I've included a devcontainer setup that can be used to reliably reproduce the problem (specifically, the environment-modules package sets up some functions that get exported with newlines).

Screenshots (optional)

Desktop

• Extension Version: 4.3.1
• VS Code Version: 1.70.2
• Catch2 / Google Test / DOCTest Version: GTest a9b2f0495
• OS Type and Version: Linux (Debian Bullseye)
• Using remote-ssh/docker/wsl?: Docker - devcontainer

Log (optional but recommended)

Log not included, will file a pull request momentarily.

[matepek]

Hello,

It sounds like a "Microsoft GDB adapter" issue.
Why do you think it should be fixed here?

[matepek]

Btw you can check the documentation of debugConfigTemplate

And I added a new paragraph which might be helpful for this case to here

[bspeice]

Hello,

It sounds like a "Microsoft GDB adapter" issue. Why do you think it should be fixed here?

Because other official C++ plugins have fixed the issue without touching the cpptools extension (microsoft/vscode-cmake-tools#2518). I agree that it's an issue with the cppdbg adapter (the lldb extension adapter doesn't suffer the same problem), but I'm hoping to merge this fix as a way to improve the default user experience.

I'm currently trying to investigate how VS Code launches GDB (I think the cpptools extension is responsible for actually spawning the executable), I'll add another comment once I have more details on whether this can be solved upstream. My concern is that GDB commands in general don't support newline characters (microsoft/vscode-cpptools#3666) so there might not be a general solution.

Btw you can check the documentation of debugConfigTemplate

And I added a new paragraph which might be helpful for this case to here

That works if users are aware of all environment variables that contain newlines ahead of time. As is the case with the environment-modules package, it's very frequently the case that users never intended to have environment variables with newlines (some distros install it by default), but ended up with problems anyway.

My specific concern is that error messages are extremely difficult to understand and it's not clear how to fix the problems. If you're not comfortable filtering out environment variables, would it be beneficial to have some form of warning (popup notification that can be ignored in the future?) so users are aware of the potential problems?

[bspeice]

I was wrong about the extension; the specific problem comes from the debug engine that cpptools relies on not escaping commands properly:

https://github.com/microsoft/MIEngine/blob/3511d551feb27fd5e5d78e0edd98ce6ff827384b/src/MICore/Debugger.cs#L840

I think the fix might be to add \n to the debug escape sequences here:

https://github.com/microsoft/MIEngine/blob/3511d551feb27fd5e5d78e0edd98ce6ff827384b/src/MICore/Debugger.cs#L774

Going to open an issue there to see what they think.

[matepek]

If it were "fixed" in this extension then maybe one day another user came and say "my multiline env variables are not working, the extension is buggy". Should I say: "It's not a bug, it's a feature"?
:)
Beside jokes. If we agree that the issue is coming from another extension and I provided a way for workaround I think I will close this.