preview8 - signal SIGSEGV on executables

[thild]

preview8 - signal SIGSEGV on executables

Create a console app "console1" and run with dotnet run
Nothing happens. Program just exits silently.

The program builds normally.
dotnet bin/Debug/netcoreapp3.0/console1.dll works.
./bin/Debug/netcoreapp3.0/console1 crashes with segmentation fault.

General

$ lldb console1
(lldb) target create "console1"
Current executable set to 'console1' (x86_64).
(lldb) run
Process 26817 launched: '/mnt/docs/dev/tmp/console1/bin/Debug/netcoreapp3.0/console1' (x86_64)
Process 26817 stopped
* thread dotnet/sdk#4283, name = 'console1', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
    frame #0: 0x0000000000000000
error: memory read failed for 0x0

$ dotnet --info
SDK do .NET Core (refletindo qualquer global.json):
 Version:   3.0.100-preview8-013656
 Commit:    8bf06ffc8d

Ambiente de tempo de execução:
 OS Name:     opensuse-tumbleweed
 OS Version:  20190721
 OS Platform: Linux
 RID:         linux-x64
 Base Path:   /snap/dotnet-sdk/45/sdk/3.0.100-preview8-013656/

Host (useful for support):
  Version: 3.0.0-preview8-28405-07
  Commit:  d01b2fb7bc

.NET Core SDKs installed:
  3.0.100-preview8-013656 [/snap/dotnet-sdk/45/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.App 3.0.0-preview8.19405.7 [/snap/dotnet-sdk/45/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.0.0-preview8-28405-07 [/snap/dotnet-sdk/45/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

[peterhuene]

Attempting to reproduce.

[peterhuene]

I was unable to reproduce with the generic Linux x64 tar.gz on opensuse-tumbleweed. I could build and run with dotnet run as well as executing the produced apphost directly.

However, I was able to reproduce with the .NET Core SDK installed via snap.

@leecow are there known issues in this area with snap installed .NET Core SDKs?

I'll try to see if I can capture a meaningful backtrace.

[peterhuene]

It looks like this may be a dupe of dotnet/core-setup#5186.

[peterhuene]

This is a dupe of the core-setup issue. The problem is the that the apphost can't resolve its dependencies because its RPATH isn't correct to resolve them in the snap's directory.

I was able to get the apphost working with this workaround:

$ patchelf --set-rpath '$ORIGIN/netcoredeps:/snap/dotnet-sdk/current/lib/x86_64-linux-gnu:/snap/dotnet-sdk/current/usr/lib/x86_64-linux-gnu' bin/Debug/netcoreapp3.0/console1

Edit bin/Debug/netcore3.0/console1.runtimeoptions.json to include this in the runtimeOptions settings:

"configProperties": {
    "System.Globalization.Invariant": true
}

And then finally run with DOTNET_ROOT set:

$ DOTNET_ROOT=/snap/dotnet-sdk/current bin/Debug/netcoreapp3.0/console1

Another workaround is to disable building with the apphost by setting <UseAppHost>false</UseAppHost> in the project file. This will prevent the apphost from being created, so dotnet run will work. However, to run the application manually you must use dotnet application.dll to activate.

I'm going to close this issue in favor of the dotnet/core-setup issue referenced above.

@thild thanks for reporting this to us!

[thild]

patchelf and DOTNET_ROOT do the job. No need to set configProperties in my case.

Just an obs.: this issue doesn't happen in preview7.

Thanks for the workaround. All I needed was patchelf as well. Globalization setting was not needed and I didn't have to define my project path in DOTNET_ROOT

Because this information is scattered all over the place, here is my complete solution to get the dotnet core snap fully up and running (on Solus) if it helps anyone:

• Install dotnet core snap
• Make dotnet alias: sudo snap alias dotnet-sdk.dotnet dotnet
• .bashrc:

export DOTNET_ROOT=/snap/dotnet-sdk/current
export MSBuildSDKsPath="${DOTNET_ROOT}/sdk/$(dotnet --version)/Sdks"
export PATH="${PATH}:${DOTNET_ROOT}"
export PATH="${PATH}:$(realpath ~/.dotnet/tools)"

To resolve some certificate errors with nuget packages, I also needed:

export SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt
export SSL_CERT_DIR=/dev/null

• Fix RPATH as mentioned above

cd ~/source/my-project
patchelf --set-rpath '$ORIGIN/netcoredeps:/snap/dotnet-sdk/current/lib/x86_64-linux-gnu:/snap/dotnet-sdk/current/usr/lib/x86_64-linux-gnu' bin/Debug/netcoreapp3.0/my-project

• Lastly, if Mono is installed on the system, a fix for Omnisharp is needed in /my-project/.vscode/settings.json. More info at OmniSharp stops working after Mono is installed. vscode-csharp#1998

{
    "omnisharp.path": "latest",
    "omnisharp.useGlobalMono": "never"
 }