Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

segfault following debian tutorial #649

Closed
mm-s opened this issue May 11, 2017 · 26 comments
Closed

segfault following debian tutorial #649

mm-s opened this issue May 11, 2017 · 26 comments

Comments

@mm-s
Copy link

mm-s commented May 11, 2017

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
Copy link
Member

leecow commented May 11, 2017

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

@livarcocc
Copy link

@eerhardt

@pinaraf
Copy link

pinaraf commented May 12, 2017

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
Copy link
Member

@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
Copy link
Member

@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
Copy link

pinaraf commented May 13, 2017

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
Copy link

pinaraf commented May 13, 2017

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
Copy link
Member

leecow commented May 13, 2017

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

/cc @richlander @Petermarcu

@bartonjs
Copy link
Member

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

@pinaraf
Copy link

pinaraf commented May 14, 2017

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

@Petermarcu
Copy link
Member

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

@brendandburns
Copy link

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
Copy link
Member

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

@brendandburns
Copy link

$ 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
Copy link

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
Copy link
Member

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

@bartonjs
Copy link
Member

@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
Copy link

xPaw commented Jun 30, 2017

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

@malachib
Copy link

malachib commented Jul 4, 2017

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

@GreenRidingHood
Copy link

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

@AlexBander
Copy link

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

.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
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
Copy link

randomizedthinking commented Sep 14, 2017

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
Copy link

3ronco commented Sep 19, 2017

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
Copy link

@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
Copy link

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

@Lynxy
Copy link

Lynxy commented Nov 14, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests