[Snap] .NET Core 3.0 RC1 console app (and webapp) does not work under Linux

[petermcclymont]

I am using .NET Core from a snap package on KUbuntu. I switched to the beta and edge channels to upgrade from .NET Core 2.2 to .NET Core 3.0.

When on beta or edge my console app doesn't work, whereas it was working perfectly under .NET Core 2.2.

I decided to go back to basics. Create a new console app to see what would happen,

mkdir testdotnet
cd testdotnet
dotnet new console
dotnet build
dotnet run

It runs for a second, and gives nothing. No output, whereas I would normally expect,

Hello World!

My actual app does the same thing. Running the app doesn't actually run any code. When I change back to the stable channel, everything works.

Please let me know what additional information you need. I ran this,

dotnet run -v diag

But the output was no different (as far as I could see) between .NET Core 2.2 and .NET Core 3.0, it just shows the build process that was run first. However if that is useful or something similar then let me know.

Something else, I also tried this,

dotnet new webapp
dotnet build
dotnet run

And it does the same. If you want me to run this against a different version of Linux, or a clean version of Linux I can do do.

[danmoseley]

Does "strace" suggest anything?

[petermcclymont]

trace2.log

Thanks. I didn't know that trace was a thing. However this is not the result I expected.

dotnet run - gives nothing

sudo dotnet run - gives nothing

sudo strace -o trace2.log dotnet bin/Debug/netcoreapp2.0/strace-sample2.dll - makes it work!

sudo dotnet run bin/Debug/netcoreapp3.0/strace-sample2.dll - gives nothing

dotnet run bin/Debug/netcoreapp3.0/strace-sample2.dll - gives nothing

Running the trace makes it work, but all options not using the trace don't work. So I assume the trace is going to suggest everything is good? However that trace does mean nothing to me. Take a look and let me know.

Just a little bit of extra information, this time I had a disk space problem with my virtual machine, so I deleted it and started again with a fresh KUbuntu 19.04 install. This is very easy to replicate.

[kevingosse]

Just a little bit of extra information, this time I had a disk space problem with my virtual machine, so I deleted it and started again with a fresh KUbuntu 19.04 install. This is very easy to replicate.

I tried with a clean install of KUbuntu 19.04 on VirtualBox (I chose the minimum installation). Then I installed dotnet-sdk with:

sudo snap install dotnet-sdk --classic --beta
sudo snap alias dotnet-sdk.dotnet dotnet

Then I ran your commands:

mkdir testdotnet
cd testdotnet
dotnet new console
dotnet build
dotnet run

And it displayed "Hello World!" as expected. Is there something you're doing differently?

[kevingosse]

Ok I reproduce it now. I did two things: I updated the system and I rebooted. Not sure which step did the trick.

Interestingly, dotnet run doesn't seem to work, but dotnet ./bin/Debug/netcoreapp3.0/temp.dll works.

[kevingosse]

It's starting to look crazy.

If I create a folder named "1" at the root (/1/) and run dotnet new console then dotnet run, I run into the aforementioned issue.
Same thing from /1/2/
Same thing from /1/2/3/
Then from /1/2/3/4/ or any deeper folder structure, it starts working.
The name of the folders doesn't matter (confirmed by doing the same test with my home profile), it's really just the depth of the folder tree.

I haven't been able to figure out the error yet. I see nothing obvious with strace (well there's 1MB of traces so it's hard to find the relevant parts), and for some reason dotnet run doesn't seem to work at all if I run it from lldb.

[kevingosse]

Taking the dotnet sdk out of the equation, the application seems to crash if less than 7 folders deep

$ /1/2/3/4/5/6/test
Segmentation fault (core dumped)

$ /1/2/3/4/5/6/7/test
Hello World!

Not sure where the segmentation fault comes from, lldb has no symbols for that frame:

(lldb) thread backtrace
* thread dotnet/coreclr#1, name = 'test', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
  * frame #0: 0x0000000000000000
    frame dotnet/coreclr#1: 0x00007ffff7b66704
    frame dotnet/coreclr#2: 0x00007ffff7dd9307 ld-2.27.so`___lldb_unnamed_symbol19$$ld-2.27.so + 7335
    frame dotnet/coreclr#3: 0x00007ffff7defdd0 ld-2.27.so`___lldb_unnamed_symbol110$$ld-2.27.so + 1264
    frame dotnet/coreclr#4: 0x00007ffff7dd7128 ld-2.27.so`___lldb_unnamed_symbol17$$ld-2.27.so + 648
    frame dotnet/coreclr#5: 0x00007ffff7dd6098 ld-2.27.so`___lldb_unnamed_symbol4$$ld-2.27.so + 55

It looks like we're trying to invoke a null pointer somewhere.

Since calling dotnet test.dll works, I think the issue comes from the loader.

Edit: actually, we got there following a retq instruction, so it's more likely that something is wrong with the stack. A method called with the wrong number of parameters?

[petermcclymont]

Thanks. I did not realise there would be a difference between this, which doesn't work,

dotnet run bin/Debug/netcoreapp3.0/strace-sample2.dll

And this which does work,

dotnet bin/Debug/netcoreapp3.0/strace-sample2.dll

At least now there is a work around, I will try again with the beta channel and see if it works with my proper app.

Otherwise when the underlying issue is fixed I am happy to upgrade and give it another go.

[dagood]

/cc @MichaelSimons @leecow, an issue labeled for the snap, however, based on @kevingosse's last comment I would guess it's somehow a host issue in the end (edit: after more info, this is strange, don't know!).

[kevingosse]

/cc @MichaelSimons @leecow, an issue labeled for the snap, however, based on @kevingosse's last comment I would guess it's somehow a host issue in the end.

Well there's two things:

• I couldn't reproduce it when manually downloading the SDK. So it seems to be somehow related to snap
• The issue is in the ELF loader generated during compilation. I'm not sure which part is responsible for that, Roslyn maybe?

[kevingosse]

Might be a dupe of https://github.com/dotnet/cli/issues/12269 and https://github.com/dotnet/core-setup/issues/5186

[kevingosse]

Following the discussion https://github.com/dotnet/core-setup/issues/5186, I tried dumping the RPATH on the ELF loader:

RPATH=$ORIGIN/netcoredeps:$ORIGIN/../../../../../../lib/x86_64-linux-gnu:$ORIGIN/../../../../../../usr/lib/x86_64-linux-gnu:/snap/core18/current/lib/x86_64-linux-gnu

The faulty bit seems to be $ORIGIN/../../../../../../lib/x86_64-linux-gnu.

If $ORIGIN is less than 7 folders deep, then $ORIGIN/../../../../../../ resolves to /, and /lib/x86_64-linux-gnu/libc.so.6 is loaded, resulting in a segfault.
If $ORIGIN is 7 folders deep or more, then $ORIGIN/../../../../../../lib/x86_64-linux-gnu won't be found, so /snap/core18/current/lib/x86_64-linux-gnu/libc.so.6 is loaded, and everything works.

As to know why using /lib/x86_64-linux-gnu/libc.so.6 causes a segfault, that's where my Linux knowledge runs short.

Edit: For what it's worth, /lib/x86_64-linux-gnu/libc.so.6 is glibc 2.29-0ubuntu2, and /snap/core18/current/lib/x86_64-linux-gnu/libc.so.6 is glibc 2.27-3ubuntu1.

When not using the snap version of the SDK, then the RPATH of the output is just $ORIGIN/netcoredeps, and /lib/x86_64-linux-gnu/libc.so.6 is loaded.
Just a guess, could it be that the manually downloaded SDK links the output against /lib/x86_64-linux-gnu/libc.so.6 (and so it works when the same dependency is loaded), but the snap version links against /snap/core18/current/lib/x86_64-linux-gnu/libc.so.6 (so it crashes when /lib/x86_64-linux-gnu/libc.so.6 is loaded instead) ?

[petermcclymont]

Read this,

https://askubuntu.com/questions/1131867/dotnet-command-not-found-after-installing-using-snap

I did add an alias like that to get the command dotnet working,

sudo snap alias dotnet-sdk.dotnet dotnet

But I did try it on a clean installation running without the alias, and it still has the same issue. So it is something about the snap rather than the alias specifically.

[deinok]

Hi, same issue here but with stable release.

Could somebody give me a bit more information on how the dotnet-sdk snap is build? As it seems to be due how it is packed?

[dagood]

@deinok, there are snapcraft files checked in at https://github.com/dotnet/core-setup/tree/master/src/pkg/packaging/snaps. Note that they aren't built by CI or official builds, and they're kept up to date manually. I wouldn't expect the overall strategy to change much between 3.0 builds, however, so there may be some good insights in there.

@leecow would know for sure.

[deinok]

@dagood For what I see, seems like the process is just dump the published precompiled binaries inside the Snap package, so the issue is probably due something regarding snap.

Could you point me on what folder should I apply changes in order to fix the next dotnet-sdk snap release? I supose dotnet-sdk-3

[leecow]

dotnet-sdk is the one to use at the moment. Based on this issue and another related conversation, we'll be re-working the package mix soon (possibly this week).

[petermcclymont]

I wanted to try the latest preview, and it has the same problem,

sudo snap install dotnet-sdk --channel=5.0/beta --classic
sudo snap alias dotnet-sdk.dotnet dotnet
mkdir dotnet
cd dotnet
dotnet new console
dotnet run

Gives nothing. However this works fine,

dotnet bin/Debug/net5.0/dotnet.dll

Going back to dotnet-sdk 3.1.300 and doing the same,

sudo snap install dotnet-sdk --classic
sudo snap alias dotnet-sdk.dotnet dotnet
mkdir dotnet
cd dotnet
dotnet new console
dotnet run

gives me,

*** stack smashing detected ***: terminated

This works,

dotnet bin/Debug/netcoreapp3.1/dotnet.dll

I have switched to Kubuntu 20.04 these days, not that it matters. This appears to be a snap only problem. Grabbing the latest tar.gz from master works fine.

sdk-5.0.100-preview.6.20275.9-linux-x64 - is all good

I recently switched my server to the snap dotnet 3.1 package without thinking about this issue. Everything is running, but I realised it is because I am starting applications like this in a shell script,

dotnet build --configuration Release /home/HomeFolder/dotnet/ProjectName
dotnet run -c Release --project /home/HomeFolder/dotnet/ProjectName

There are some good work arounds for this issue which is the main thing for now.

I have 3 linux machines, so let me know if there is anything I can help with, e.g. testing etc. Or if there are other linux specific issues you want help with.

[ForNeVeR]

FYI, folks, this is still an issue with the latest stable .NET 5 SDK from Snap.

[NikolaMilosavljevic]

[Triage] Closing Snap issues to reflect current priorities.