dotnet restore fails on Linux 4.6.2 #3681

Closed
andschwa opened this Issue Jun 23, 2016 · 109 comments

Comments

Projects
None yet
@andschwa
Member

andschwa commented Jun 23, 2016

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 #3655.

@andschwa

This comment has been minimized.

Show comment
Hide comment
@andschwa

andschwa Jun 23, 2016

Member

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 #3676.

Member

andschwa commented Jun 23, 2016

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 #3676.

@andschwa

This comment has been minimized.

Show comment
Hide comment
@andschwa

andschwa Jun 23, 2016

Member

The backtrace in GDB was not useful to me:

#0  0x00007ffff79c66d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  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
#2  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
#3  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
#4  0x00007ffff6495da2 in WaitForSingleObjectEx ()
   from /home/andrew/.dotnet/shared/Microsoft.NETCore.App/1.0.0/libcoreclr.so
#5  0x00007ffff61eded2 in CLREventBase::WaitEx(unsigned int, WaitMode, PendingSync*) ()
   from /home/andrew/.dotnet/shared/Microsoft.NETCore.App/1.0.0/libcoreclr.so
Member

andschwa commented Jun 23, 2016

The backtrace in GDB was not useful to me:

#0  0x00007ffff79c66d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  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
#2  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
#3  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
#4  0x00007ffff6495da2 in WaitForSingleObjectEx ()
   from /home/andrew/.dotnet/shared/Microsoft.NETCore.App/1.0.0/libcoreclr.so
#5  0x00007ffff61eded2 in CLREventBase::WaitEx(unsigned int, WaitMode, PendingSync*) ()
   from /home/andrew/.dotnet/shared/Microsoft.NETCore.App/1.0.0/libcoreclr.so
@eerhardt

This comment has been minimized.

Show comment
Hide comment
@eerhardt

eerhardt Jun 23, 2016

Member

/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.

Member

eerhardt commented Jun 23, 2016

/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.

@andschwa

This comment has been minimized.

Show comment
Hide comment
@andschwa

andschwa Jun 23, 2016

Member

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.

Member

andschwa commented Jun 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@eerhardt

eerhardt Jun 23, 2016

Member

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.

Member

eerhardt commented Jun 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@eerhardt

eerhardt Jun 23, 2016

Member

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

Member

eerhardt commented Jun 23, 2016

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

@andschwa

This comment has been minimized.

Show comment
Hide comment
@andschwa

andschwa Jun 23, 2016

Member

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
Member

andschwa commented Jun 23, 2016

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
@andschwa

This comment has been minimized.

Show comment
Hide comment
@andschwa

andschwa Jun 23, 2016

Member

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

Member

andschwa commented Jun 23, 2016

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

@eerhardt

This comment has been minimized.

Show comment
Hide comment
@eerhardt

eerhardt Jun 23, 2016

Member

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

Member

eerhardt commented Jun 23, 2016

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

@andschwa

This comment has been minimized.

Show comment
Hide comment
@andschwa

andschwa Jun 23, 2016

Member

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

Member

andschwa commented Jun 23, 2016

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

@andschwa

This comment has been minimized.

Show comment
Hide comment
@andschwa

andschwa Jun 23, 2016

Member

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.)

Member

andschwa commented Jun 23, 2016

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.)

@andschwa

This comment has been minimized.

Show comment
Hide comment
@andschwa

andschwa Jun 23, 2016

Member

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)
Member

andschwa commented Jun 23, 2016

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)
@andschwa

This comment has been minimized.

Show comment
Hide comment
@andschwa

andschwa Jun 23, 2016

Member

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.

Member

andschwa commented Jun 23, 2016

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.

@andschwa andschwa changed the title from dotnet restore fails on CentOS 7 to dotnet restore fails on Linux 4.6.2 Jun 23, 2016

@eerhardt

This comment has been minimized.

Show comment
Hide comment
@eerhardt

eerhardt Jun 23, 2016

Member

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

Member

eerhardt commented Jun 23, 2016

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

@andschwa

This comment has been minimized.

Show comment
Hide comment
@andschwa

andschwa Jun 23, 2016

Member

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.

Member

andschwa commented Jun 23, 2016

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

This comment has been minimized.

Show comment
Hide comment

ghost commented Jun 23, 2016

@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

@andschwa

This comment has been minimized.

Show comment
Hide comment
@andschwa

andschwa Jun 24, 2016

Member

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.

Member

andschwa commented Jun 24, 2016

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.

@andschwa

This comment has been minimized.

Show comment
Hide comment
@andschwa

andschwa Jun 24, 2016

Member

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)?

Member

andschwa commented Jun 24, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ellismg

ellismg Jun 24, 2016

Contributor

I vote we keep this one.

Contributor

ellismg commented Jun 24, 2016

I vote we keep this one.

@MichaelSimons MichaelSimons referenced this issue in dotnet/dotnet-docker Jun 24, 2016

Closed

Seg Fault running dotnet restore Linux #61

@janvorli

This comment has been minimized.

Show comment
Hide comment
@janvorli

janvorli Jun 27, 2016

Member

Let me take a look.

Member

janvorli commented Jun 27, 2016

Let me take a look.

@janvorli

This comment has been minimized.

Show comment
Hide comment
@janvorli

janvorli Jun 27, 2016

Member

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:
dotnet/coreclr#6016

Member

janvorli commented Jun 27, 2016

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:
dotnet/coreclr#6016

@klinkby

This comment has been minimized.

Show comment
Hide comment
@klinkby

klinkby Jun 28, 2016

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

klinkby commented Jun 28, 2016

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

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jun 28, 2016

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

ghost commented Jun 28, 2016

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

@abrodersen

This comment has been minimized.

Show comment
Hide comment
@abrodersen

abrodersen Jun 28, 2016

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

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

@cruz82

This comment has been minimized.

Show comment
Hide comment
@cruz82

cruz82 Jul 22, 2016

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

cruz82 commented Jul 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ellismg

ellismg Jul 22, 2016

Contributor

@cruz82 What version of the kernel are you using?

Contributor

ellismg commented Jul 22, 2016

@cruz82 What version of the kernel are you using?

@cruz82

This comment has been minimized.

Show comment
Hide comment
@cruz82

cruz82 Jul 22, 2016

I'm on 4.6.3-300

cruz82 commented Jul 22, 2016

I'm on 4.6.3-300

@ellismg

This comment has been minimized.

Show comment
Hide comment
@ellismg

ellismg Jul 22, 2016

Contributor

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.

Contributor

ellismg commented Jul 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@tanordheim

tanordheim Jul 22, 2016

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.

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.

@cruz82

This comment has been minimized.

Show comment
Hide comment
@cruz82

cruz82 Jul 22, 2016

Sure, could try building with the appropriate patch or better yet, is there a runnable branch with the fix in place?

cruz82 commented Jul 22, 2016

Sure, could try building with the appropriate patch or better yet, is there a runnable branch with the fix in place?

@shahid-pk

This comment has been minimized.

Show comment
Hide comment
@shahid-pk

shahid-pk Jul 22, 2016

Contributor

i think this was the commit in coreclr dotnet/coreclr#6027 @ellismg can confirm.

Contributor

shahid-pk commented Jul 22, 2016

i think this was the commit in coreclr dotnet/coreclr#6027 @ellismg can confirm.

@janvorli

This comment has been minimized.

Show comment
Hide comment
@janvorli

janvorli Jul 22, 2016

Member

@shahid-pk yes, that was the fix.

Member

janvorli commented Jul 22, 2016

@shahid-pk yes, that was the fix.

@tanordheim

This comment has been minimized.

Show comment
Hide comment
@tanordheim

tanordheim Jul 23, 2016

For someone who's not really familiar with building this platform from source - any steps in some documentation on how I can go about fixing this? I have a built of coreclr here with this patched onto the 1.0.0-branch but I can't really figure out how to go about actually making that into a fix we can deploy into our currently deployed .NET core apps that are experiencing some failures at the moment. Do we need to rebuild everything (coreclr+corefx+cli) and use that, or can we replace some running parts of a system with stuff from this coreclr build and potentially fix this problem until we get a new official release containing this fix?

For someone who's not really familiar with building this platform from source - any steps in some documentation on how I can go about fixing this? I have a built of coreclr here with this patched onto the 1.0.0-branch but I can't really figure out how to go about actually making that into a fix we can deploy into our currently deployed .NET core apps that are experiencing some failures at the moment. Do we need to rebuild everything (coreclr+corefx+cli) and use that, or can we replace some running parts of a system with stuff from this coreclr build and potentially fix this problem until we get a new official release containing this fix?

@shahid-pk

This comment has been minimized.

Show comment
Hide comment
@shahid-pk

shahid-pk Jul 23, 2016

Contributor

@tanordheim you will only need to replace binaries you get from coreclr-1.0.0-branch+(dotnet/coreclr#6027), that is if your application is self contained and not using shared host/framework/runtime installed system wide in which case you will have to build all coreclr+corefx+cli.

Note : I am not a member of .net team. My words should be taken as an advise which should work. Team members may advise differently.

Contributor

shahid-pk commented Jul 23, 2016

@tanordheim you will only need to replace binaries you get from coreclr-1.0.0-branch+(dotnet/coreclr#6027), that is if your application is self contained and not using shared host/framework/runtime installed system wide in which case you will have to build all coreclr+corefx+cli.

Note : I am not a member of .net team. My words should be taken as an advise which should work. Team members may advise differently.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jul 23, 2016

@tanordheim, dotnet/coreclr#6027 is a link of PR, the in-tree commit of master branch is dotnet/coreclr@56ab756.

You most probably only need to replace mscorlib, libcoreclr, and system.private.corlib (in total 5 items, see below) from the build output and replace with the installed one. Here is how:

# this is std Bourne shell
git clone https://github.com/dotnet/coreclr -b release/1.0.0

cd coreclr

git cherry-pick 56ab756
git cherry-pick 41912e3  # you *may* need this patch as well,
                         # see https://github.com/dotnet/coreclr/issues/5006

build.sh release

# it may ask you to install cmake, libunwind etc. if you haven't already,

# On successful build, time to copy stuff:

# 1)

# make backup of existing libcoreclr.so in the installed runtime dir first:
mv $(dirname $(which dotnet))/shared/Microsoft.NETCore.App/1.0.0/libcoreclr.so \
$(dirname $(which dotnet))/shared/Microsoft.NETCore.App/1.0.0/libcoreclr.so.old
# ^ this way, you can always move `libcoreclr.so.old` back to `libcoreclr.so`

# copy newly built libcoreclr.so over to the installed runtime dir
cp bin/Product/Linux.x64.Release/libcoreclr.so \
$(dirname $(which dotnet))/shared/Microsoft.NETCore.App/1.0.0/

# 2)

# similarly, make backup of existing mscorlib.dll in the installed runtime dir:
mv $(dirname $(which dotnet))/shared/Microsoft.NETCore.App/1.0.0/mscorlib.dll \
$(dirname $(which dotnet))/shared/Microsoft.NETCore.App/1.0.0/mscorlib.dll.old

# copy newly built mscorlib.dll over to the installed runtime dir
cp bin/Product/Linux.x64.Release/mscorlib.dll \
$(dirname $(which dotnet))/shared/Microsoft.NETCore.App/1.0.0/

# repeat for the following:

# 3) bin/Product/Linux.x64.Release/mscorlib.ni.dll
# 4) bin/Product/Linux.x64.Release/System.Private.CoreLib.dll
# 5) bin/Product/Linux.x64.Release/System.Private.CoreLib.ni.dll

CLI team at some point announced the nightly builds, but apparently that plan is not on board any more..

ghost commented Jul 23, 2016

@tanordheim, dotnet/coreclr#6027 is a link of PR, the in-tree commit of master branch is dotnet/coreclr@56ab756.

You most probably only need to replace mscorlib, libcoreclr, and system.private.corlib (in total 5 items, see below) from the build output and replace with the installed one. Here is how:

# this is std Bourne shell
git clone https://github.com/dotnet/coreclr -b release/1.0.0

cd coreclr

git cherry-pick 56ab756
git cherry-pick 41912e3  # you *may* need this patch as well,
                         # see https://github.com/dotnet/coreclr/issues/5006

build.sh release

# it may ask you to install cmake, libunwind etc. if you haven't already,

# On successful build, time to copy stuff:

# 1)

# make backup of existing libcoreclr.so in the installed runtime dir first:
mv $(dirname $(which dotnet))/shared/Microsoft.NETCore.App/1.0.0/libcoreclr.so \
$(dirname $(which dotnet))/shared/Microsoft.NETCore.App/1.0.0/libcoreclr.so.old
# ^ this way, you can always move `libcoreclr.so.old` back to `libcoreclr.so`

# copy newly built libcoreclr.so over to the installed runtime dir
cp bin/Product/Linux.x64.Release/libcoreclr.so \
$(dirname $(which dotnet))/shared/Microsoft.NETCore.App/1.0.0/

# 2)

# similarly, make backup of existing mscorlib.dll in the installed runtime dir:
mv $(dirname $(which dotnet))/shared/Microsoft.NETCore.App/1.0.0/mscorlib.dll \
$(dirname $(which dotnet))/shared/Microsoft.NETCore.App/1.0.0/mscorlib.dll.old

# copy newly built mscorlib.dll over to the installed runtime dir
cp bin/Product/Linux.x64.Release/mscorlib.dll \
$(dirname $(which dotnet))/shared/Microsoft.NETCore.App/1.0.0/

# repeat for the following:

# 3) bin/Product/Linux.x64.Release/mscorlib.ni.dll
# 4) bin/Product/Linux.x64.Release/System.Private.CoreLib.dll
# 5) bin/Product/Linux.x64.Release/System.Private.CoreLib.ni.dll

CLI team at some point announced the nightly builds, but apparently that plan is not on board any more..

@naamunds

This comment has been minimized.

Show comment
Hide comment
@naamunds

naamunds Sep 14, 2016

Member

@janvorli Does the segmentation fault that @Bhaal22 is still seeing on Debian Stretch look like the same issue, or should a new issue be logged for it?

Member

naamunds commented Sep 14, 2016

@janvorli Does the segmentation fault that @Bhaal22 is still seeing on Debian Stretch look like the same issue, or should a new issue be logged for it?

@janvorli

This comment has been minimized.

Show comment
Hide comment
@janvorli

janvorli Sep 14, 2016

Member

@naamunds The former issue manifested in a very random way - the stack segment register was getting overwritten for threads at random times (when GC was starting) and took effect after the GC finished and each thread was resumed and so the issue was always at a different place.
I would say that if the issue @Bhaal22 sees has always the same bottom of the call stack, it is a different problem.

Member

janvorli commented Sep 14, 2016

@naamunds The former issue manifested in a very random way - the stack segment register was getting overwritten for threads at random times (when GC was starting) and took effect after the GC finished and each thread was resumed and so the issue was always at a different place.
I would say that if the issue @Bhaal22 sees has always the same bottom of the call stack, it is a different problem.

@gkhanna79

This comment has been minimized.

Show comment
Hide comment
@gkhanna79

gkhanna79 Sep 14, 2016

Member

@Bhaal22 Can you please export COREHOST_TRACE=1, attempt the repro and share the following:

  1. Log containing the trace output
  2. Crash dump for the crash.
Member

gkhanna79 commented Sep 14, 2016

@Bhaal22 Can you please export COREHOST_TRACE=1, attempt the repro and share the following:

  1. Log containing the trace output
  2. Crash dump for the crash.
@Bhaal22

This comment has been minimized.

Show comment
Hide comment
@Bhaal22

Bhaal22 Sep 15, 2016

Fore some reason (probably a system update), now its fine.
My bad ...

Close the issue then.

Bhaal22 commented Sep 15, 2016

Fore some reason (probably a system update), now its fine.
My bad ...

Close the issue then.

@cobrafast

This comment has been minimized.

Show comment
Hide comment
@cobrafast

cobrafast May 3, 2017

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
#1  0x00007fffefb83c8b in X509_verify_cert () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#2  0x00007fff7ce5e2c5 in ?? ()
#3  0x00007fff3e209be0 in ?? ()
#4  0xbafbcb4b7ab40f52 in ?? ()
#5  0x000000001fd117cb in ?? ()
#6  0x00007ffff67bf0f0 in vtable for InlinedCallFrame () from /opt/dotnet/shared/Microsoft.NETCore.App/1.1.1/libcoreclr.so
#7  0x00007fff3e20a5f8 in ?? ()
#8  0x00007fff7d667cc0 in ?? ()
#9  0x00007fff7d667cc0 in ?? ()
#10 0x00007fff3e209be0 in ?? ()
#11 0x00007fff7ce5e2c5 in ?? ()
#12 0x00007fff3e209c80 in ?? ()
#13 0x00007fff7d667cc0 in ?? ()
#14 0x00007fff58114100 in ?? ()
#15 0x00007fff500ddfc0 in ?? ()
#16 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 #1 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

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
#1  0x00007fffefb83c8b in X509_verify_cert () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#2  0x00007fff7ce5e2c5 in ?? ()
#3  0x00007fff3e209be0 in ?? ()
#4  0xbafbcb4b7ab40f52 in ?? ()
#5  0x000000001fd117cb in ?? ()
#6  0x00007ffff67bf0f0 in vtable for InlinedCallFrame () from /opt/dotnet/shared/Microsoft.NETCore.App/1.1.1/libcoreclr.so
#7  0x00007fff3e20a5f8 in ?? ()
#8  0x00007fff7d667cc0 in ?? ()
#9  0x00007fff7d667cc0 in ?? ()
#10 0x00007fff3e209be0 in ?? ()
#11 0x00007fff7ce5e2c5 in ?? ()
#12 0x00007fff3e209c80 in ?? ()
#13 0x00007fff7d667cc0 in ?? ()
#14 0x00007fff58114100 in ?? ()
#15 0x00007fff500ddfc0 in ?? ()
#16 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 #1 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

This comment has been minimized.

Show comment
Hide comment
@msjyoo

msjyoo May 12, 2017

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

msjyoo commented May 12, 2017

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

@eerhardt

This comment has been minimized.

Show comment
Hide comment
@eerhardt

eerhardt May 12, 2017

Member

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

Member

eerhardt commented May 12, 2017

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

@msjyoo

This comment has been minimized.

Show comment
Hide comment
@msjyoo

msjyoo May 12, 2017

@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.

msjyoo commented May 12, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@eerhardt

eerhardt May 12, 2017

Member

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.

Member

eerhardt commented May 12, 2017

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

This comment has been minimized.

Show comment
Hide comment
@cobrafast

cobrafast May 12, 2017

@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?

@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

This comment has been minimized.

Show comment
Hide comment
@omajid

omajid May 12, 2017

Member

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

Member

omajid commented May 12, 2017

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

@cobrafast

This comment has been minimized.

Show comment
Hide comment
@cobrafast

cobrafast May 15, 2017

Sure: https://pastebin.com/s0NqFQDD

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

Sure: https://pastebin.com/s0NqFQDD

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

@eerhardt

This comment has been minimized.

Show comment
Hide comment
@eerhardt

eerhardt May 15, 2017

Member

@bartonjs - any thoughts?

Member

eerhardt commented May 15, 2017

@bartonjs - any thoughts?

@bartonjs

This comment has been minimized.

Show comment
Hide comment
@bartonjs

bartonjs May 15, 2017

Member

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.

Member

bartonjs commented May 15, 2017

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

This comment has been minimized.

Show comment
Hide comment
@cobrafast

cobrafast May 15, 2017

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

This comment has been minimized.

Show comment
Hide comment
@bartonjs

bartonjs May 15, 2017

Member

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.
Member

bartonjs commented May 15, 2017

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

This comment has been minimized.

Show comment
Hide comment
@msjyoo

msjyoo May 17, 2017

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?

msjyoo commented May 17, 2017

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

This comment has been minimized.

Show comment
Hide comment
@bartonjs

bartonjs May 17, 2017

Member

@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.

Member

bartonjs commented May 17, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@omajid

omajid May 17, 2017

Member

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.

Member

omajid commented May 17, 2017

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

This comment has been minimized.

Show comment
Hide comment
@cobrafast

cobrafast May 26, 2017

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

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

This comment has been minimized.

Show comment
Hide comment
@ellismg

ellismg May 26, 2017

Contributor

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

Contributor

ellismg commented May 26, 2017

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

@cobrafast

This comment has been minimized.

Show comment
Hide comment
@cobrafast

cobrafast May 26, 2017

@ellismg it's the same system I've been talking about previously (i.e. #3681 (comment))

@ellismg it's the same system I've been talking about previously (i.e. #3681 (comment))

@bartonjs

This comment has been minimized.

Show comment
Hide comment
@bartonjs

bartonjs May 26, 2017

Member

@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.

Member

bartonjs commented May 26, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@cobrafast

cobrafast Sep 13, 2017

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
#1  0x00007fffe0abac8b in X509_verify_cert () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#2  0x00007fff7d237ff6 in ?? ()
#3  0x00007fff54f1edb0 in ?? ()
#4  0x6c00fa377b77ae7b in ?? ()
#5  0x00000000d0408626 in ?? ()
#6  0x00007ffff67b4488 in ?? () from /usr/share/dotnet/shared/Microsoft.NETCore.App/2.0.0/libcoreclr.so
#7  0x00007fff54f1f688 in ?? ()
#8  0x00007fff7e652100 in ?? ()
#9  0x00007fff7e652100 in ?? ()
#10 0x00007fff54f1edb0 in ?? ()
#11 0x00007fff7d237ff6 in ?? ()
#12 0x00007fff54f1ee40 in ?? ()
#13 0x00007fff7e652100 in ?? ()
#14 0x00007fff5823d308 in ?? ()
#15 0x0000000000000001 in ?? ()
#16 0x00007fff582306a8 in ?? ()
#17 0x00007fff5823d378 in ?? ()
#18 0x00007fff5823d308 in ?? ()
#19 0x00007fff5823d308 in ?? ()
#20 0x00007fff301330c0 in ?? ()
#21 0x00007fff54f1eeb0 in ?? ()
#22 0x00007fff7e43ce57 in ?? ()
#23 0x00007fff54f1ee50 in ?? ()
#24 0x00007fff5823d308 in ?? ()
#25 0x00007fff582306a8 in ?? ()
#26 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

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
#1  0x00007fffe0abac8b in X509_verify_cert () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#2  0x00007fff7d237ff6 in ?? ()
#3  0x00007fff54f1edb0 in ?? ()
#4  0x6c00fa377b77ae7b in ?? ()
#5  0x00000000d0408626 in ?? ()
#6  0x00007ffff67b4488 in ?? () from /usr/share/dotnet/shared/Microsoft.NETCore.App/2.0.0/libcoreclr.so
#7  0x00007fff54f1f688 in ?? ()
#8  0x00007fff7e652100 in ?? ()
#9  0x00007fff7e652100 in ?? ()
#10 0x00007fff54f1edb0 in ?? ()
#11 0x00007fff7d237ff6 in ?? ()
#12 0x00007fff54f1ee40 in ?? ()
#13 0x00007fff7e652100 in ?? ()
#14 0x00007fff5823d308 in ?? ()
#15 0x0000000000000001 in ?? ()
#16 0x00007fff582306a8 in ?? ()
#17 0x00007fff5823d378 in ?? ()
#18 0x00007fff5823d308 in ?? ()
#19 0x00007fff5823d308 in ?? ()
#20 0x00007fff301330c0 in ?? ()
#21 0x00007fff54f1eeb0 in ?? ()
#22 0x00007fff7e43ce57 in ?? ()
#23 0x00007fff54f1ee50 in ?? ()
#24 0x00007fff5823d308 in ?? ()
#25 0x00007fff582306a8 in ?? ()
#26 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

This comment has been minimized.

Show comment
Hide comment
@cobrafast

cobrafast Sep 13, 2017

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

Perhaps we can get this issue reopened?

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

Perhaps we can get this issue reopened?

@janvorli

This comment has been minimized.

Show comment
Hide comment
@janvorli

janvorli Sep 13, 2017

Member

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

Member

janvorli commented Sep 13, 2017

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

@cobrafast

This comment has been minimized.

Show comment
Hide comment
@cobrafast

cobrafast Sep 13, 2017

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

This comment has been minimized.

Show comment
Hide comment
@janvorli

janvorli Sep 14, 2017

Member

@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?

Member

janvorli commented Sep 14, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@cobrafast

cobrafast Sep 14, 2017

@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

@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

This comment has been minimized.

Show comment
Hide comment
@cobrafast

cobrafast Sep 14, 2017

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

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

This comment has been minimized.

Show comment
Hide comment
@janvorli

janvorli Sep 14, 2017

Member

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.

Member

janvorli commented Sep 14, 2017

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

This comment has been minimized.

Show comment
Hide comment
@v6ak

v6ak Sep 26, 2017

  • 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.

v6ak commented Sep 26, 2017

  • 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

This comment has been minimized.

Show comment
Hide comment
@janvorli

janvorli Sep 26, 2017

Member

@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.

Member

janvorli commented Sep 26, 2017

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment