Open DenSmoke opened 5 years ago
That error code is CORDBG_E_TIMEOUT.
My guess would be that the issue is that you need to be root to debug the process. Though I don't know why you wouldn't be getting some sort of 'access denied' error if that is the case. The other idea that occurs to me is that maybe you are attaching to the wrong process. Maybe tweak your code to print its process id and see if that is the same as the process you are attaching to.
All tools show same PID for the process. I can't find any other processes for my app.
I tried to set "debuggerPath": "sudo ~/vsdbg/vsdbg"
but it doesn't help too
I found the reason - it is PrivateTmp=true
setting in service config. I changed it to false and debugger attached successfully.
But it is still unclear for me how does this setting impact on vsdbg.
Thanks for digging! I believe this is because CoreCLR stores its IPC (inter-process-communication) objects in the temp directory. I am not sure if CoreCLR can somehow fix this. @Mikem8361 any thoughts?
CoreCLR assumes an accessible /tmp directory. It honor the $TMPDIR environment variable but otherwises assumes /tmp/.
I think the problem here isn't that the temp directory is inaccessible, but rather the target process's temp directory != the debugger's temp directory. The only thing I can think to somehow improve is - maybe we can fail with a better error and have some other configuration nob if people really need to have isolated temp directory (ex: set CORECLR_IPC_DIR environment variable in both processes)?
To have an env var to configure the IPC directory is a fairly big change and would require VS to take a new dbgshim too. That would cover the named pipes used for debugging. The named semaphores are used by dbgshim/runtime to coordinate debugger launch may also be an issue and there is really no way to override the root directory (/dev/shm) on Linux.
Agreed, but it does feel like a significant gap to me that these services can't be debugged. So it feels like we should have something on the back log to address it, even if it is just a work around because the underlying problem can't be fixed.
@gregg-miskelly We are facing similar situation while trying to attach to service fabric services. Do you guys have any work around or any fix available for this issue?
OS: Ubuntu 18.04.4 LTS OmniSharp: 1.22.1 DotNet: 3.1.301 SF: 7.1
While trying to attach to service from VS code, it is giving an error: 0x80131c08 I am running VS Code as a elevated privileges under sudo and it is using its own private user data directory.
Output from vsdbg-ui
Waiting for communication on port 4711...
>> accepted connection from client
-> (C) {"command":"initialize","arguments":{"clientID":"vscode","clientName":"Visual Studio Code","adapterID":"coreclr","pathFormat":"path","linesStartAt1":true,"columnsStartAt1":true,"supportsVariableType":true,"supportsVariablePaging":true,"supportsRunInTerminalRequest":true,"locale":"en-us","supportsProgressReporting":true},"type":"request","seq":1}
<- (R) {"seq":0,"type":"response","request_seq":1,"success":true,"command":"initialize","message":"","body":{"supportsConfigurationDoneRequest":true,"supportsFunctionBreakpoints":false,"supportsConditionalBreakpoints":true,"supportsHitConditionalBreakpoints":true,"supportsEvaluateForHovers":true,"exceptionBreakpointFilters":[{"filter":"all","label":"All Exceptions","default":false},{"filter":"user-unhandled","label":"User-Unhandled Exceptions","default":true}],"supportsSetVariable":true,"supportsGotoTargetsRequest":true,"supportsModulesRequest":true,"additionalModuleColumns":[],"supportedChecksumAlgorithms":["MD5","SHA1","SHA256"],"supportsExceptionOptions":true,"supportsValueFormattingOptions":true,"supportsExceptionInfoRequest":true,"supportTerminateDebuggee":true,"supportsSetExpression":true,"supportsReadMemoryRequest":true,"supportsExceptionConditions":true,"supportsLoadSymbolsRequest":true,"supportsModuleSymbolSearchLog":true,"supportsDebuggerProperties":true,"supportsSetSymbolOptions":true}}
-> (C) {"command":"initialize","arguments":{"clientID":"vscode","clientName":"Visual Studio Code","adapterID":"coreclr","pathFormat":"path","linesStartAt1":true,"columnsStartAt1":true,"supportsVariableType":true,"supportsVariablePaging":true,"supportsRunInTerminalRequest":true,"locale":"en-us","supportsProgressReporting":true},"type":"request","seq":1}
-> (C) {"command":"attach","arguments":{"name":".NET Core Attach","type":"coreclr","request":"attach","processId":"6352","logging":{"engineLogging":false},"debugServer":4711,"__sessionId":"107ce00b-afc0-40f9-bbc4-eb86c7786acb"},"type":"request","seq":2}
<- (E) {"seq":3,"type":"event","event":"output","body":{"category":"console","output":"-------------------------------------------------------------------\nYou may only use the Microsoft .NET Core Debugger (vsdbg) with\nVisual Studio Code, Visual Studio or Visual Studio for Mac software\nto help you develop and test your applications.\n-------------------------------------------------------------------\n"}}
<- (R) {"seq":4,"type":"response","request_seq":2,"success":true,"command":"attach"}
<- (E) {"seq":5,"type":"event","event":"initialized","body":{}}
-> (C) {"command":"setExceptionBreakpoints","arguments":{"filters":["user-unhandled"]},"type":"request","seq":3}
<- (R) {"seq":6,"type":"response","request_seq":3,"success":true,"command":"setExceptionBreakpoints"}
-> (C) {"command":"configurationDone","type":"request","seq":4}
<- (E) {"seq":7,"type":"event","event":"output","body":{"category":"telemetry","output":"VS/Diagnostics/Debugger/vsdbg/AttachFailed","data":{"VS.Diagnostics.Debugger.vsdbg.ErrorCode":-2146231288,"VS.Diagnostics.Debugger.vsdbg.Distribution.Name":"ubuntu","VS.Diagnostics.Debugger.vsdbg.Distribution.Version":"18.04","VS.Diagnostics.Debugger.vsdbg.OSFamily":"Linux","VS.Diagnostics.Debugger.vsdbg.Version":"16.6.20415.1 commit:0184bb70e1ed40656c0dfa53125805036207007b"}}}
<- (R) {"seq":8,"type":"response","request_seq":4,"success":false,"command":"configurationDone","message":"Failed to attach to process: Unknown Error: 0x80131c08"}
-> (C) {"command":"disconnect","arguments":{"restart":false},"type":"request","seq":5}
-> (C) {"command":"threads","type":"request","seq":6}
<- (E) {"seq":9,"type":"event","event":"output","body":{"category":"telemetry","output":"VS/Diagnostics/Debugger/vsdbg/DebugCompleted","data":{"VS.Diagnostics.Debugger.vsdbg.AdapterId":"coreclr","VS.Diagnostics.Debugger.vsdbg.DebugCompleted.BreakCounter":0,"VS.Diagnostics.Debugger.vsdbg.Distribution.Name":"ubuntu","VS.Diagnostics.Debugger.vsdbg.Distribution.Version":"18.04","VS.Diagnostics.Debugger.vsdbg.OSFamily":"Linux","VS.Diagnostics.Debugger.vsdbg.Version":"16.6.20415.1 commit:0184bb70e1ed40656c0dfa53125805036207007b"}}}
<- (R) {"seq":10,"type":"response","request_seq":5,"success":true,"command":"disconnect"}
>> client connection closed
CC @mikem8361
The only work around that I know of is to temporarily force both processes to use the same temp directory.
How to I set temp directory for vsdbg? using TMPDIR environment variable? I figured, I am running a service fabric service, which will have different temp directory per instance.
Sorry, I have no idea how to do that for services.
Same issue in the Visual Studio 2022, not only vscode
The work around was perfect. Saved my day.
Environment data
VS Code version: 1.38.1 C# Extension version: 1.21.2
Steps to reproduce
I'm trying to attach debugger via ssh to ASP.NET Core app (.NET Core 3.0 preview9) running on Ubuntu 18.04 x64 under systemd.
systemd service config:
Expected behavior
Debugger attach
Actual behavior
Error 0x80131c08
Same error when attaching with Visual Studio 2019 16.3.0 preview 3.0
Debugger attaches and works well if I launch app on remote host in bash typing
/home/dotnet/dotnet /home/thedensmoke/techwiz_admin_api/TechWiz.Admin.Api.dll
Work around
Note: adding by gregg-miskelly Disable
PrivateTmp=true