Crash: 'Debug adapter process has terminated unexpectedly' on arch and manjaro

[NikkyAI]

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.1)

Product Information:
 Version:            1.0.1
 Commit SHA-1 hash:  005db40cd1

Runtime Environment:
 OS Name:     manjaro
 OS Version:
 OS Platform: Linux
 RID:         ubuntu.16.10-x64
 Base Path:   /opt/dotnet/sdk/1.0.1

VS Code version:

Version 1.10.2
Commit 8076a19fdcab7e1fc1707952d652f0bb6c6db331
Date 2017-03-08T14:00:46.854Z
Shell 1.4.6
Renderer 53.0.2785.143
Node 6.5.0

C# Extension version:
1.8.0

Steps to reproduce

• install dotnet, dotnet-cli and dotnet-sdk on archlinux (see additional info for building from aur)
• install C# extension
• try to debug anything

Expected behavior

running the debugger

Actual behavior

instant crash when trying to run the debugger

Debug adapter process has terminated unexpectedly

Additional info

Linux railgun 4.9.13-1-rt11-MANJARO #1 SMP PREEMPT RT Wed Mar 1 17:46:29 UTC 2017 x86_64 GNU/Linux

System Info

 OS: Manjaro 17.1-dev Gellivara
 Kernel: x86_64 Linux 4.9.13-1-rt11-MANJARO
 Uptime: 5d 12h 23m
 Packages: 1655
 Shell: zsh 5.3.1
 Resolution: 1920x1080
 DE: XFCE4
 WM: Xfwm4
 WM Theme: Vertex-Maia
 GTK Theme: Vertex-Maia-Square [GTK2]
 Icon Theme: Vertex-Maia
 Font: Cantarell 10
 CPU: Intel Core i5-6200U @ 4x 2.8GHz
 GPU: Mesa DRI Intel(R) HD Graphics 520 (Skylake GT2)

to make dotnet build on archlinux/manjaro
i remember i had to patch a single line in corefx build because of

ignoring return value of function declared with 'warn_unused_result'
attribute [-Werror,-Wunused-result]
pipe2(waitForChildToExecPipe, O_CLOEXEC);

with

-    pipe2(waitForChildToExecPipe, O_CLOEXEC);
+    if (pipe2(waitForChildToExecPipe, O_CLOEXEC)) { } else { }

i wonder if something similar happens with corclr, because i have seen patch files for that flying around too https://gist.github.com/leafi/9404f79bcd3c64e4d828c0c5e06f056d although the line numbers and commit hashes are different now...

followed the steps on #564 #564 (comment)
to install the debugger for 14.04 as well, did not help
tried installing the 16.10 debugger as well (because dotnet --info suggested that it might be compatible with that.. as expected a "Debug adapter process has terminated unexpectedly"

[baumhoto]

had the same issue (Archlinux 4.9 Kernel, Dotnet 1.0.1, Vscode 1.10.2, C# Extension 1.8.0), but for me it works after i downloaded the ubuntu 14.04 debugger as suggested above.

[NikkyAI]

same versions.. although i do not know if mnjaro-rt 4.9 is the same as archlinux 4.9 that it is based on.. but it does not help as i mentioned before
same issue, shows the debug controls for a split second and then opens the error popup

[baumhoto]

ok. steps i did:

• deleted everything from .debugger folder in vscode c# extension
• downloaded the following zip: wget https://vsdebugger.azureedge.net/coreclr-debug-1-8-6/coreclr-debug-ubuntu.14.04-x64.zip
• extracted zip to .debugger folder in c# extension dir
• needed to set execute right on vsdbg-ui (otherwise would get an SPAWN error in vscode when starting the debugger)

[NikkyAI]

i did the same and tried with all versions of the debugger for ubuntu

• 16.04 obviously
• 14.04 as suggested
• 16.10 too

same result everwhere
some kind of error log would be nice
PS: by now i think that it might crash because of some other missconfiguration in the build task or launch.json .. but it works on windows

[starquake]

I tested on a normal arch installation. Same issue. Also tried 16.04, 14.04 and 16.10 and fedora 24

[starquake]

Running vsdbg is fine. Running vsdbg-ui responds with:

[starquake@archmonkey .debugger]$ ./vsdbg-ui 
Failed to initialize CoreCLR, HRESULT: 0x80131500

[starquake]

So apparently the wrong version of icu is expected. ArchLinux has icu 58.

I executed this command in the debugger folder:find *.so -type f | xargs ldd 2> /dev/null | grep not\ found
which gave met the following output:

	liblldb-3.6.so => not found
	libvsdebugeng.so => not found
	libvsbaseservices.so => not found
	libvsbaseservices.so => not found
	libicuuc.so.55 => not found
	libicui18n.so.55 => not found
./System.Net.Http.Native.so: /usr/lib/libcurl.so.4: version `CURL_OPENSSL_3' not found (required by ./System.Net.Http.Native.so)

I installed icu55 which can be found in the AUR here: https://aur.archlinux.org/packages/icu55/

Now debugging works again!

[JBildstein]

I installed icu55

• with 16.10 same error as before
• with 16.04:
  • popup says: Error processing 'configurationDone' request. Unknown Error: 0x89720010
  • Output->Extensions prints: Waiting for communication on stdin/stdout...
• with 14.04 same error as before

dotnet --info:

.NET Command Line Tools (1.0.1)

Product Information:
 Version:            1.0.1
 Commit SHA-1 hash:  005db40cd1

Runtime Environment:
 OS Name:     manjaro
 OS Version:  
 OS Platform: Linux
 RID:         ubuntu.16.10-x64
 Base Path:   /opt/dotnet/sdk/1.0.1

after installing icu55, find *.so -type f | xargs ldd 2> /dev/null | grep not\ found still returns:

./System.Net.Http.Native.so: /usr/lib/libcurl.so.4: version `CURL_OPENSSL_3' not found (required by ./System.Net.Http.Native.so)
        liblldb-3.6.so => not found
        libvsdebugeng.so => not found
        libvsbaseservices.so => not found
        libvsbaseservices.so => not found

[starquake]

16.10 and 14.04 expect other icu versions so that's not going to work.
Maybe remove the ms-vscode.csharp-1.8.0 extension and reinstall it.

"Waiting for communication on stdin/stdout..." Actually sounds like it's working. Did you try restarting visual studio code?

[JBildstein]

ah yes of course, that makes sense.
tried to reinstall the whole extension but got the same result.
I did restart vs code and also it was closed while I changed the packages.

Tried it again with

• 14.04 and icu52
• 16.10 and icu57
  which both result in the same error/result as before with 16.04 (0x89720010)

The problem seems to be attaching to the process. If I do a dotnet run in the console and use ".NET Core Attach" in vs code I get the error.
If I use ".NET Core Launch" I can see two dotnet processes spawn for a short time in the system monitor and then I get the error.
Any idea why that might be? maybe a rights issue?

[rajkumar42]

@JBildstein which version of VSCode are you running?

[JBildstein]

@rajkumar42 Version 1.10.2 - (8076a19fdcab7e1fc1707952d652f0bb6c6db331)
I installed it from the AUR: visual-studio-code-oss

[rajkumar42]

@JBildstein please install stable or insiders.

[JBildstein]

@rajkumar42 curios, the version from code.visualstudio.com works (using 16.10/icu57) even though it is the exact same version and commit hash as the one from AUR.
Anyway, glad it works now, thanks for the help!

[NikkyAI]

isu55 and ubuntu 16.04 works on my manjaro system.. yay

i guess the issue should stay open until this is adressed in the debugger installer though..

[gregg-miskelly]

@NikkyAI are there things that you think the exception can reasonable do today to fix this?

In the longer term (a few months) .NET Core is making changes that they believe will eliminate this class of issue for .NET Core 2.0.

[NikkyAI]

@gregg-miskelly could you check which version of icu is available and suggest installing one that matches the debugger ?

[gregg-miskelly]

@NikkyAI what is the right way on arch to see what version of icu is installed?

[starquake]

Multiple versions of icu can be installed: https://aur.archlinux.org/packages/?O=0&SeB=n&K=icu&outdated=&SB=n&SO=a&PP=50&do_Search=Go
Instead of checking if the package is installed I would rather check if the library is available.

I would check if the needed version is installed using something like:

➜  ~ ldconfig -p | grep libicuuc.so.55
        libicuuc.so.55 (libc6,x86-64) => /usr/lib/libicuuc.so.55

Alternatively you could just check if /usr/lib/libicuuc.so.55 exists

If you want to actually know what version is included in the icu package that is currently installed do this:

pacman -Qi icu | grep "Version" | sed 's/^Version\s*:\s//'

[gegenschall]

In my humble opinion the real solution would be to give the user a setting to configure the .NET Core debugger path manually, I'm thinking something like omnisharp.debuggerPath.

That way it would be possible to create a working version of the debugger by replacing all *.so and *.Native.dll with the ones from the dotnet AUR package and persist these changes across omnisharp updates.

Fumbling with icu/curl/$whatnot versions is time consuming, error prone and just not the right way to do it.

edit: I created an AUR package for the debugger that should work for all Arch based distributions: vscode-coreclr-debug.
Install it, boldly rm -r your ~/.vscode/extensions/ms-vscode.csharp-1.?.?/.debugger directory and then issue a ln -s /opt/dotnet/debugger ~/.vscode/extensions/ms-vscode.csharp-1.?.?/.debugger. Should be working just fine...

[gregg-miskelly]

Here is my tentative plan, let me know if anyone hates this. I haven't finished implementing this yet, so I may change my mind if something doesn't work as well as I am expecting.

1. Add a new preference to VS Code to select what version of the debugger to use on Linux
2. Add a new wiki page with the relevant parts of this issue to this repo
3. Add a new error message when installing on arch that will direct folks to the wiki page

[rajkumar42]

👍
@gregg-miskelly would this selector show up only on arch (unsupported coreclr distros) ?

[gregg-miskelly]

@rajkumar42 my thought is that we would look at the setting on any Linux distro other than the few officially supported ones (ex: Ubuntu16).

[rafamerlin]

@gegenschall I tried your solution but now when I open Vs Code it immediately gives me:

[ERROR]: An error occured while installing the .NET Core Debugger:
Error: Error during installation.

I've also tried to add on /etc/os-release the line

ID_LIKE=arch

And to install icu55.

I'm using Manjaro. Do you know if there is something I'm missing.

Cheers

Edit:

I was able to fix it!
First I've removed the vscode-coreclr-debug package and the extension.
Then I've reinstalled the extension and also installed icu54 (besides the 55), because I saw in another issue someone mentioning that fedora install + icu 54 worked.

Well, I tried the fedora first but it didn't work, so I went back to ubuntu and the ID_LIKE and now it's working fine.

I know here's not the place to ask it, but being a noob, I got that icu are libraries that install a bunch of packages on linux. I just couldn't get how other users were able to find out which icu was missing (55 and 54 for example). Is there any reference I can use to learn the same.

[gegenschall]

@Merurino Ignore the error and don't install funky icu versions, just use the one from [core] it should be working just fine.

[rafamerlin]

Hey @gegenschall thanks for the reply.
By core you mean the AUR package you made? It didn't work. Is it dangerous to install icu packages? I got them from AUR and checked the script before installing.

[gegenschall]

@Merurino By [core] I mean the default Arch Linux core repository. No, it's not dangerous to install icu packages but the dotnet dependency of vscode-coreclr-debug is (partially) compiled from the coreclr source code anyway and should correctly link to the latest icu version from the core repository. This means that there shouldn't be any need to "clog" your system with additional icu versions.

But hey: If your method works, then all is good. Whatever works, right? :-)

[starquake]

@gegenschall Totally missed your edit on the new AUR package. Sounds great! Will try it ASAP.

Thanks!

[gregg-miskelly]

Closing this as it should be fixed in upcoming 1.9.

[gregg-miskelly]

If anyone would like to try the private before 1.9 is out, here are instructions --

1. Download csharp-1.9.0-beta2-private.zip
2. Rename the extension from '.zip' to '.vsix'
3. Follow instructions on https://github.com/OmniSharp/omnisharp-vscode/wiki/Installing-Beta-Releases for installing it.