Open CAD97 opened 3 years ago
CodeLLDB runs a copy of itself in the terminal to figure out which console to attach stdio to. This information is then communicated back to the main instance via that second port you are seeing (the first port is where VSCode attaches to control the debug session). Do you see this "terminal agent" instance starting in the terminal? Does it report any errors?
I've seen reports of this behavior before, but was never able to reproduce locally. I was not able to compile the breakout example because of some errors about missing "__GSHandlerCheck_EH4" symbol, but I doubt it's related to a specific debuggee, and more likely something to do with debugger startup timing.
Failure is inconsistent on my machine as well. It almost certainly has to do with startup timing, and something timing out. It definitely fails more often when something is multitasking, and less often when starting up the debug is the only thing going on.
By launching with "terminal": "external"
, I see exactly nothing in the external terminal; just "Press any key to continue...".
Using the integrated terminal, command history shows the command run as & 'c:\Users\CAD\.vscode\extensions\vadimcn.vscode-lldb-1.6.1\adapter\codelldb.exe' 'terminal-agent' '--port=64721'
and a $LASTEXITCODE
of 0
(unfortunately). Attempting to manually run the command from command history gives "connection actively refused".
I'm experiencing this exact issue with a bevy project too. The odd thing is that in two of my projects this does not happen but in other projects it does. I've tried switching between nightly and stable rust, recompiling, reloading, all terminal settings, nothing seems to be able to fix this it just... happens to some projects and not others. I could not tell you the difference other than that they're different projects in different locations configured exactly the same
Edit: I tried creating a completely fresh project and this seems to happen only when I add the DefaultPlugins, but I also add those in the projects where it works correctly, so I'm pretty stumped at what could cause this to happen
Edit 2: It started randomly working after I commented out some code, got a panic on run, added the code back in, and now it works. Seems like this might be a really convoluted edge case
Just fixed something while investigating another bug, wondering if it was the root cause of this one as well. Can you try this build?
Can confirm it's happening with MSYS Clang 13.0.1 and CodeLLDB 1.7.0. Having a working cout is almost impossible.
I'm encountering this in my Work on a C++ project called Prismlauncher. I try to do most of my work in Neovim using the codelldb dap adapter. but currently I end up moving over to VSCode to use cppvsdbg
just to test some things.
if i use the "integrated"
terminal
setting in my launch.json
I get this
Console is in 'commands' mode, prefix expressions with '?'.
[debug-adapter stderr] [adapter\codelldb\src\terminal.rs:101] winapi::um::wincon::FreeConsole() = 1
Launching: C:\Users\ryexc\Projects\PrismLauncher\install\prismlauncher.exe
Launched process 41620
my internal logging shows this
0.007 D | Console Attached : No
0.007 D | STDIn Type : 0
0.007 D | STDOut Type : 0
0.007 D | STDError Type : 0
where the handle types are retrieved like so
auto stdinType = GetFileType(GetStdHandle(STD_INPUT_HANDLE));
auto stdoutType = GetFileType(GetStdHandle(STD_OUTPUT_HANDLE));
auto stderrType = GetFileType(GetStdHandle(STD_ERROR_HANDLE));
I should probably note that Prismlauncher does not use AllocConsole
to make it's own console only AttachConsole(ATTACH_PARENT_PROCESS)
to attach to a parent process console
If however i use the "console"
value for terminal
in launch.json
I get this
Console is in 'commands' mode, prefix expressions with '?'.
Launching: C:\Users\ryexc\Projects\PrismLauncher\install\prismlauncher.exe
Launched process 113700
[debug-adapter stderr] 0.000 D | Testing "C:/Users/ryexc/Projects/PrismLauncher/install/qtlogging.ini" ...
[debug-adapter stderr] 0.000 D | Loading logging rules from: "C:/Users/ryexc/Projects/PrismLauncher/install/qtlogging.ini"
0.000 D | Setting log rules:
0.000 D | "*.debug=true"
[debug-adapter stderr] 0.001 D | "launcher.auth.credentials.debug=false"
0.013 D | Console Attached : Yes
0.013 D | STDIn Type : 1 // disk
0.013 D | STDOut Type : 3 // pipe
0.013 D | STDError Type : 3 // pipe
the console successfully attaches but everything is mixed together instead of going to the correct place
I tried to replicate in VSCode and i get no redirected console there as well.
I also get this in the LLDB output log
Initial debug configuration: {
name: 'PrismLauncher lldb (VSCODE ONLY)',
type: 'lldb',
request: 'launch',
program: '${workspaceFolder}/install/prismlauncher',
stopOnEntry: false,
cwd: '${workspaceFolder}/install',
stdio: null,
terminal: 'integrated',
windows: { program: '${workspaceFolder}/install/prismlauncher.exe' },
__configurationTarget: 6
}
Resolved debug configuration: {
name: 'PrismLauncher lldb (VSCODE ONLY)',
type: 'lldb',
request: 'launch',
program: '${workspaceFolder}/install/prismlauncher',
stopOnEntry: false,
cwd: '${workspaceFolder}/install',
stdio: null,
terminal: 'integrated',
windows: { program: '${workspaceFolder}/install/prismlauncher.exe' },
__configurationTarget: 6,
relativePathBase: 'c:\\Users\\ryexc\\Projects\\PrismLauncher',
_adapterSettings: {
displayFormat: 'auto',
showDisassembly: 'auto',
dereferencePointers: true,
suppressMissingSourceFiles: true,
evaluationTimeout: 5,
consoleMode: 'commands',
sourceLanguages: null,
terminalPromptClear: null,
evaluateForHovers: true,
commandCompletions: true,
reproducer: false
}
}
[adapter\codelldb\src\terminal.rs:101] winapi::um::wincon::FreeConsole() = 1
[adapter\codelldb\src\terminal.rs:102] winapi::um::wincon::AttachConsole(pid) = 1
[adapter\codelldb\src\terminal.rs:109] winapi::um::wincon::FreeConsole() = 1
This seems to indicate that codelldb is attempting to attach to the child process console and then immediately detaching
OS: Microsoft Windows Version 2004 (OS Build 19041.685) VSCode version: Visual Studio Code Version 1.52.1 (system setup) Extension version: v1.6.0 Compiler: rustc 1.50.0-nightly (b32e6e6ac 2020-12-16) Build target: x86_64-pc-windows-msvc
When debugging Bevy games, stdio is failing to be redirected (terminal agent did not respond within the allotted time). (Side note: because of #380, the debug console says "Debugee output will appear here", but it doesn't, as debugee output is going to the LLDB log exclusively.) Interestingly, the LLDB log says
Listening on port 55372
, and command history in the terminal shows that it was attaching to--port=55375
?Debug Log
Output (LLDB)
This can be most easily reproduced by cloning the bevy repo and running the breakout example via the debugger.
This does not seem to be an issue for smaller projects, so perhaps this is related to startup time? My trivial playground works just fine (there
Listening on port 55492
and--port=55494
it seems, so that's not the issue, I suppose.)Debugging itself seems to work fine, it's just the stdio redirection that is not working.
(Panic in bevy example is due to working directory shenanigans, and is more likely a bevy issue.)