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

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 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 https://github.com/OmniSharp/omnisharp-vscode/issues/564#issuecomment-285960000 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”

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 3
  • Comments: 30 (9 by maintainers)

Commits related to this issue

Most upvoted comments

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

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!

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…

Closing this as it should be fixed in upcoming 1.9.

@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? 😃

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…