dotnet restore fails on Linux 4.6.2 #6502

andyleejordan · 2016-06-23T01:01:31Z

Steps to reproduce

CentOS 7 with kernel-ml installed, the mainline Linux kernel at version 4.6.2.

./dotnet-install.sh -c preview -v 1.0.0-preview2-003121
~/.dotnet/dotnet restore

Expected behavior

Packages to be restored.

Actual behavior

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 commandline 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% 2175 ms
Expanding 3%Segmentation fault (core dumped)

Environment data

dotnet --info output:

dotnet --info
.NET Command Line Tools (1.0.0-preview2-003121)

Product Information:
 Version:            1.0.0-preview2-003121
 Commit SHA-1 hash:  1e9d529bc5

Runtime Environment:
 OS Name:     centos
 OS Version:  7
 OS Platform: Linux
 RID:         centos.7-x64

This is a fresh CentOS 7 machine I made to replace the Debian Testing machine I couldn't build on in #6483.

The text was updated successfully, but these errors were encountered:

andyleejordan · 2016-06-23T01:04:03Z

This behavior reproduced even with versions of dotnet (specifically 1.0.0-preview2-003119) I knew to be good on other CentOS 7 machines (where I was building fine just last week).

This does not appear to be the same as #6500.

andyleejordan · 2016-06-23T01:04:41Z

The backtrace in GDB was not useful to me:

#0  0x00007ffff79c66d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
dotnet/sdk#4283  0x00007ffff64911b2 in CorUnix::CPalSynchronizationManager::ThreadNativeWait(CorUnix::_ThreadNativeWaitData*, unsigned int, CorUnix::ThreadWakeupReason*, unsigned int*) ()
   from /home/andrew/.dotnet/shared/Microsoft.NETCore.App/1.0.0/libcoreclr.so
dotnet/sdk#4284  0x00007ffff6490df4 in CorUnix::CPalSynchronizationManager::BlockThread(CorUnix::CPalThread*, unsigned int, bool, bool, CorUnix::ThreadWakeupReason*, unsigned int*) ()
   from /home/andrew/.dotnet/shared/Microsoft.NETCore.App/1.0.0/libcoreclr.so
dotnet/sdk#4285  0x00007ffff6495b81 in CorUnix::InternalWaitForMultipleObjectsEx(CorUnix::CPalThread*, unsigned int, void* const*, int, unsigned int, int) () from /home/andrew/.dotnet/shared/Microsoft.NETCore.App/1.0.0/libcoreclr.so
dotnet/sdk#4286  0x00007ffff6495da2 in WaitForSingleObjectEx ()
   from /home/andrew/.dotnet/shared/Microsoft.NETCore.App/1.0.0/libcoreclr.so
dotnet/cli#5  0x00007ffff61eded2 in CLREventBase::WaitEx(unsigned int, WaitMode, PendingSync*) ()
   from /home/andrew/.dotnet/shared/Microsoft.NETCore.App/1.0.0/libcoreclr.so

eerhardt · 2016-06-23T04:10:45Z

/cc @piotrpMSFT @livarcocc @ericstj

It sounds like you probably don't have a required prerequisite on the machine, but I would have no idea which one... I'm not even sure of the list of required prereqs on CentOS.

andyleejordan · 2016-06-23T04:17:48Z

As part of the prereqs I've previously identified for CentOS, I have installed:

curl make gcc-c++ cmake glibc libgcc libstdc++ libcurl krb5-libs libicu lldb openssl-libs libunwind libuuid zlib clang

This was after taking the package dependencies from the old Ubuntu dotnet packages (host, sdk, and tool), and finding the corresponding CentOS packages.

eerhardt · 2016-06-23T04:19:31Z

Can you check all the config that happens in https://github.com/dotnet/cli/blob/rel/1.0.0/scripts/docker/centos/Dockerfile? That sets up our centos docker images for our CI.

eerhardt · 2016-06-23T04:21:27Z

Obviously you shouldn't need 'make' or any C++ compiler, those are needed for building the CLI and Shared Framework code itself.

andyleejordan · 2016-06-23T04:23:24Z

Checked the prereqs, already have them all. Really don't think I need the clang, lldb, and llvm packages.

$ sudo yum install unzip libunwind gettext libcurl-devel openssl-devel zlib libicu-devel
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirrors.syringanetworks.net
 * elrepo: ftp.osuosl.org
 * epel: mirrors.cat.pdx.edu
 * extras: mirrors.xmission.com
 * updates: mirrors.cat.pdx.edu
Package unzip-6.0-15.el7.x86_64 already installed and latest version
Package 2:libunwind-1.1-5.el7_2.2.x86_64 already installed and latest version
Package gettext-0.18.2.1-4.el7.x86_64 already installed and latest version
Package libcurl-devel-7.29.0-25.el7.centos.x86_64 already installed and latest version
Package 1:openssl-devel-1.0.1e-51.el7_2.5.x86_64 already installed and latest version
Package zlib-1.2.7-15.el7.x86_64 already installed and latest version
Package libicu-devel-50.1.2-15.el7.x86_64 already installed and latest version
Nothing to do

andyleejordan · 2016-06-23T04:27:10Z

@piotrpMSFT said they'd recently identified and fixed some compression library problems in CoreFX.

eerhardt · 2016-06-23T04:34:17Z

The version you are using is the build of .NET Core 1.0.0 RTM and the SDK Preview2 that is going to be released next week. These should be the "golden bits".

Just to ensure everything is right: where did you get dotnet-install from? Above you are using ./ to invoke it. Is it old/out of date somehow? Can you ensure you are using this version: https://github.com/dotnet/cli/blob/rel/1.0.0-preview2/scripts/obtain/dotnet-install.sh

andyleejordan · 2016-06-23T04:35:57Z

@eerhardt yes I downloaded it today, let me re-download it and test.

andyleejordan · 2016-06-23T04:38:38Z

Deleted ~/.dotnet, re-downloaded install script, it downloaded the same 1.0.0-preview2-003121.tar.gz, still segfaults when expanding the initial cache.

(We have these steps automated for our CI, they should definitely be right, but I re-ran them by hand to be sure.)

andyleejordan · 2016-06-23T04:40:17Z

Here's the last bit of the strace before it crashes:

open("/home/andrew/.dotnet/sdk/1.0.0-preview2-003121/NuGet.RuntimeModel.dll", O_RDONLY) = 81
flock(81, LOCK_SH|LOCK_NB)              = 0
fcntl(81, F_SETFD, FD_CLOEXEC)          = 0
lseek(81, 0, SEEK_SET)                  = 0
read(81, "MZ\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 64) = 64
lseek(81, 128, SEEK_SET)                = 128
read(81, "PE\0\0\35\375\3\0\301\37_W\0\0\0\0\0\0\0\0\360\0\" \v\2\v\0\0\0\0\0"..., 264) = 264
mmap(0x7f0ded06c000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED, 81, 0) = 0x7f0ded06c000
mmap(0x7f0ded06d000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 81, 0x1000) = 0x7f0ded06d000
mmap(0x7f0ded06e000, 57344, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 81, 0x2000) = 0x7f0ded06e000
mmap(0x7f0ded07c000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED, 81, 0x10000) = 0x7f0ded07c000
mprotect(0x7f0ded046000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0x7f0ded05d000, 4096, PROT_READ|PROT_WRITE) = 0
mmap(NULL, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e66f54000
mprotect(0x7f0e66f54000, 65536, PROT_READ|PROT_WRITE) = 0
mprotect(0x7f0dec0c0000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0x7f0dec0c0000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
munmap(0x7f0e66f54000, 65536)           = 0
mprotect(0x7f0ded047000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0x7f0ded048000, 4096, PROT_READ|PROT_WRITE) = 0
mmap(NULL, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e66f54000
mprotect(0x7f0e66f54000, 65536, PROT_READ|PROT_WRITE) = 0
mmap(NULL, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e5d4c1000
mprotect(0x7f0e5d4c1000, 65536, PROT_READ|PROT_WRITE) = 0
mmap(NULL, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e5d4b1000
mprotect(0x7f0e5d4b1000, 65536, PROT_READ|PROT_WRITE) = 0
mmap(NULL, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e5d4a1000
mprotect(0x7f0e5d4a1000, 65536, PROT_READ|PROT_WRITE) = 0
mmap(NULL, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e5d491000
mprotect(0x7f0e5d491000, 65536, PROT_READ|PROT_WRITE) = 0
munmap(0x7f0e66f54000, 65536)           = 0
munmap(0x7f0e5d4c1000, 65536)           = 0
munmap(0x7f0e5d4b1000, 65536)           = 0
munmap(0x7f0e5d4a1000, 65536)           = 0
munmap(0x7f0e5d491000, 65536)           = 0
mprotect(0x7f0ded05e000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0x7f0ded049000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0x7f0ded04a000, 4096, PROT_READ|PROT_WRITE) = 0
mmap(NULL, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e66f54000
mprotect(0x7f0e66f54000, 65536, PROT_READ|PROT_WRITE) = 0
munmap(0x7f0e66f54000, 65536)           = 0
mprotect(0x7f0ded04b000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0x7f0dec0c1000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0x7f0dec0c1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mmap(NULL, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e66f54000
mprotect(0x7f0e66f54000, 65536, PROT_READ|PROT_WRITE) = 0
munmap(0x7f0e66f54000, 65536)           = 0
mprotect(0x7f0ded04c000, 4096, PROT_READ|PROT_WRITE) = 0
mmap(NULL, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e66f54000
mprotect(0x7f0e66f54000, 65536, PROT_READ|PROT_WRITE) = 0
mmap(NULL, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e5d4c1000
mprotect(0x7f0e5d4c1000, 65536, PROT_READ|PROT_WRITE) = 0
mmap(NULL, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e5d4b1000
mprotect(0x7f0e5d4b1000, 65536, PROT_READ|PROT_WRITE) = 0
mprotect(0x7f0ded05f000, 4096, PROT_READ|PROT_WRITE) = 0
mmap(NULL, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e5d4a1000
mprotect(0x7f0e5d4a1000, 65536, PROT_READ|PROT_WRITE) = 0
munmap(0x7f0e66f54000, 65536)           = 0
munmap(0x7f0e5d4c1000, 65536)           = 0
munmap(0x7f0e5d4b1000, 65536)           = 0
munmap(0x7f0e5d4a1000, 65536)           = 0
mprotect(0x7f0ded07d000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0x7f0ded07d000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mprotect(0x7f0ded060000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0x7f0ded04d000, 4096, PROT_READ|PROT_WRITE) = 0
flock(75, LOCK_UN)                      = 0
close(75)                               = 0
mprotect(0x7f0ded04e000, 4096, PROT_READ|PROT_WRITE) = 0
mmap(NULL, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e66f54000
mprotect(0x7f0e66f54000, 65536, PROT_READ|PROT_WRITE) = 0
mmap(NULL, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e5d4c1000
mprotect(0x7f0e5d4c1000, 65536, PROT_READ|PROT_WRITE) = 0
munmap(0x7f0e66f54000, 65536)           = 0
munmap(0x7f0e5d4c1000, 65536)           = 0
mprotect(0x7f0ded04f000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0x7f0ded061000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0x7f0ded050000, 4096, PROT_READ|PROT_WRITE) = 0
futex(0x7f0db4002f64, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7f0db4002f60, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x7f0db4002f38, FUTEX_WAKE_PRIVATE, 1) = 1
mmap(NULL, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e66f54000
mprotect(0x7f0e66f54000, 65536, PROT_READ|PROT_WRITE) = 0
futex(0x7f0e659c9c54, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7f0e659c9c50, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x7f0e659c9c28, FUTEX_WAKE_PRIVATE, 1) = 1
mprotect(0x7f0ded066000, 4096, PROT_READ|PROT_WRITE) = 0
futex(0x16c78cc, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x16c78c8, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x16c78a0, FUTEX_WAKE_PRIVATE, 1) = 1
munmap(0x7f0e66f54000, 65536)           = 0
futex(0x16b242c, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EAGAIN (Resource temporarily unavailable)
futex(0x16b2400, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x1826cf4, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EAGAIN (Resource temporarily unavailable)
futex(0x1826cc8, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x1826bc4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x1826bc0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x1826b98, FUTEX_WAKE_PRIVATE, 1) = 1
mprotect(0x7f0ded0da000, 4096, PROT_READ|PROT_WRITE) = 0
futex(0x7f0e659c9c54, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7f0e659c9c50, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x7f0e659c9c28, FUTEX_WAKE_PRIVATE, 1) = 1
mmap(NULL, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e5d4c1000
mprotect(0x7f0e5d4c1000, 65536, PROT_READ|PROT_WRITE) = 0
futex(0x7f0e659c9c54, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7f0e659c9c50, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x7f0e659c9c28, FUTEX_WAKE_PRIVATE, 1) = 1
mmap(NULL, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e66f54000
mprotect(0x7f0e66f54000, 65536, PROT_READ|PROT_WRITE) = 0
futex(0x7f0e659c9c54, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7f0e659c9c50, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x7f0e659c9c28, FUTEX_WAKE_PRIVATE, 1) = 1
mmap(NULL, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e5d4b1000
mprotect(0x7f0e5d4b1000, 65536, PROT_READ|PROT_WRITE) = 0
futex(0x7f0e659c9c54, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7f0e659c9c50, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x7f0e659c9c28, FUTEX_WAKE_PRIVATE, 1) = 1
munmap(0x7f0e5d4c1000, 65536)           = 0
futex(0x7f0e659c9c54, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7f0e659c9c50, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x7f0e659c9c28, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f0e659c9c54, FUTEX_WAIT_PRIVATE, 13, NULL) = -1 EAGAIN (Resource temporarily unavailable)
futex(0x7f0e659c9c28, FUTEX_WAKE_PRIVATE, 1) = 0
munmap(0x7f0e66f54000, 65536)           = 0
munmap(0x7f0e5d4b1000, 65536)           = 0
futex(0x7f0e659c9c54, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7f0e659c9c50, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x7f0e659c9c28, FUTEX_WAKE_PRIVATE, 1) = 1
mprotect(0x7f0deb56b000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0x7f0deb56b000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
futex(0x7f0e659c9c54, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7f0e659c9c50, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x7f0e659c9c28, FUTEX_WAKE_PRIVATE, 1) = 1
mmap(NULL, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e5d4c1000
mprotect(0x7f0e5d4c1000, 65536, PROT_READ|PROT_WRITE) = 0
futex(0x7f0e659c9c54, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7f0e659c9c50, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x7f0e659c9c28, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f0e659c9c54, FUTEX_WAIT_PRIVATE, 21, NULL) = -1 EAGAIN (Resource temporarily unavailable)
futex(0x7f0e659c9c28, FUTEX_WAKE_PRIVATE, 1) = 0
mmap(NULL, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e66f54000
mprotect(0x7f0e66f54000, 65536, PROT_READ|PROT_WRITE) = 0
futex(0x7f0e659c9c54, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7f0e659c9c50, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x7f0e659c9c28, FUTEX_WAKE_PRIVATE, 1) = 1
munmap(0x7f0e5d4c1000, 65536)           = 0
futex(0x7f0e659c9c54, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7f0e659c9c50, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x7f0e659c9c28, FUTEX_WAKE_PRIVATE, 1) = 1
munmap(0x7f0e66f54000, 65536)           = 0
mmap(NULL, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e5d4b1000
mprotect(0x7f0e5d4b1000, 65536, PROT_READ|PROT_WRITE) = 0
futex(0x7f0e659c9c54, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7f0e659c9c50, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x7f0e659c9c28, FUTEX_WAKE_PRIVATE, 1) = 1
mmap(NULL, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0e5d4c1000
mprotect(0x7f0e5d4c1000, 65536, PROT_READ|PROT_WRITE) = 0
futex(0x7f0e659c9c54, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7f0e659c9c50, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x7f0e659c9c28, FUTEX_WAKE_PRIVATE, 1) = 1
munmap(0x7f0e5d4b1000, 65536)           = 0
futex(0x7f0e659c9c54, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7f0e659c9c50, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x7f0e659c9c28, FUTEX_WAKE_PRIVATE, 1) = 1
munmap(0x7f0e5d4c1000, 65536)           = 0
sched_yield()                           = 0
futex(0x169eab4, FUTEX_WAIT_PRIVATE, 113, NULL) = ? <unavailable>
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault (core dumped)

andyleejordan · 2016-06-23T15:55:57Z

I found it:

This segmentation fault occurs when running with the mainline kernel, 4.6.2, but not with 3.10.0 (CentOS 7's default).

Now why decompression fails on an up-to-date kernel is beyond me, but I'll change this name of this issue.

eerhardt · 2016-06-23T15:58:13Z

Awesome! Thanks for tracking it down, @andschwa. Adding some CoreCLR and CoreFX folks who may have a better idea of the issue on an updated CentOS kernel.

/cc @gkhanna79 @ellismg @sergiy-k @jkotas @janvorli

andyleejordan · 2016-06-23T18:09:09Z

Hey wouldn't you know it: I can reproduce this on Ubuntu 14.04 with the 4.6.2 image from kernel.ubuntu.com. At least it's consistent!

This also tells me that it doesn't repro on 4.2.0 either.

ghost · 2016-06-23T19:05:09Z

@andschwa, do you have similar symptoms with updated kernel as http://unix.stackexchange.com/q/253903? Then these might be related:

Answer: http://unix.stackexchange.com/a/255603
Announcement: https://github.com/systemd/systemd/blob/master/NEWS#L60
PR: systemd/systemd#1239

andyleejordan · 2016-06-24T03:16:56Z

I'm not seeing the same errors as the Stack Exchange question. I have this in dmesg when it crashes:

[   85.928175] traps: dotnet[3374] general protection ip:7f51d0f5f815 sp:7f51a9ff81e0 error:0

I've ruled out the Hypervisor and any extensions, as the CentOS VM is on VirtualBox (with guest additions) and the Ubuntu VM is on Hyper-V (with kernel LIS drivers).

Running through valgrind didn't give me much, dotnet restore seemed to hang. Seeing what I can do about.

Attempting to get a coredump.

andyleejordan · 2016-06-24T03:24:58Z

Coredumps obtained for CentOS (and Debian), emailing them to you @ellismg.

Fortunately, as I know how to reproduce the problem, I can downgrade my kernel and move on with work. Nonetheless, we should figure out why 4.6.x kernels and dotnet don't play well. Which issue should we keep (pretty sure they're the same problem now)?

ellismg · 2016-06-24T03:29:08Z

I vote we keep this one.

janvorli · 2016-06-27T16:15:34Z

Let me take a look.

janvorli · 2016-06-27T18:59:47Z

I have installed the 4.6.2 kernel to my Ubuntu VM and found it has nothing to do with the cli. The runtime itself doesn't work on that linux kernel. Even attempt to build coreclr repo fails with SIGSEGV in GC when building mscorlib.dll / System.Private.CoreLib.dll.
I have created issue in coreclr assigned to myself to track it:
https://github.com/dotnet/coreclr/issues/6016

klinkby · 2016-06-28T12:38:43Z

I can confirm that Debian stretch (4.6.0-1-amd64) is also affected with 1.0.0-preview2-003121.

ghost · 2016-06-28T12:47:20Z

@klinkby, PR that fixes the issue: dotnet/coreclr#6027.

abrodersen · 2016-06-28T17:26:05Z

Any chance the fix can be pushed out in a hotfix patch? This is currently preventing us from upgrading to 1.0

bakakaba · 2016-07-22T05:32:38Z

Having the same issue on Fedora 24 after fixing the libicu version issues.
Is there a workaround for this?

$ dotnet --version
1.0.0-preview3-003208
$ dotnet new

Decompressing 100% 1951 ms
Expanding 4%/usr/local/bin/dotnet: line 5: 11895 Segmentation fault (core dumped) /opt/dotnet/dotnet
$ dotnet --info
.NET Command Line Tools (1.0.0-preview3-003208)

Product Information:
Version: 1.0.0-preview3-003208
Commit SHA-1 hash: 76058be

Runtime Environment:
OS Name: fedora
OS Version: 24
OS Platform: Linux
RID: fedora.24-x64

ellismg · 2016-07-22T05:46:02Z

@cruz82 What version of the kernel are you using?

bakakaba · 2016-07-22T05:58:31Z

I'm on 4.6.3-300

ellismg · 2016-07-22T06:33:42Z

There was a bug in 1.0.0, that manifests itself as a crash like the above on recent kernels (IIRC 4.6.0+). We have a fix in the runtime but no official release of it yet. If you want to rebuild the CoreCLR part from source I can show you the commit to cherry-pick.

tanordheim · 2016-07-22T06:55:28Z

We're struggling with this also - we're seeing some instabilities in some apps running in Docker here after the underlying hosts (CoreOS) received some updates to the kernel recently. We're unable to run new builds right now (also happening in the containers) and already built apps are crashing fairly often. We can rebuild the CLR from source based on the latest preview2 if we can get some more information about which commits fixes this.

cobrafast · 2017-05-03T01:14:44Z

I'm still running into this problem with dotnet restore on my Debian box with the 1.1 package as described at https://www.microsoft.com/net/core#linuxdebian.

Program received signal SIGSEGV, Segmentation fault.
0x00007fffefb88d6d in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
(gdb) backtrace
#0  0x00007fffefb88d6d in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
dotnet/sdk#4283  0x00007fffefb83c8b in X509_verify_cert () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
dotnet/sdk#4284  0x00007fff7ce5e2c5 in ?? ()
dotnet/sdk#4285  0x00007fff3e209be0 in ?? ()
dotnet/sdk#4286  0xbafbcb4b7ab40f52 in ?? ()
dotnet/cli#5  0x000000001fd117cb in ?? ()
dotnet/cli#6  0x00007ffff67bf0f0 in vtable for InlinedCallFrame () from /opt/dotnet/shared/Microsoft.NETCore.App/1.1.1/libcoreclr.so
dotnet/cli#7  0x00007fff3e20a5f8 in ?? ()
dotnet/cli#8  0x00007fff7d667cc0 in ?? ()
dotnet/sdk#4287  0x00007fff7d667cc0 in ?? ()
dotnet/sdk#4288 0x00007fff3e209be0 in ?? ()
dotnet/sdk#4289 0x00007fff7ce5e2c5 in ?? ()
dotnet/sdk#4290 0x00007fff3e209c80 in ?? ()
dotnet/sdk#4291 0x00007fff7d667cc0 in ?? ()
dotnet/sdk#4292 0x00007fff58114100 in ?? ()
dotnet/sdk#4293 0x00007fff500ddfc0 in ?? ()
dotnet/sdk#4294 0x0000000000000000 in ?? ()

.NET Command Line Tools (1.0.3)

Product Information:
 Version:            1.0.3
 Commit SHA-1 hash:  37224c9917

Runtime Environment:
 OS Name:     debian
 OS Version:  8
 OS Platform: Linux
 RID:         debian.8-x64
 Base Path:   /opt/dotnet/sdk/1.0.3

Distributor ID: Debian
Description:    Debian GNU/Linux 8.7 (jessie)
Release:        8.7
Codename:       jessie

Linux 4.9.0-2-amd64 dotnet/sdk#4283 SMP Debian 4.9.18-1 (2017-03-30) x86_64

COREHOST_TRACE=1 resulted in a lot of text: https://pastebin.com/C7gtMr41

I'm not sure how to create or where to find crash dumps.

I have installed a few backport/sid packages as I need them for other things running on the same machine. That said, running apt-get upgrade didn't do anything for this particular problem.

Here are some currently installed packages that might be relevant:

ii  libcurl3:amd64                                              7.52.1-5                             amd64
ii  libcurl3:i386                                               7.52.1-5                             i386
ii  libcurl3-gnutls:amd64                                       7.52.1-5                             amd64
ii  libcurl3-gnutls:i386                                        7.52.1-5                             i386
ii  libcurl4-gnutls-dev:amd64                                   7.52.1-5                             amd64
ii  libssl-dev:amd64                                            1.0.1t-1+deb8u6                      amd64
ii  libssl-doc                                                  1.0.1t-1+deb8u6                      all
ii  libssl0.9.8                                                 0.9.8o-4squeeze14                    amd64
ii  libssl1.0.0:amd64                                           1.0.1t-1+deb8u6                      amd64
ii  libssl1.0.0:i386                                            1.0.1t-1+deb8u6                      i386
ii  libssl1.0.2:amd64                                           1.0.2k-1                             amd64
ii  libssl1.0.2:i386                                            1.0.2k-1                             i386
ii  libssl1.1:amd64                                             1.1.0e-1                             amd64

msjyoo · 2017-05-12T16:40:29Z

I am also running into this problem on Debian Stretch. So much for getting started with learning C# :(

eerhardt · 2017-05-12T16:47:11Z

@sekjun9878 - please see this conversation for Debian Stretch: dotnet/core#649 (comment)

msjyoo · 2017-05-12T16:52:01Z

@eerhardt Thanks for the reference, but it's not the same issue. I can run dotnet new console -o hwapp successfully. It's only dotnet restore that is segfaulting.

eerhardt · 2017-05-12T16:54:18Z

The general thread talks about that .NET Core 2.0 doesn't support Debian Stretch unless you install OpenSSL 1.0.x. Do you have that installed on the machine? Debian Stretch comes with OpenSSL 1.1, which .NET Core doesn't support yet.

So you'll get a segfault anywhere that tries using HTTPS or SSL.

cobrafast · 2017-05-12T20:28:17Z

@eerhardt as you can see from my post, there were various versions of libssl installed on my machine, two of which are 1.0.x versions in 64 and 32 bit variants, but it still segfaulted.

Here are the relevant files those packages result in:

/usr/lib/x86_64-linux-gnu/libssl3.so.1d -> libssl3.so
/usr/lib/x86_64-linux-gnu/libssl.so -> libssl.so.1.0.0
/usr/lib/x86_64-linux-gnu/libssl3.so
/usr/lib/x86_64-linux-gnu/libssl.a
/usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
/usr/lib/x86_64-linux-gnu/pkgconfig/libssl.pc
/usr/lib/x86_64-linux-gnu/libssl.so.1.0.2
/usr/lib/x86_64-linux-gnu/libssl.so.1.1
/usr/lib/i386-linux-gnu/libssl3.so.1d -> libssl3.so
/usr/lib/i386-linux-gnu/i586/libssl.so.1.0.0
/usr/lib/i386-linux-gnu/libssl3.so
/usr/lib/i386-linux-gnu/libssl.so.1.0.0
/usr/lib/i386-linux-gnu/i686/cmov/libssl.so.1.0.0
/usr/lib/i386-linux-gnu/libssl.so.1.0.2
/usr/lib/libssl.so.0.9.8

Maybe dotnet is using the wrong one?

omajid · 2017-05-12T21:06:35Z

Can you do an strace dotnet or LD_DEBUG=libs dotnet to see what it's loading?

cobrafast · 2017-05-15T13:30:21Z

Sure: https://pastebin.com/s0NqFQDD

As far as I can tell it does load libssl.so.1.0.0 but segfaults anyways.

eerhardt · 2017-05-15T14:48:43Z

@bartonjs - any thoughts?

bartonjs · 2017-05-15T16:19:18Z

My psychic debugger is getting a weak ping off of libcurl+openssl11 (since I see libssl.so.1.1 installed)

@cobrafast: What curl/libcurl do you have installed?

$ curl --version
curl 7.47.0 (x86_64-pc-linux-gnu) libcurl/7.47.0 GnuTLS/3.4.10 zlib/1.2.8 libidn/1.32 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP UnixSockets

In the case of the machine I happen to be logged in to right now, the TLS provider is GnuTLS/3.4.10. I'm surely hoping yours doesn't say OpenSSL/1.1(.something). If so, you'll need to get libcurl+openssl1.0(.x) or libcurl+anyotherprovider.

cobrafast · 2017-05-15T16:21:26Z

@bartonjs My curl is newer, but it says OpenSSL/1.0.2k.

curl 7.52.1 (x86_64-pc-linux-gnu) libcurl/7.52.1 OpenSSL/1.0.2k zlib/1.2.8 libidn2/0.16 libpsl/0.17.0 (+libidn2/0.16) libssh2/1.8.0 nghttp2/1.22.0 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL

bartonjs · 2017-05-15T16:32:34Z

Okay, libcurl is the problem. Or, at least the packages are. But it's a 1.0 vs 1.0 problem.

At line 224: find library=libSystem.Security.Cryptography.Native.OpenSsl.so [0]; searching

Followed (at 232) by:

     10571: find library=libcrypto.so.1.0.0 [0]; searching
     10571:  search cache=/etc/ld.so.cache
     10571:   trying file=/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0

Okay, we've loaded libcrypto.so.1.0.0.

Then, down at 544: find library=libSystem.Net.Http.Native.so [0]; searching

552:

     10571: find library=libcurl.so.4 [0]; searching
     10571:  search cache=/etc/ld.so.cache
     10571:   trying file=/usr/lib/x86_64-linux-gnu/libcurl.so.4

And.... 580:

     10571: find library=libcrypto.so.1.0.2 [0]; searching
     10571:  search cache=/etc/ld.so.cache
     10571:   trying file=/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2

So we're calling X509_verify in libcrypto.so.1.0.0, but giving it a pointer created by libcrypto.so.1.0.2. And something between the two different compilations has clearly changed the offset of some value (or interpretation thereof).

I don't know why Debian has packaged them side by side like that. Your system devel says that "1.0.0" is the SONAME to bind (/usr/lib/x86_64-linux-gnu/libssl.so -> libssl.so.1.0.0). If there isn't a libcurl which is bound to libssl.so.1.0.0 then you'll either need to

Change to libcurl+gnutls (or libcurl+nss, etc)
Change your development package to be libssl-dev 1.0.2 and rebuild the shims locally.

msjyoo · 2017-05-17T07:18:53Z

Just to confirm, Debian Stretch does not ship with libssl1.0.0. It was an artifact package required by some userspace apps from the previous release like skype (libssl1.0.0:i386) and rstudio and ruby2.1 (libssl1.0.0:amd64) in my case. I've removed both of those packages and now I'm getting this error:

Unhandled Exception: System.TypeInitializationException: The type initializer for 'Crypto' threw an exception. ---> System.TypeInitializationException: The type initializer for 'CryptoInitializer' threw an exception. ---> System.DllNotFoundException: Unable to load DLL 'System.Security.Cryptography.Native.OpenSsl': The specified module could not be found.
 (Exception from HRESULT: 0x8007007E)
   at Interop.CryptoInitializer.EnsureOpenSslInitialized()
   at Interop.CryptoInitializer..cctor()
   --- End of inner exception stack trace ---
   at Interop.Crypto..cctor()
   --- End of inner exception stack trace ---
   at Interop.Crypto.GetRandomBytes(Byte* buf, Int32 num)
   at System.IO.Path.GetCryptoRandomBytesOpenSsl(Byte* bytes, Int32 byteCount)
   at System.IO.Path.GetCryptoRandomBytes(Byte* bytes, Int32 byteCount)
   at System.IO.Path.GetRandomFileName()
   at Microsoft.DotNet.InternalAbstractions.TemporaryDirectory..ctor()
   at Microsoft.Extensions.EnvironmentAbstractions.DirectoryWrapper.CreateTemporaryDirectory()
   at Microsoft.DotNet.Configurer.NuGetPackagesArchiver..ctor()
   at Microsoft.DotNet.Cli.Program.ConfigureDotNetForFirstTimeUse(INuGetCacheSentinel nugetCacheSentinel)
   at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, ITelemetry telemetryClient)
   at Microsoft.DotNet.Cli.Program.Main(String[] args)
Aborted

Is dotnet core v1 supposed to support libssl1.0.2 or do I need libssl1.0.0?

bartonjs · 2017-05-17T13:35:04Z

@sekjun9878 If you build locally, any 1.0.x build is fine. The prebuilts, which were built on/for Jessie, require libssl.1.0.0. .NET Core 2.0 has added more flexibility, and will work prebuilt on both Jessie and Stretch.

omajid · 2017-05-17T13:41:36Z

It looks like this will be supported in the future: dotnet/corefx@4d7ee84

But the 1.0.x branch links against libcrypto.so.10 and libssl.so.10 directly. You can see this via ldd path/to/dotnet/shared/Microsoft.NETCore.App/1.0.*/System.Security.Cryptography.Native.so.

cobrafast · 2017-05-26T00:49:02Z

I just tried the .NET Core 2.0 Preview 1 package as per https://www.microsoft.com/net/core/preview#linuxdebian and the problem seems to persist.

fish: “dotnet restore” terminated by signal SIGSEGV (Address boundary error)

.NET Command Line Tools (2.0.0-preview1-005977)

Product Information:
 Version:            2.0.0-preview1-005977
 Commit SHA-1 hash:  414cab8a0b

Runtime Environment:
 OS Name:     debian
 OS Version:  8
 OS Platform: Linux
 RID:         debian.8-x64
 Base Path:   /opt/dotnet/sdk/2.0.0-preview1-005977/

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0-preview1-002111-00
  Build    : 1ff021936263d492539399688f46fd3827169983

ellismg · 2017-05-26T00:50:50Z

@cobrafast just to be sure, this is on Jessie, right?

cobrafast · 2017-05-26T00:52:01Z

@ellismg it's the same system I've been talking about previously (i.e. https://github.com/dotnet/cli/issues/3681#issuecomment-298802996)

bartonjs · 2017-05-26T08:16:46Z

@cobrafast Support for Jessie was fixed with dotnet/corefx@4d7ee84, but that happened after the preview1 build. You'll need to try nightlies, or wait for the next release.

cobrafast · 2017-09-13T17:10:46Z

Issue seems to persist with the build from the dotnet debian package repository.

deb [arch=amd64] https://packages.microsoft.com/repos/microsoft-debian-stretch-prod stretch main

fish: “dotnet build” terminated by signal SIGSEGV (Address boundary error)

#0  0x00007fffe0abfd6d in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
dotnet/sdk#4283  0x00007fffe0abac8b in X509_verify_cert () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
dotnet/sdk#4284  0x00007fff7d237ff6 in ?? ()
dotnet/sdk#4285  0x00007fff54f1edb0 in ?? ()
dotnet/sdk#4286  0x6c00fa377b77ae7b in ?? ()
dotnet/cli#5  0x00000000d0408626 in ?? ()
dotnet/cli#6  0x00007ffff67b4488 in ?? () from /usr/share/dotnet/shared/Microsoft.NETCore.App/2.0.0/libcoreclr.so
dotnet/cli#7  0x00007fff54f1f688 in ?? ()
dotnet/cli#8  0x00007fff7e652100 in ?? ()
dotnet/sdk#4287  0x00007fff7e652100 in ?? ()
dotnet/sdk#4288 0x00007fff54f1edb0 in ?? ()
dotnet/sdk#4289 0x00007fff7d237ff6 in ?? ()
dotnet/sdk#4290 0x00007fff54f1ee40 in ?? ()
dotnet/sdk#4291 0x00007fff7e652100 in ?? ()
dotnet/sdk#4292 0x00007fff5823d308 in ?? ()
dotnet/sdk#4293 0x0000000000000001 in ?? ()
dotnet/sdk#4294 0x00007fff582306a8 in ?? ()
dotnet/sdk#4295 0x00007fff5823d378 in ?? ()
dotnet/sdk#4296 0x00007fff5823d308 in ?? ()
dotnet/sdk#4297 0x00007fff5823d308 in ?? ()
dotnet/sdk#4298 0x00007fff301330c0 in ?? ()
dotnet/sdk#4299 0x00007fff54f1eeb0 in ?? ()
dotnet/sdk#4300 0x00007fff7e43ce57 in ?? ()
dotnet/sdk#4301 0x00007fff54f1ee50 in ?? ()
dotnet/sdk#4302 0x00007fff5823d308 in ?? ()
dotnet/sdk#4303 0x00007fff582306a8 in ?? ()
dotnet/sdk#4304 0x0000000000000000 in ?? ()

.NET Command Line Tools (2.0.0)

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

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

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0
  Build    : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d

ii  dotnet-host                                                 2.0.0-1                                         amd64
ii  dotnet-hostfxr-2.0.0                                        2.0.0-1                                         amd64
ii  dotnet-runtime-2.0.0                                        2.0.0-1                                         amd64
ii  dotnet-sdk-2.0.0                                            2.0.0-1                                         amd64
ii  libcrypt-openssl-bignum-perl                                0.04-4+b2                                       amd64
ii  libcrypt-openssl-rsa-perl                                   0.28-2+b1                                       amd64
ii  libcurl4-openssl-dev:amd64                                  7.55.1-1                                        amd64
ii  libgnutls-openssl27:amd64                                   3.5.13-2                                        amd64
ii  openssl                                                     1.0.1t-1+deb8u6                                 amd64

cobrafast · 2017-09-13T17:18:33Z

Installing packages from the jessie repo doesn't help either.

Perhaps we can get this issue reopened?

janvorli · 2017-09-13T17:28:34Z

@cobrafast can you please run curl --version and post the result here? I am interested in seeing the libraries that it shows.

cobrafast · 2017-09-13T17:29:50Z

@janvorli sure:

curl 7.55.1 (x86_64-pc-linux-gnu) libcurl/7.55.1 OpenSSL/1.0.2l zlib/1.2.8 libpsl/0.17.0 (+libidn2/0.16) libssh2/1.8.0 nghttp2/1.25.0 librtmp/2.3
Release-Date: 2017-08-14
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL

janvorli · 2017-09-14T16:49:08Z

@cobrafast the curl was built against OpenSSL 1.0.2l and according to your list you seem to have OpenSSL 1.0.1t installed. Do you happen to have the 1.0.2l package installed too? I am not sure about Debian 8, but in Debian 9, the libssl 1.0.2 has a different soname than libssl 1.0.1, those two can be installed side by side and if they end up in the same process (e.g. if one was pulled in by libcurl and the other by .NET native libraries), a threading issues can happen leading to crashes that may be what you are getting.
To see if that's the case, when you run it under gdb and it crashes, could you please run the "info proc map" debugger command and share the output e.g. via gist?

cobrafast · 2017-09-14T18:19:57Z

@janvorli hmm, there are several libssl packages installed.

ii  libssl-dev:amd64                                            1.0.1t-1+deb8u6                                 amd64
ii  libssl-doc                                                  1.0.1t-1+deb8u6                                 all
ii  libssl0.9.8                                                 0.9.8o-4squeeze14                               amd64
ii  libssl1.0.0:amd64                                           1.0.1t-1+deb8u6                                 amd64
ii  libssl1.0.0:i386                                            1.0.1t-1+deb8u6                                 i386
ii  libssl1.0.2:amd64                                           1.0.2l-2                                        amd64
ii  libssl1.0.2:i386                                            1.0.2l-2                                        i386
ii  libssl1.1:amd64                                             1.1.0f-5                                        amd64

Of those I was able to remove libssl0.9.8 but not the other three (i.e. 1.0.0, 1.0.2, 1.1) since other packages depend on them.

The info proc map is here: https://pastebin.com/wpT57znN

cobrafast · 2017-09-14T18:27:32Z

Seems like downgrading curl let me remove libssl1.0.2 and fixed the problem. I hope this doesn't break any other programs though.

janvorli · 2017-09-14T18:42:42Z

The proc map shows I was right - both the libssl.so.1.0.0 and libssl.so.1.0.2 were loaded at the same time. It seems that I'll need to add an env var that would allow people to override the libssl version that we use to allow fixing these corner cases.

v6ak · 2017-09-26T10:11:47Z

Is there any way to ignore one of the versions, or we have to wait until the next release?
IIUC, DotNet Core on Debian Jessie is limited to an unsupported version of OpenSSL. (Moreover, this version will not be present in clean Jessie installations.) So, this version can contain vulnerabilities that will never be fixed in Jessie. Are there any plans to upgrade DotNet Core to use the newer OpenSSL version?

In the meantime, I've tried to symlink /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 to /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 . Do it only at your own risk, this might introduce more issues than it fixes. So far, it looks good, though.

janvorli · 2017-09-26T10:42:47Z

@v6ak on Debian Jessie, the 1.0.1 is the supported version. See https://packages.debian.org/search?suite=jessie&searchon=names&keywords=openssl. The CURL that @cobrafast was using is not the version that's the standard version for Debian Jessie. His version was 7.55 while Debian Jessie has version 7.38. See
https://packages.debian.org/search?suite=jessie&section=all&arch=any&searchon=names&keywords=curl

The Debian Stretch is the one that has moved to 1.0.2.

andyleejordan changed the title ~~dotnet restore fails on CentOS 7~~ dotnet restore fails on Linux 4.6.2 Jun 23, 2016

msftgits transferred this issue from dotnet/cli Jan 31, 2020

dotnet restore fails on Linux 4.6.2 #6502

dotnet restore fails on Linux 4.6.2 #6502

Comments

andyleejordan commented Jun 23, 2016

Steps to reproduce

Expected behavior

Actual behavior

Environment data

andyleejordan commented Jun 23, 2016

andyleejordan commented Jun 23, 2016

eerhardt commented Jun 23, 2016

andyleejordan commented Jun 23, 2016

eerhardt commented Jun 23, 2016

eerhardt commented Jun 23, 2016 • edited

andyleejordan commented Jun 23, 2016

andyleejordan commented Jun 23, 2016

eerhardt commented Jun 23, 2016

andyleejordan commented Jun 23, 2016

andyleejordan commented Jun 23, 2016

andyleejordan commented Jun 23, 2016

andyleejordan commented Jun 23, 2016

eerhardt commented Jun 23, 2016

andyleejordan commented Jun 23, 2016

ghost commented Jun 23, 2016

andyleejordan commented Jun 24, 2016

andyleejordan commented Jun 24, 2016

ellismg commented Jun 24, 2016

janvorli commented Jun 27, 2016

janvorli commented Jun 27, 2016

klinkby commented Jun 28, 2016

ghost commented Jun 28, 2016

abrodersen commented Jun 28, 2016

bakakaba commented Jul 22, 2016

ellismg commented Jul 22, 2016

bakakaba commented Jul 22, 2016

ellismg commented Jul 22, 2016

tanordheim commented Jul 22, 2016

cobrafast commented May 3, 2017

msjyoo commented May 12, 2017

eerhardt commented May 12, 2017

msjyoo commented May 12, 2017

eerhardt commented May 12, 2017

cobrafast commented May 12, 2017

omajid commented May 12, 2017

cobrafast commented May 15, 2017

eerhardt commented May 15, 2017

bartonjs commented May 15, 2017

cobrafast commented May 15, 2017

bartonjs commented May 15, 2017 • edited

msjyoo commented May 17, 2017 • edited

bartonjs commented May 17, 2017

omajid commented May 17, 2017

cobrafast commented May 26, 2017

ellismg commented May 26, 2017

cobrafast commented May 26, 2017

bartonjs commented May 26, 2017

cobrafast commented Sep 13, 2017

cobrafast commented Sep 13, 2017

janvorli commented Sep 13, 2017

cobrafast commented Sep 13, 2017

janvorli commented Sep 14, 2017

cobrafast commented Sep 14, 2017

cobrafast commented Sep 14, 2017

janvorli commented Sep 14, 2017

v6ak commented Sep 26, 2017

janvorli commented Sep 26, 2017

eerhardt commented Jun 23, 2016 •

edited

bartonjs commented May 15, 2017 •

edited

msjyoo commented May 17, 2017 •

edited