sdk: Failed to initialize CoreCLR, HRESULT: 0x80004005

I don’t know why this is closed, because .NET Core stability is some kind of a joke.

http://pastebin.com/raw/tdSdXDKa

I have to issue dotnet run command 37 TIMES before it actually works. THIRTY SEVEN GODDAMN TIMES OR MORE!

Hmm, it turns out if I switch from the debian.8-x64 runtime to linux-x64, then it works.
Btw. what does the linux-x64 RID represent exactly? I found it in one of the examples repository, but I cannot find it on the page listing all the RIDs.

@janvorli I’m going to sh** bricks… I fully cleaned anything that related to dotnet on my server and following exactly the instructions on the microsoft page with the 1.0.1-runtime (https://www.microsoft.com/net/core#linuxdebian). And it just works. What. The. Fuck. What I don’t get: if I now do the ldd command to the path you’ve mentioned, it states it does not exists.

I really can’t reproduce what went wrong in the past but probably I just collected the wrong download URL and wasted up my server. Sorry for your lost time!

root@faraway:/home/main# rm /usr/local/bin/dotnet
root@faraway:/home/main# rm -rf /opt/dotnet
root@faraway:/home/main# cd /tmp
root@faraway:/tmp# dotnet
bash: /usr/local/bin/dotnet: No such file or directory
root@faraway:/tmp# mkdir installdotnet
root@faraway:/tmp# cd installdotnet
root@faraway:/tmp/installdotnet# curl -sSL -o dotnet.tar.gz https://go.microsoft.com/fwlink/?LinkID=836295
root@faraway:/tmp/installdotnet# mkdir -p /opt/dotnet
root@faraway:/tmp/installdotnet# tar zxf dotnet.tar.gz -C /opt/dotnet
root@faraway:/tmp/installdotnet# ln -s /opt/dotnet/dotnet /usr/local/bin
root@faraway:/tmp/installdotnet# dotnet --version

Microsoft .NET Core Shared Framework Host

  Version  : 1.0.1
root@faraway:/tmp/installdotnet# ldd /opt/dotnet/shared/Microsoft.NETCore.App/1.0.1/System.Globalization.Native.so
ldd: /opt/dotnet/shared/Microsoft.NETCore.App/1.0.1/System.Globalization.Native.so: No such file or directory
root@faraway:/tmp/installdotnet# su myuser
myuser@faraway:~$ dotnet myproject.dll

@geeooff thank you for the details, I will definitely look into the grsecurity stuff, try to enable it on my local Debian 8.6 and see what we can do about it. SEGFAULTS visible under the debugger most likely mean null references and if it runs ok without GDB, then they seem properly handled. Thanks to the call stack you have provided us with, I can see why the ClrVirtualAllocWithinRange is called. Since we have failed to allocate memory for the executable memory allocator close to the libcoreclr.so in the memory, jitter needs to create jump stubs that can jump farther than +/-2GB. That’s what results in calling ClrVirtualAllocWithinRange. But these jump stubs need to be located within +/-2GB range from the code that wants to make the long jump and we fail again, so the end result is OOM exception due to inability to allocate virtual memory in the specific range. I guess that it has something to do with the grsecurity.

I can repro. I used this Dockerfile: https://raw.githubusercontent.com/colemickens/polykube/dev/dotnet/dockerfiles/aspnet-base/Dockerfile

Cloned aspnet/cli-samples.

Ran dotnet restore and COREHOST_TRACE=1 dotnet run: https://gist.github.com/colemickens/133e434131961e6fe28178a35ed03696

Failed to initialize CoreCLR, HRESULT: 0x80004005

dotnet version: dotnet-dev-1.0.0-beta-002111"