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
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
- Improve dependancy handling / Linux distro handling https://github.com/OmniSharp/omnisharp-vscode/issues/1361 https://github.com/OmniSharp/omnisharp-vscode/issues/1323 Changes: 1. Add a setting to c... — committed to gregg-miskelly/vscode-csharp by gregg-miskelly 7 years ago
- Improve dependancy handling / Linux distro handling (#1371) * Improve dependancy handling / Linux distro handling https://github.com/OmniSharp/omnisharp-vscode/issues/1361 https://github.com/Omni... — committed to dotnet/vscode-csharp by gregg-miskelly 7 years ago
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.
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: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 thedotnet
dependency ofvscode-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 thedotnet
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 aln -s /opt/dotnet/debugger ~/.vscode/extensions/ms-vscode.csharp-1.?.?/.debugger
. Should be working just fine…