Closed amyspark closed 2 years ago
From the logs, it seems like the PATH environment is set on GDB:
1: (1077) <-1011-interpreter-exec console "set env PATH E:\\krita-win\\i_msys\\bin\\;E:\\krita-win\\i_deps_msys\\bin\\;D:\\msys64\\ucrt64\\bin\\;D:\\Ruby30-x64\\bin;D:\\Program Files\\AdoptOpenJDK\\jdk-11.0.11.9-hotspot\\bin;C:\\Program Files\\Python38\\Scripts\\;C:\\Program Files\\Python38\\;C:\\Program Files\\NVIDIA GPU Computing Toolkit\\CUDA\\v8.0\\bin;C:\\Program Files\\NVIDIA GPU Computing Toolkit\\CUDA\\v8.0\\libnvvp;C:\\Program Files\\NVIDIA GPU Computing Toolkit\\cuDNN\\v6.0\\bin;C:\\Program Files (x86)\\Common Files\\Intel\\Shared Files\\cpp\\bin\\Intel64;C:\\Windows\\system32;C:\\Windows;C:\\Windows\\System32\\Wbem;C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\;C:\\Windows\\System32\\OpenSSH\\;D:\\Program Files\\Calibre2\\;C:\\WINDOWS\\system32;C:\\WINDOWS;C:\\WINDOWS\\System32\\Wbem;C:\\WINDOWS\\System32\\WindowsPowerShell\\v1.0\\;C:\\WINDOWS\\System32\\OpenSSH\\;C:\\Program Files\\7-Zip;C:\\Program Files\\Pandoc\\;C:\\Program Files\\TortoiseSVN\\bin;C:\\Program Files\\PuTTY\\;C:\\Program Files\\Git\\cmd;C:\\ProgramData\\chocolatey;C:\\Program Files\\dotnet\\;C:\\Program Files\\CMake\\bin;C:\\ProgramData\\chocolatey\\bin;C:\\Program Files\\PowerShell\\7\\;C:\\Program Files\\nodejs\\;C:\\Program Files (x86)\\NVIDIA Corporation\\PhysX\\Common;C:\\Program Files\\gs\\gs9.51\\bin;C:\\Users\\Amalia\\AppData\\Local\\Streamlink\\bin;C:\\Users\\Amalia\\.cargo\\bin;D:\\texlive\\2022\\bin\\win32;C:\\Users\\Amalia\\AppData\\Local\\Microsoft\\WindowsApps;C:\\Users\\Amalia\\AppData\\Roaming\\Python\\Python38\\Scripts;C:\\Users\\Amalia\\AppData\\Local\\Programs\\Microsoft VS Code\\bin;"
--> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (1085) ->1011^done\r\n"},"seq":226}
I see the gdb being used is D:\msys64\ucrt64\bin\gdb.exe
, does moving ;D:\\msys64\\ucrt64\\bin
earlier in the path help?
If it is this issue:
The added folders are just not available on the child process, thus leading to the crash depicted in the logs.
Then this would be an issue in GDB not spawning the process with the set PATH.
Then this would be an issue in GDB not spawning the process with the set PATH.
GDB 8 can spawn the process successfully, GDB 11 can not and crashes with the error code above.
It seems the problem is that everywhere e.g. here, here, and here the system environment variable is called PATH
, but instead in Windows 10 it's called Path
(caps sensitive). All other commands e.g. tasks.json calling cmd.exe handle this correctly, but cppdbg does not.
GDB 8 can spawn the process successfully, GDB 11 can not and crashes with the error code above.
This suggests that it is a bug with gdb 11.
It seems the problem is that everywhere e.g. here, here, and here the system environment variable is called PATH, but instead in Windows 10 it's called Path (caps sensitive). All other commands e.g. tasks.json calling cmd.exe handle this correctly, but cppdbg does not.
However, if it is this, can you modify the environment
in your launch.json
to be this:
{
"name": "Path",
"value": "${workspaceFolder}\\i_msys\\bin\\;${workspaceFolder}\\i_deps_msys\\bin\\;D:\\msys64\\ucrt64\\bin\\;${env:PATH}"
},
and see if debugging work?
However, if it is this, can you modify the environment in your launch.json to be this:
Yes, I modified it and it works now. Though I'm still not sure whether it's GDB that is wrong; for instance, launching an instance of CMD works, and Process Explorer shows the modified PATH. But if the app itself requires the changed PATH, it crashes on launch. Perhaps the modification is done asynchronously?
In any case, feel free to close this issue if you deem the problem be inside GDB.
This issue brings up a great discussion. Thank you for bringing this topic up.
I'm on the fence on if the debug adapter detects that it is on Win 10 or greater, if we notice an env PATH
being set, modify it to just be Path
to make GDB happy.
Auto-detecting and causing changes like this usually end it making it more difficult for the user to understand what actually went wrong.
This issue has been closed because it is a question and has not had recent activity.
Environment
Bug Summary and Steps to Reproduce
Bug Summary:
Environment variables specified in the launch task do not apply to the debugger: Applications that do need them will instantly crash on launch with error 0xc00000135.
Steps to reproduce:
Debugger Configurations
Debugger Logs
Other Extensions
No response
Additional Information
A trace of the target app with Process Monitor shows that it launchs without the requested environment variables. The added folders are just not available on the child process, thus leading to the crash depicted in the logs.