Core: segfault following debian tutorial

[mm-s]

segfault at step 2 of this tut:

https://www.microsoft.com/net/core/preview#linuxdebian

log:

root@fish# dotnet new console

Welcome to .NET Core!

Learn more about .NET Core @ https://aka.ms/dotnet-docs. Use dotnet --help to see available commands or go to https://aka.ms/dotnet-cli-docs.

Telemetry

The .NET Core tools collect usage data in order to improve your experience. The data is anonymous and does not include command-line arguments. The data is collected by Microsoft and shared with the community.
You can opt out of telemetry by setting a DOTNET_CLI_TELEMETRY_OPTOUT environment variable to 1 using your favorite shell.
You can read more about .NET Core tools telemetry @ https://aka.ms/dotnet-cli-telemetry.

Configuring...

A command is running to initially populate your local package cache, to improve restore speed and enable offline access. This command will take up to a minute to complete and will only happen once.
Decompressing 100% 6845 ms
Expanding 100% 13180 ms
Getting ready...
Segmentation fault
root@fish# dotnet new console -o hwapp
Getting ready...
Segmentation fault

[leecow]

Hi @mm-s - which version of Debian so I can give it a go?

[livarcocc]

@eerhardt

[pinaraf]

I've got the same problem on my computers running Debian sid, and I can not get it running on Debian testing (stretch) because it requires OpenSSL 1.0.0 that is no longer packaged.

[eerhardt]

@bartonjs let me know that we have an issue to support OpenSSL 1.1, but .NET Core 2.0 doesn't support it yet. Debian 9 comes with OpenSSL 1.1, which we don't support.

@leecow @Petermarcu @richlander - our supported versions roadmap says that .NET Core 2.0 supports Debian 8.7+. Is the intention that we support Debian 9 with .NET Core 2.0?

[bartonjs]

@pinaraf The back-compat package seems to be called libssl1.0.2: https://packages.debian.org/stretch/libssl1.0.2. If you install that, do things start working?

[pinaraf]

I removed on my sid the old unmaintained libssl 1.0.0 package, and now I get the error message No usable version of the libssl was found. At least that's not a segfault.
A strace shows that only libssl.so.1.0.0 is searched, with a fallback on libssl.so.10, while the libssl1.0.2 package provides only libssl.so.1.0.2.
I tried to put a symlink, but the symbols changed in libssl 1.0.2 (SSLv3_method missing). That's why Debian did not simply upgrade the previous package and kept my old version installed: the OpenSSL package broke the binary compatibility…
So right now, .NET Core 2.0 may work on Debian 8.(7+), not on Debian 8.7+
Considering that Debian 9 will be out in the next months, supporting it is imho important. And it will come with OpenSSL 1.0.2 as a fallback so you should be able to use it.
https://packages.debian.org/search?keywords=libssl&searchon=names&suite=testing&section=all

[pinaraf]

So, basically, for Debian 9+ corefx must be compiled with OPENSSL_NO_SSL3_METHOD defined…
This was changed in OpenSSL 1.0.2d-2 package back in 2015.

[leecow]

@eerhardt Yes, it's my understanding that Debian 9 will be supported by 2.0.

/cc @richlander @Petermarcu

[bartonjs]

@pinaraf Ah, yeah, I thought that sounded familiar... we fixed it two weeks ago: https://github.com/dotnet/corefx/pull/19070. The latest daily builds should work on Debian 9.

[pinaraf]

@bartonjs And I confirm the latest builds work on Debian 9 with OpenSSL 1.0.2.

[Petermarcu]

closing this because it looks like we've solved the issue.

[brendandburns]

fwiw, I still see this on:

$ dotnet --version
2.1.0-preview1-006491

$ dotnet restore
Segmentation fault

Latest debian stretch (now the stable release)

[eerhardt]

@brendandburns - did you install libssl1.0.2 that @bartonjs recommends above?

[brendandburns]

$ sudo apt-get install libssl1.0.2
[sudo] password for bburns: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
libssl1.0.2 is already the newest version (1.0.2l-2).
0 upgraded, 0 newly installed, 0 to remove and 17 not upgraded.

It appears to be the right version. Happy to help with further debugging, let me know what you need me to do.

[brendandburns]

Ah, I dug around a little more. I had a stray /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 sitting around on my system (Jessie to Stretch upgrade)

Not sure why that was there, but moving it out of the way (adding .old) fixed things.

Thanks.

[Petermarcu]

Great to hear you found it @Bartonjs should we open an issue to see if we can be more resilient here?

[bartonjs]

@Petermarcu If it's badly pervasive, maybe? libcrypto.so.1.0.0 (and libssl.so.1.0.0) is the name recommended by OpenSSL. Debian is deviating from that recommendation and naming it libcrypto.so.1.0.2. Preferring Debian's name above OpenSSL's recommended name on Ubuntu seems weird.

Though, I guess that we could assert that libcrypto and libssl need the same SONAME version fragment and we load them locked, or not at all. @janvorli, thoughts? (I'm assuming that there was an aberrant libssl.so.1.0.0, but not also an aberrant libcrypto.so.1.0.0)

[xPaw]

@brendandburns Oh wow, thanks for the solution! I was hitting segfaults with latest preview on Debian 9, and this fixed it.

[malachib]

Experienced this issue, but pulling down the newest (preview 2 2.0 SDK) seems to fix it nicely

[GreenRidingHood]

I had the same problem, and solution for me was
adding dotnet before "-o hwapp" (dotnet -o hwapp)
and now working

[AlexBander]

I have the same problem.
logically as dotnet -o hwapp dont work -> Unknown option: -o.

it dont work on default settings

dotnet new Wird vorbereitet... Speicherzugriffsfehler

```dotnet --info
.NET-Befehlszeilentools (2.0.0)

Product Information:
Version: 2.0.0
Commit SHA-1 hash: cdcd1928c9

Runtime Environment:
OS Name: debian
OS Version: 9
OS Platform: Linux
RID: linux-x64
Base Path: /usr/share/dotnet/sdk/2.0.0/

Microsoft .NET Core Shared Framework Host

Version : 2.0.0
Build : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d

```lsb_release -da
Distributor ID: Debian
Description:    Debian GNU/Linux 9.1 (stretch)
Release:        9.1
Codename:       stretch

Statusinformationen werden eingelesen.... Fertig
libssl1.0.2 ist schon die neueste Version (1.0.2l-2).

[randomizedthinking]

Just encountered the same issue on debian stretch while following the instruction on https://www.microsoft.com/net/core#linuxdebian. Also, libssl.1.0.2 are installed as suggested, but it does not solve the problem.

[3ronco]

Same here, segfault on Debian Stretch when using
dotnet new ...
Temporary fix:
export DOTNET_CLI_TELEMETRY_OPTOUT=1
Although not nice to disable telemetry but works for now link

[thetravis]

@brendandburns The reason I had libssl.so.1.0.0 seem to be that spotify-client requires that version. Checked apt-cache showpkg libssl1.0.0 and I got

  Reverse Depends: 
  librhash0,libssl1.0.0 1.0.0
  spotify-client-0.9.17,libssl1.0.0
  spotify-client,libssl1.0.0
  rhash,libssl1.0.0 1.0.0

I have no rhash installed so no other program than Spotify should need it on my install. I moved the /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 library to Spotify folder under my home folder and ran Spotify with

export LD_LIBRARY_PATH=/home/heikki/Spotify && spotify

and it works. Now dotnet restore and dotnet run seem to work too.

[willvitorino]

I just wrote
export DOTNET_CLI_TELEMETRY_OPTOUT = 1
in my .bashrc, and it has worked. Thank you guys.

[Lynxy]

Thanks @willvitorino, I was able to solve my seg fault error, 3 years later! As strange as it sounds, opting out of telemetry stopped the crashes.
echo 'export DOTNET_CLI_TELEMETRY_OPTOUT=1' > /root/.bashrc