dotnet / vscode-csharp

Official C# support for Visual Studio Code
MIT License
2.86k stars 672 forks source link

Error 0x80131c08 when attaching debugger to systemd process that uses `PrivateTmp=true` #3277

Open DenSmoke opened 5 years ago

DenSmoke commented 5 years ago

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:

[Unit]  
Description=TechWiz.Admin.Api service  

[Service]  
ExecStart=/home/dotnet/dotnet /home/thedensmoke/techwiz_admin_api/TechWiz.Admin.Api.dll
WorkingDirectory=/home/thedensmoke/techwiz_admin_api
User=thedensmoke  
Group=thedensmoke  
Restart=always
RestartSec=10  
SyslogIdentifier=techwiz_admin_api
PrivateTmp=true  

[Install]  
WantedBy=multi-user.target 

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

gregg-miskelly commented 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.

DenSmoke commented 5 years ago

image image image

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

DenSmoke commented 5 years ago

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.

gregg-miskelly commented 5 years ago

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?

mikem8361 commented 5 years ago

CoreCLR assumes an accessible /tmp directory. It honor the $TMPDIR environment variable but otherwises assumes /tmp/.

gregg-miskelly commented 5 years ago

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)?

mikem8361 commented 5 years ago

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.

gregg-miskelly commented 5 years ago

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.

tejasavora commented 4 years ago

@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
gregg-miskelly commented 4 years ago

CC @mikem8361

The only work around that I know of is to temporarily force both processes to use the same temp directory.

mikem8361 commented 4 years ago

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.

kinguru commented 1 year ago

Same issue in the Visual Studio 2022, not only vscode

VasuInukollu commented 4 months ago

The work around was perfect. Saved my day.