Segmentation Fault when using dotnet 5.0 from snap

[briguyjm]

I just installed dotnet sdk 5.0 using snap on Ubuntu 20.10. When creating a simple Hello World and running dotnet test, nothing happens. Running dotnet build builds my Hello World just fine, but dotnet run does nothing. Running the binary directly in the bin/ directory results in a Segmentation Fault.

brian@brian-pc:~/hello$ dotnet build
Microsoft (R) Build Engine version 16.8.0+126527ff1 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  All projects are up-to-date for restore.
  hello -> /home/brian/hello/bin/Debug/net5.0/hello.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:00.74
brian@brian-pc:~/hello$ dotnet run
brian@brian-pc:~/hello$ cd bin/Debug/net5.0/
brian@brian-pc:~/hello/bin/Debug/net5.0$ ./hello 
Segmentation fault (core dumped)

This is my Program.cs

using System;

namespace hello
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello World!");
        }
    }
}

System info:

lsb_release -cr
Release:	20.10
Codename:	groovy

dotnet --version
5.0.101

uname -r
5.8.0-7630-generic

[kjholzapfel]

I am having exactly the same issue, installed dotnet with snap.

System:  Kernel: 5.10.16-1-default x86_64 bits: 64 Desktop: KDE Plasma 5.21.0  Distro: openSUSE Tumbleweed 20210222 

dotnet --version
5.0.103

snap list
Name        Version              Rev    Tracking       Publisher      Notes
dotnet-sdk  5.0.103              112    latest/stable  dotnetcore✓    classic

I've tried to debug the issue, but I am inexperienced with it:

/snap/dotnet-sdk/current # lldb dotnet
(lldb) target create "dotnet"
Current executable set to '/snap/dotnet-sdk/current/dotnet' (x86_64).
(lldb) process launch -program_arg build
Process 26812 launched: '/snap/dotnet-sdk/current/dotnet' (x86_64)
Process 26812 stopped
* thread dotnet/sdk#11, name = '.NET ThreadPool', stop reason = signal SIGSEGV: invalid address (fault address: 0x1a0)
    frame #0: 0x00007ffff7ddfc78 ld-2.27.so`___lldb_unnamed_symbol42$$ld-2.27.so + 888
ld-2.27.so`___lldb_unnamed_symbol42$$ld-2.27.so:
->  0x7ffff7ddfc78 <+888>: movl   0x8(%r8), %esi
    0x7ffff7ddfc7c <+892>: movl   $0x0, %eax
    0x7ffff7ddfc81 <+897>: testl  %esi, %esi
    0x7ffff7ddfc83 <+899>: cmoveq %rax, %r8

[danmoseley]

@janvorli should this get transferred to runtime repo - the VM area?

[ghost]

Hope this issue been resolved, I am ubuntu linux user, thanks. and love dotnet and fsharp.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[mangod9]

Hi @kouvel, believe you had done some investigation for snap -- does this issue still exist in 6?

[kouvel]

This seems to be the same issue as described in detail in #3775 (comment). Snap's dotnet seems to be targeting and should be running under the core18 base snap but it's ending up loading libs from system paths instead of from the base snap paths due to the RPATH issue.

Modifying the RPATH or just putting the app one folder deeper seems to resolve the issue when running the app directly from the build folder. Same issue with dotnet run as well it seems. dotnet bin/Debug/net5.0/hello.dll seems to work without any issues.

[NikolaMilosavljevic]

[Triage] Closing Snap issues to reflect current priorities.