Unable to run hello world on ARM Linux

[Const-me]

The command I'm running: dotnet my.dll

A fatal error was encountered. The library 'libhostpolicy.so' required to execute the application was not found in '...'.
Failed to run as a self-contained app. If this should be a framework-dependent app, add the ...runtimeconfig.json file specifying the appropriate framework.

Content of my runtimeconfig.json:

{
  "runtimeOptions": {
    "tfm": "netcoreapp2.1",
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "2.1"
    }
  }
}

I’ve even verified that nano opens that file, by copy-pasting the path, opens OK.

Output of dotnet --info

Host (useful for support):
  Version: 2.1.16
  Commit:  5f979c18c1

.NET Core SDKs installed:
  No SDKs were found.

.NET Core runtimes installed:
  Microsoft.NETCore.App 2.1.16 [/opt/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

Another one, same bug:

Host (useful for support):
  Version: 2.2.8
  Commit:  b9aa1abc51

.NET Core SDKs installed:
  No SDKs were found.

.NET Core runtimes installed:
  Microsoft.NETCore.App 2.2.8 [/opt/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

Can reproduce with 100% probability, when running from a network mounted location.
Mount command: sudo mount -t cifs //192.168.0.55/z$/Something /home/pi/z -o 'username=*******@live.com,password=*******,uid=1000,gid=1000' -o vers=2.0

192.168.0.55 is my desktop PC, it’s running Windows 10 1903, both devices are connected with gigabit Ethernet to the same router.

Ideally, could you please stop requiring strange features from the file system so the .NET programs can run from network drives? As a bare minimum, at least fix the error message. I’ve spent half an hour trying different versions of the framework, and different settings in that JSON.

[elinor-fung]

@lpereira thoughts on why we can't detect the existence of the app's .runtimeconfig.json in this scenario?

Created #33193 to at least point out that we could not find the config file.

[lpereira]

Unfortunately we don't have git tags for the runtime releases so it's not easy to look back at what a previous version did. I'm not familiar with the 2.x series of .NET Core.

Having said that, however, I would appreciate an strace log of when this fails; this should help me figure out what could be the issue, as I don't know what could be failing (there's nothing but trivial filesystem operations as far as I remember).

Ideally, something like strace -f -etrace=%file -o trace.txt dotnet my.dll. The last few hundred lines of trace.txt should be sufficient.

[elinor-fung]

Unfortunately we don't have git tags for runtime releases

Are you looking for something like https://github.com/dotnet/core-setup/tree/v2.2.8? Or something else?

[lpereira]

Ah, yes, forgot to check in the old repo. 😅 We should port those tags to this repo.

[lpereira]

OK, looked at the old code and it doesn't seem that weird as far as file system operations go. It's pretty vanilla-looking. So, to figure out what's happening here I'd appreciate that strace log.

[Const-me]

@lpereira Nothing interesting there, all your kernel calls complete successfully. Take a look.

867   execve("/usr/local/bin/dotnet", ["dotnet", "EglTest.dll"], 0xbeeef694 /* 22 vars */) = 0
867   access("/etc/ld.so.preload", R_OK) = 0
867   openat(AT_FDCWD, "/etc/ld.so.preload", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
867   readlink("/proc/self/exe", "/opt/dotnet/dotnet", 4096) = 18
867   openat(AT_FDCWD, "/usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
867   openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
867   openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libdl.so.2", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
867   openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libpthread.so.0", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
867   openat(AT_FDCWD, "/usr/lib/arm-linux-gnueabihf/libstdc++.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
867   openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libm.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
867   openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libgcc_s.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
867   openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libc.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
867   lstat64("/proc", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
867   lstat64("/proc/self", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0
867   readlink("/proc/self", "867", 4095) = 3
867   lstat64("/proc/867", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
867   lstat64("/proc/867/exe", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0
867   readlink("/proc/867/exe", "/opt/dotnet/dotnet", 4095) = 18
867   lstat64("/opt", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
867   lstat64("/opt/dotnet", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
867   lstat64("/opt/dotnet/dotnet", {st_mode=S_IFREG|0755, st_size=76144, ...}) = 0
867   stat64("/opt/dotnet/host/fxr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
867   openat(AT_FDCWD, "/opt/dotnet/host/fxr", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_CLOEXEC|O_DIRECTORY) = 3
867   stat64("/opt/dotnet/host/fxr/2.2.8/libhostfxr.so", {st_mode=S_IFREG|0755, st_size=441080, ...}) = 0
867   openat(AT_FDCWD, "/opt/dotnet/host/fxr/2.2.8/libhostfxr.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 4
867   stat64("/opt/dotnet/libcoreclr.so", 0xbec3c0b8) = -1 ENOENT (No such file or directory)
867   stat64("/opt/dotnet/dotnet.dll", 0xbec3c0f8) = -1 ENOENT (No such file or directory)
867   getcwd("/home/pi/z/net-bug", 4096) = 19
867   lstat64("/home/pi/z/net-bug/EglTest.dll", {st_mode=S_IFREG|0755, st_size=8704, ...}) = 0
867   stat64("/home/pi/z/net-bug/EglTest.runtimeconfig.dev.json", {st_mode=S_IFREG|0755, st_size=246, ...}) = 0
867   stat64("/home/pi/z/net-bug/EglTest.runtimeconfig.json", {st_mode=S_IFREG|0755, st_size=154, ...}) = 0
867   stat64("/home/pi/z/net-bug/EglTest.deps.json", {st_mode=S_IFREG|0755, st_size=752, ...}) = 0
867   stat64("/home/pi/z/net-bug/libhostpolicy.so", 0xbec3b7a0) = -1 ENOENT (No such file or directory)
867   stat64("/home/pi/z/net-bug/EglTest.runtimeconfig.json", {st_mode=S_IFREG|0755, st_size=154, ...}) = 0
867   +++ exited with 131 +++

The /home/pi/z directory is network mounted, here’s what mount prints about the share:

//192.168.0.55/z$/Something on /home/pi/z type cifs (rw,relatime,vers=2.0,cache=strict,username=****@live.com,uid=1000,forceuid,gid=1000,forcegid,addr=192.168.0.55,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=65536,wsize=65536,echo_interval=60,actimeo=1)

If you want to reproduce locally, I’m running this on Raspberry Pi 4B with Raspbian Buster Lite 4.19.

Update: the text above is the complete log, it only has 35 lines. I’ve tried running the same binaries from local FS with strace, it completed successfully and resulted in 1730 lines in the strace output.

Another funfact. When running locally, the runtime doesn’t try to find libhostpolicy.so in the application’s folder. It only looks in pkgs/runtime.linux-arm.Microsoft.NETCore.DotNetHostPolicy/2.2.8/runtimes/linux-arm/native/ (fails) and in /opt/dotnet/shared/Microsoft.NETCore.App/2.2.8/ (finds one).

Based on the symptoms, my guess is you have a code which detects it’s running from a network drive, and adjusts some runtime security policies if it’s the case.

Update: Tried running with local current directory, specify DLL path on mounted folder – fails with the bug.

Tried running from mounted current directory, specify DLL path in local folder — runs OK, however before running my code it printed 4 identical messages realpath(): Invalid argument

[lpereira]

In the chance that this has been fixed already, have you tried running with 3.1?

[elinor-fung]

It may also be helpful to get the more detailed host tracing output. If you set the environment variable COREHOST_TRACE=1, it will print a bunch of log messages to the terminal (there's a way to redirect to a file in 3.0, but not in earlier releases).