runtime: dotnet restore segfaults on Debian 9.0/stretch Testing

I have some more information.

Looking at a standard install of 1.0.x + 1.1.x runtime and 2.0 preview 2 runtime+sdk I can find only 3 .so objects that depend on libssl:

shared/Microsoft.NETCore.App/1.0.5/System.Security.Cryptography.Native.so on 1.0.0 shared/Microsoft.NETCore.App/1.1.2/System.Security.Cryptography.Native.OpenSsl.so on 1.0.0 shared/Microsoft.NETCore.App/2.0.0-preview2-25407-01/System.Net.Http.Native.so on 1.0.0 for Debian 8 shared/Microsoft.NETCore.App/2.0.0-preview2-25407-01/System.Net.Http.Native.so on 1.0.2 for Debian 9

Note that the dependencies where found using ldd but objdump doesn’t show any explicit dependency on libssl. I suppose there is some kind of runtime check and that’s why 2.0 preview 2 shows different dependencies on different Debian versions. (My fault. ldd just shows the full dependency tree and obviously the tree is different on Debian 8 and 9.)

This means that older frameworks won’t run on Debian 9 because of missing shared libraries (is this a problem?) Trying to compile and run a netcoreapp1.1 console application on Debian 9 yields:

$ dotnet run -f netcoreapp1.1
Failed to initialize CoreCLR, HRESULT: 0x80131500

Here’s a little summary:

.NET Core 1.0.x

• Runs on Debian 8
• Doesn’t run on Debian 9 unless libssl1.0.0 is installed from oldstable (but this breaks 2.0 preview 2)

.NET Core 1.1.x

• Runs on Debian 8
• Doesn’t run on Debian 9 unless libssl1.0.0 is installed from oldstable (but this breaks 2.0 preview 2)

.NET Core 2.0 preview 2

• Runs on Debian 8
• Runs on Debian 9, when installed from scratch
• Runs on Debian 9 when upgraded from Debian 8 only if libssl1.0.0 is removed from the system

I just did some extensive tests using a clean Debian 9 docker image. On a clean install, adding curl and libcurl 7.52.1-5 is not a problem, everything works well. The problem pops up when upgrading an old Debian to version 9 or when using the Ubuntu .deb packages on Debian 9. In both cases libssl1.0.0 gets pulled in and BOOM, segfault. Note that this is NOT libssl1.0.2, the Debian 9 default but an older library with a different soname. Apparently dotnet tries to load any available libssl at runtime and when both libcurl 7.52.1-5 (that pulls libssl1.0.2) and libssl1.0.0 are present it chooses to load the older one resulting in a segfault.

TL;DR: don’t use Ubuntu packages on Debian 9 and remove libssl1.0.0 after upgrading from an older Debian to the latest stable.

I had this issue on debian stretch, gdb showed a segfault in /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0.

dpkg -S /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 showed that libssl1.0.0 was the installed package. Apparently this is due to not removing obsolete packages such as php5-cli and postgresql-9.4.

After sudo apt remove libssl1.0.0 (and the obsolete packages) it works!

Yet another bump to this, preview2 doesn’t work OOB and depends on oldstable libcurl. Can we do anything with that? Stretch went stable a while ago and not supporting it without workarounds feel wrong.

@fogzot Oh it actually worked ! I used Jessie’s version of libcurl 3 and I managed to create, restore and run the app !

I don’t really understand why but I won’t complain !

Any way to make a wiki or something to explain all steps needed to be able to use .NET Core on Debian Stretch ? I had to look several issues to know I had to download several packages and so on.

Thanks !

EDIT : I created a markdown file here to explain the step to follow to make it work on Stretch. I tried on a brand new Stretch VM and it works great.

Isn’t this the usual problem with libcurl? Just downgrade curl and libcurl3 to version 7.38.0-4+deb8u5 and the last tarball works correctly on Stretch.

@nmschulte Yes. Sorry, I didn’t explain myself too well. I just wanted to emphasize that everything runs OK on Jessie as long as you don’t upgrade the kernel, else everything breaks on Jessie too.

@ellismg who can help here?