Linux debug launch hangs if the .NET SDK is installed with Snap
DmitryNaumov opened this issue · 12 comments
Edits by the repro owner:
Repro steps:
- Install the .NET SDK or .NET Runtime via Snap on Linux. There are probably some other technologies that might trigger this problem as well.
- Create a hello world project
- Try to debug
Result:
Target process hangs when the .NET Runtime loads in the target process and debugging never proceeds
Work around:
Install the .NET Runtime using a different technology such as apt or the dotnet-install script.
Original text
It took me a while to figure out why my remote debugging suddenly stopped working. Here is short version:
I've managed to find how to enable engine logging and here is output:
-> (C) {"command":"threads","type":"request","seq":6}
<- (R) {"seq":13,"type":"response","request_seq":6,"success":true,"command":"threads","body":{"threads":[]}}
v1.25.0 successfully goes further, v1.25.2 stucks at this point until you terminate debugging session.
Hi @DmitryNaumov can you tell us more about your setup (target OS? target .NET version? vsdbg version? attach vs launch? launch.json configuration?), and also how you are comparing the two versions of the C# extension. I guess anything is possible, but it would be very strange for a difference in the C# extension to cause the issue you are seeing.
I am seeing the same thing but with launching local debugging on Ubuntu 20.04 using Dotnet 6. Just stops never loads any debug symbols. Works fine with 1.25.0
@gregg-miskelly Win10 as client OS running VS Code, .net core 6 & 7 (tried both) on Ubuntu 20.04 as remote OS. It worked like a charm 2 weeks ago (launch) and I would agree that many factors may contribute to this strange behaviour, but downgrading to v1.25.0 fixes that immediately. And looking to changelog gives me idea that this is what has changed in my setup during last week, cause v1.25.1 and v1.25.2 were released a few days ago and v1.25.0 was around for monthes. So you still may be right, but I would say "it is highly likely that recent extension upgrade caused the trouble". Btw I've checked with Golang and it's remote debugging works perfectly. And just in case I've disabled extensions auto update...
@SteveCurran I am not sure your issue is related, so I would suggest opening a new issue.
@SteveCurran and @DmitryNaumov can you provide a full log?
I am seeing the same thing but with launching local debugging on Ubuntu 20.04 using Dotnet 6. Just stops never loads any debug symbols. Works fine with 1.25.0
Exactly - no symbols loaded, just stuck with initial banner about remote debugger
Please provide a full log
@gregg-miskelly opened #5461
See attached
Log.txt
Got it. When you said 'remote debugging' I was thinking of PipeTransport, which would mean that it would be very strange that a new version of the extension would break anything. But you mean you are using VS Code remoting, which makes much more sense. It looks like the two issues are indeed the same.
@DmitryNaumov How did you install the .NET SDK into your Linux machine?
The underlying problem is tracked with dotnet/diagnostics#3510. This issue will be used to track updating the C# extension once there is a new libdbgshim.so with the fix.
How did you install the .NET SDK into your Linux machine?
I've installed .NET via Snap and I see that it could be a root cause. But why downgrading extensions helps to overcome the issue?
But why downgrading extensions helps to overcome the issue?
.NET Debuggers include a library named libdbgshim.so that comes from the .NET team that is used to load the .NET debugging services. The new version of this library has the bug referenced above. The old version of the extension shipped the previous version of libdbgshim.so. We can't just roll back to the old version though, as new versions of the debugger depend on functionality from the new libdbgshim. So for now, you can either continue using the old version of the C# extension, or you can switch to the Microsoft-built versions of the .NET runtime, such as the one pulled by the dotnet-install script, or the version on the Microsoft apt feed.