Loading assemblies from root folder `/` fails on linux arm64 (error code 0x80070002)

[anthony-c-martin]

Description

When using self-contained binaries, we've run into a strange error message if the binary is executed on a path outside of /usr/local/bin. This was reported to us under Azure/bicep#15278.

Here's the error:

./bicep build test.bicep    
Failed to load System.Private.CoreLib.dll (error code 0x80070002)
Path: /System.Private.CoreLib.dll
Error message: Could not load file or assembly '/System.Private.CoreLib.dll'. The system cannot find the file specified.
(0x80070002)

Reproduction Steps

1. Clone https://github.com/Azure/bicep
2. Run dotnet publish --configuration release --self-contained true -r linux-arm64 ./src/Bicep.Cli/Bicep.Cli.csproj
3. Copy the binary to a linux arm64 container, and try to run it from a path outside of /usr/local/bin - e.g. ./bicep build <foo>

Expected behavior

The binary runs successfully and returns exit code 0.

Actual behavior

The following error is returned:

./bicep build test.bicep    
Failed to load System.Private.CoreLib.dll (error code 0x80070002)
Path: /System.Private.CoreLib.dll
Error message: Could not load file or assembly '/System.Private.CoreLib.dll'. The system cannot find the file specified.
(0x80070002)

Regression?

Unknown

Known Workarounds

Copy the binary to /usr/local/bin on the system.

Configuration

No response

Other information

No response

[dotnet-policy-service]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

[agocke]

Our official bits don't support bicep:

The specified RuntimeIdentifier 'bicep-linux-arm64' is not recognized.

Is this a source-built copy of the runtime?

[anthony-c-martin]

Our official bits don't support bicep:

The specified RuntimeIdentifier 'bicep-linux-arm64' is not recognized.

Is this a source-built copy of the runtime?

It's a binary we've built using dotnet with self-contained mode.

[agocke]

Right, but where are you getting dotnet? You can't pass -r bicep-linux-arm64 on an official build of the dotnet SDK.

[anthony-c-martin]

🤦 sorry - I had a typo in my original repro. It was meant to be linux-arm64, not bicep-linux-arm64. I've updated it.

[elinor-fung]

I think I narrowed this down a bit more: single-file, self-contained, linux-arm64, running from / in a linux arm64 container

1. dotnet new console -o repro && cd repro
2. dotnet publish --sc -p:PublishSingleFile=true -r linux-arm64
3. Copy output repro executable to root / of a linux arm64 container
4. In container, run /repro

I used dotnet/runtime-deps:8.0.11-noble-arm64v8 as the container.

Did not repro with:

• location other than /
• x64 (dotnet/runtime-deps:8.0.11-noble-amd64)

[elinor-fung]

Looks like this is a problem with loading assemblies from / on linux (maybe macOS too) arm64. I think single-file/self-contained are unrelated to the core issue.

With a /repro.dll that exists (and can be loaded if put in a different location):

AssemblyLoadContext.Default.LoadFromAssemblyPath("/repro.dll");

Results in:

System.IO.FileNotFoundException: Could not load file or assembly '/repro.dll'. The system cannot find the file specified.
File name: '/repro.dll'
   at System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyPath(String assemblyPath)
   at Program.<Main>$(String[] args)

The pal's CorUnix::InternalCanonicalizeRealPath that has some special handling for the root folder only on amd64 looks suspicious:

runtime/src/coreclr/pal/src/file/file.cpp

Lines 337 to 361 in 2cdfd0a

	#if defined(HOST_AMD64)
	bool fSetFilename = true;
	// Since realpath implementation cannot handle inexistent filenames,
	// check if we are going to truncate the "/" corresponding to the
	// root folder (e.g. case of "/Volumes"). If so:
	//
	// 1) Set the separator to point to the NULL terminator of the specified
	// file/folder name.
	//
	// 2) Null terminate lpBuffer
	//
	// 3) Since there is no explicit filename component in lpExistingPath (as
	// we only have "/" corresponding to the root), set lpFilename to NULL,
	// alongwith a flag indicating that it has already been set.
	if (pchSeparator == lpExistingPath)
	{
	pchSeparator = lpExistingPath+strlen(lpExistingPath);
	// Set the lpBuffer to NULL
	lpBuffer.Clear();
	lpFilename = NULL;
	fSetFilename = false;
	}
	else
	#endif // defined(HOST_AMD64)

[janvorli]

Right, it is pretty weird handling only amd64 that way, it doesn't make any sense. The code is unchanged since the creation of the open source .NET Core (except of the ifdef that used to be _AMD64_, but that's just cosmetic).