Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failed to locate managed application c3ab8ff13720e8ad9047dd39466b3c8974e592c2fa383d4a3960714caef0c4f2 #109611

Open
omajid opened this issue Nov 7, 2024 · 4 comments
Assignees
Milestone

Comments

@omajid
Copy link
Member

omajid commented Nov 7, 2024

Description

I am seeing variants of this error on Fedora ELN and CentOS Stream 10, with .NET 8 and .NET 9.

With .NET 8, I see this when building the VMR:

             ILCompiler.Diagnostics -> dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/ILCompiler.Diagnostics/x64/Release/ILCompiler.Diagnostics.dll
             ILCompiler.ReadyToRun -> dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/ILCompiler.ReadyToRun/x64/Release/ILCompiler.ReadyToRun.dll
             crossgen2_publish -> dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/crossgen2_publish/x64/Release/crossgen2.dll
             Optimizing assemblies for size. This process might take a while.
             crossgen2_publish -> dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/crossgen2_publish/x64/Release/fedora.42-x64/publish/
             Microsoft.NETCore.App.Crossgen2 -> 
             Failed to locate managed application [dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/crossgen2_publish/x64/Release/fedora.42-x64/publish/c3ab8ff13720e8ad9047dd39466b3c8974e592c2fa383d4a3960714caef0c4f2]
           dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/src/installer/pkg/sfx/Microsoft.NETCore.App/Microsoft.NETCore.App.Crossgen2.sfxproj(67,5): error MSB3073: The command "dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/crossgen2_publish/x64/Release/fedora.42-x64/publish/crossgen2 dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/coreclr/linux.x64.Release/IL/System.Private.CoreLib.dll --out dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/obj/Microsoft.NETCore.App.Crossgen2/Release/net8.0/fedora.42-x64/S.P.C.tmp" exited with code 146.

Trying to trace this shows:

COREHOST_TRACE=1 dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/crossgen2_publish/x64/Release/fedora.42-x64/publish/crossgen2 dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/coreclr/linux.x64.Release/IL/System.Private.CoreLib.dll --out dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/obj/Microsoft.NETCore.App.Crossgen2/Release/net8.0/fedora.42-x64/S.P.C.tmp
Tracing enabled @ Thu Nov  7 13:41:40 2024 GMT
--- Invoked apphost [version: 8.0.10 @Commit: 81cabf2857a01351e5ab578947c7403a5b128ad1] main = {
dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/crossgen2_publish/x64/Release/fedora.42-x64/publish/crossgen2
dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/coreclr/linux.x64.Release/IL/System.Private.CoreLib.dll
--out
dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/obj/Microsoft.NETCore.App.Crossgen2/Release/net8.0/fedora.42-x64/S.P.C.tmp
}
The managed DLL bound to this executable is: 'c3ab8ff13720e8ad9047dd39466b3c8974e592c2fa383d4a3960714caef0c4f2'
Detected Single-File app bundle
Using internal fxr
Invoking fx resolver [dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/crossgen2_publish/x64/Release/fedora.42-x64/publish/] hostfxr_main_bundle_startupinfo
Host path: [dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/crossgen2_publish/x64/Release/fedora.42-x64/publish/crossgen2]
Dotnet path: [dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/crossgen2_publish/x64/Release/fedora.42-x64/publish/]
App path: [dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/crossgen2_publish/x64/Release/fedora.42-x64/publish/c3ab8ff13720e8ad9047dd39466b3c8974e592c2fa383d4a3960714caef0c4f2]
Bundle Header Offset: [99398693]
--- Invoked hostfxr_main_bundle_startupinfo [version: 8.0.10 @Commit: 81cabf2857a01351e5ab578947c7403a5b128ad1]
Mapped application bundle
Unmapped application bundle
Single-File bundle details:
DepsJson Offset:[5ec8f80] Size[24a5]
RuntimeConfigJson Offset:[4f4f5a8] Size[5b4]
.net core 3 compatibility mode: [No]
--- Executing in a native executable mode...
Using dotnet root path [dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/crossgen2_publish/x64/Release/fedora.42-x64/publish/]
App runtimeconfig.json from [dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/crossgen2_publish/x64/Release/fedora.42-x64/publish/c3ab8ff13720e8ad9047dd39466b3c8974e592c2fa383d4a3960714caef0c4f2]
Runtime config is cfg=dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/crossgen2_publish/x64/Release/fedora.42-x64/publish/c3ab8ff13720e8ad9047dd39466b3c8974e592c2fa383d4a3960714caef0c4f2.runtimeconfig.json dev=dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/crossgen2_publish/x64/Release/fedora.42-x64/publish/c3ab8ff13720e8ad9047dd39466b3c8974e592c2fa383d4a3960714caef0c4f2.runtimeconfig.dev.json
Attempting to read dev runtime config: dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/crossgen2_publish/x64/Release/fedora.42-x64/publish/c3ab8ff13720e8ad9047dd39466b3c8974e592c2fa383d4a3960714caef0c4f2.runtimeconfig.dev.json
Attempting to read runtime config: dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/crossgen2_publish/x64/Release/fedora.42-x64/publish/c3ab8ff13720e8ad9047dd39466b3c8974e592c2fa383d4a3960714caef0c4f2.runtimeconfig.json
Mapped bundle for [dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/crossgen2_publish/x64/Release/fedora.42-x64/publish/c3ab8ff13720e8ad9047dd39466b3c8974e592c2fa383d4a3960714caef0c4f2.runtimeconfig.json]
Unmapped application bundle
Runtime config [dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/crossgen2_publish/x64/Release/fedora.42-x64/publish/c3ab8ff13720e8ad9047dd39466b3c8974e592c2fa383d4a3960714caef0c4f2.runtimeconfig.json] is valid=[1]
Executing as a self-contained app as per config file [dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/crossgen2_publish/x64/Release/fedora.42-x64/publish/c3ab8ff13720e8ad9047dd39466b3c8974e592c2fa383d4a3960714caef0c4f2.runtimeconfig.json]
Using internal hostpolicy
Reading from host interface version: [0x16041101:248] to initialize policy version: [0x16041101:248]
Mapped application bundle
Unmapped application bundle
--- Invoked hostpolicy [version: 8.0.10 @Commit: 81cabf2857a01351e5ab578947c7403a5b128ad1] corehost_main = {
dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/crossgen2_publish/x64/Release/fedora.42-x64/publish/crossgen2
dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/coreclr/linux.x64.Release/IL/System.Private.CoreLib.dll
--out
dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/obj/Microsoft.NETCore.App.Crossgen2/Release/net8.0/fedora.42-x64/S.P.C.tmp
}
Mode: apphost
Deps file: 
Managed application [c3ab8ff13720e8ad9047dd39466b3c8974e592c2fa383d4a3960714caef0c4f2] not found in single-file bundle
Failed to locate managed application [otnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/crossgen2_publish/x64/Release/fedora.42-x64/publish/c3ab8ff13720e8ad9047dd39466b3c8974e592c2fa383d4a3960714caef0c4f2]

On CentOS Stream 10, the VMR is built successfully, but the produced SDK fails to run with similar symptoms.

Reproduction Steps

On Fedora:

$ fedpkg clone -a dotnet8.0
$ cd dotnet8.0
$ fedpkg --namespace rpms --name dotnet8.0 --release eln mockbuild --no-cleanup-after

Expected behavior

.NET builds

Actual behavior

VMR fails to build, or the generated SDK is broken.

Regression?

Yes.

I don't see this behaviour on Fedora 41, or CentOS Stream 8 or 9.

Known Workarounds

No response

Configuration

$ clang --version
clang version 19.1.0 (Fedora 19.1.0-1.eln143)
Target: x86_64-redhat-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Configuration file: /etc/clang/x86_64-redhat-linux-gnu-clang.cfg

Other information

I had to port #109198 first, to build against clang 19. But clang 19 is also used on Fedora 41, and that doesn't show the same issue.

Copy link
Contributor

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

@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label Nov 7, 2024
@elinor-fung
Copy link
Member

The managed DLL bound to this executable is: 'c3ab8ff13720e8ad9047dd39466b3c8974e592c2fa383d4a3960714caef0c4f2'

That is the placeholder that should get replaced by the SDK during build:

#define EMBED_HASH_HI_PART_UTF8 "c3ab8ff13720e8ad9047dd39466b3c89" // SHA-256 of "foobar" in UTF-8
#define EMBED_HASH_LO_PART_UTF8 "74e592c2fa383d4a3960714caef0c4f2"

// Re-write the destination apphost with the proper contents.
BinaryUtils.SearchAndReplace(accessor, AppBinaryPathPlaceholderSearchValue, appPathBytes);

We do explicitly check whether the placeholder value is the same though, so I am confused as to why we don't hit this check:

// Check if the value is the same as the placeholder
// Since the single static string is replaced by editing the executable, a reference string is needed to do the compare.
// So use two parts of the string that will be unaffected by the edit.
size_t hi_len = (sizeof(hi_part) / sizeof(hi_part[0])) - 1;
size_t lo_len = (sizeof(lo_part) / sizeof(lo_part[0])) - 1;
if (binding.size() >= (hi_len + lo_len)
&& binding.compare(0, hi_len, &hi_part[0]) == 0
&& binding.compare(hi_len, lo_len, &lo_part[0]) == 0)
{
trace::error(_X("This executable is not bound to a managed DLL to execute. The binding value is: '%s'"), app_dll->c_str());
return false;
}

It seems like on those platforms, the crossgen2 executable is somehow (reported as) successfully produced, but without actually updating the placeholder? Do you have a binlog for the build/publish of crossgen2 itself?

@omajid
Copy link
Member Author

omajid commented Nov 20, 2024

It seems like on those platforms, the crossgen2 executable is somehow (reported as) successfully produced, but without actually updating the placeholder?

Yes, I think so. This is a VMR build, so looking for the placeholder value shows apphost and singlefilehost (which are expected), and also crossgen2 (unexpected). There's also /builddir/build/BUILD/dotnet8.0-8.0.110-build/dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/obj/coreclr/crossgen2_publish/x64/Release/singlefilehost which, if I am reading the binlog right, is the intermediate (?) apphost for crossgen2.

# grep -rF c3ab8ff13720e8ad9047dd39466b3c8974e592c2fa383d4a3960714caef0c4f2 ./build/BUILD/dotnet8.0-8.0.110-build/dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts
grep: ./build/BUILD/dotnet8.0-8.0.110-build/dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/obj/Microsoft.NETCore.App.Host/Release/net8.0/fedora.42-x64/output/packs/Microsoft.NETCore.App.Host.fedora.42-x64/8.0.10/runtimes/fedora.42-x64/native/apphost: binary file matches
grep: ./build/BUILD/dotnet8.0-8.0.110-build/dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/obj/Microsoft.NETCore.App.Host/Release/net8.0/fedora.42-x64/output/packs/Microsoft.NETCore.App.Host.fedora.42-x64/8.0.10/runtimes/fedora.42-x64/native/singlefilehost: binary file matches
grep: ./build/BUILD/dotnet8.0-8.0.110-build/dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/obj/coreclr/crossgen2_publish/x64/Release/singlefilehost: binary file matches
grep: ./build/BUILD/dotnet8.0-8.0.110-build/dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/obj/coreclr/linux.x64.Release/Corehost.Static/CMakeFiles/singlefilehost.dir/builddir/build/BUILD/dotnet8.0-8.0.110-build/dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/src/native/corehost/corehost.cpp.o: binary file matches
grep: ./build/BUILD/dotnet8.0-8.0.110-build/dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/obj/coreclr/linux.x64.Release/Corehost.Static/singlefilehost: binary file matches
grep: ./build/BUILD/dotnet8.0-8.0.110-build/dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/obj/fedora.42-x64.Release/apphost/standalone/CMakeFiles/apphost.dir/__/__/corehost.cpp.o: binary file matches
grep: ./build/BUILD/dotnet8.0-8.0.110-build/dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/obj/fedora.42-x64.Release/apphost/standalone/apphost: binary file matches
grep: ./build/BUILD/dotnet8.0-8.0.110-build/dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/coreclr/linux.x64.Release/corehost/singlefilehost: binary file matches
grep: ./build/BUILD/dotnet8.0-8.0.110-build/dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/fedora.42-x64.Release/corehost/singlefilehost: binary file matches
grep: ./build/BUILD/dotnet8.0-8.0.110-build/dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/fedora.42-x64.Release/corehost/apphost: binary file matches
grep: ./build/BUILD/dotnet8.0-8.0.110-build/dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/Microsoft.NETCore.App.Crossgen2/Release/net8.0/fedora.42-x64/crossgen2: binary file matches
grep: ./build/BUILD/dotnet8.0-8.0.110-build/dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/crossgen2_publish/x64/Release/crossgen2: binary file matches
grep: ./build/BUILD/dotnet8.0-8.0.110-build/dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/bin/crossgen2_publish/x64/Release/fedora.42-x64/publish/crossgen2: binary file matches

Do you have a binlog for the build/publish of crossgen2 itself?

Here's the binlog of the VMR. The VMR produces this broken crossgen2 that then fails to run: https://people.redhat.com/~omajid/scratch/crossgen2-placeholder-sourcebuild.binlog

This was built using a source-built SDK itself. That SDK can produce an mkdir foobar && cd foobar && dotnet new console && dotnet run && bin/Debug/net8.0/foobar without problems.

@agocke agocke added this to the 10.0.0 milestone Nov 21, 2024
@agocke agocke removed the untriaged New issue has not been triaged by the area owner label Nov 21, 2024
@elinor-fung
Copy link
Member

I can't open that binlog for some reason. I get System.IO.InvalidDataException: Found invalid data while decoding when trying to open it in the latest MSBuild log viewer.

There's also /builddir/build/BUILD/dotnet8.0-8.0.110-build/dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/obj/coreclr/crossgen2_publish/x64/Release/singlefilehost which, if I am reading the binlog right, is the intermediate (?) apphost for crossgen2.

Yes, that is the intermediate apphost for crossgen2. That is what should have the app name instead of the placeholder in the binary (it just gets copied to the output directory). In the correct/working case, we should have already updated the bytes in our memory mapped view of the original apphost before writing it to that obj/ location:

// Transform the host file in-memory.
RewriteAppHost(memoryMappedViewAccessor);
// Save the transformed host.
using (FileStream fileStream = new FileStream(appHostDestinationFilePath, FileMode.Create))

I would expect for there to be some failure / exception thrown if we failed to find/update the placeholder in the memory mapped view though.

Is there anything different with access/permissions for the crossgen2 intermediate output (./build/BUILD/dotnet8.0-8.0.110-build/dotnet-8.0.10/src/runtime/artifacts/source-build/self/src/artifacts/obj/coreclr/crossgen2_publish/x64/Release/) versus other folders?

Does the source-built SDK itself produce a self-contained single-file dotnet publish --sc /p:PublishSelfContained=true that runs fine?

I don't see this behaviour on Fedora 41, or CentOS Stream 8 or 9.

I wonder if there's something different with memory mapping files that what we are doing isn't working properly with. That's the part of the sequence of 'memory map the original, search/replace in private memory mapped view, then write to output' that seems like it might be affected by an OS upgrade.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

No branches or pull requests

3 participants