-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Comments
Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov |
That is the placeholder that should get replaced by the SDK during build: runtime/src/native/corehost/corehost.cpp Lines 39 to 40 in 075b42d
runtime/src/installer/managed/Microsoft.NET.HostModel/AppHost/HostWriter.cs Lines 90 to 91 in 075b42d
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: runtime/src/native/corehost/corehost.cpp Lines 71 to 82 in 075b42d
It seems like on those platforms, the |
Yes, I think so. This is a VMR build, so looking for the placeholder value shows
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 |
I can't open that binlog for some reason. I get
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: runtime/src/installer/managed/Microsoft.NET.HostModel/AppHost/HostWriter.cs Lines 87 to 91 in 9cb3b72
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
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. |
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:
Trying to trace this shows:
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.
The text was updated successfully, but these errors were encountered: