Open
Description
Triage for dotnet/runtime#116698.
dotnet/runtime#116698: Creating the native http handler throws BadImageFormatException by rolfbjarne
[Tool] Searching for BadImageFormatException UnsafeAccessorAttribute, HttpClientHandler CreateNativeHandler BadImageFormatException, System.Net.Http UnsafeAccessorAttribute, HttpClientHandler CallNative UnsafeAccessorType (IncludeOpen=True, IncludeClosed=True, IncludeIssues=True, IncludePullRequests=True, Repository=dotnet/runtime)
[Tool] Found 44 issues, 18 comments, 44 returned results (9373 ms)
[Tool] Obtained 8 comments for issue #116676: UnsafeAccessorType targeting non-existing type crashing on Linux
[Tool] Obtained 44 comments for issue #115583: Use UnsafeAccessorType in System.Private.CoreLib and the BCL
[Tool] Obtained 133 comments for issue #114881: Implementation for `UnsafeAccessorTypeAttribute`
Here are related issues and discussions for triage of issue #116698 ("Creating the native http handler throws BadImageFormatException"):
1. Issue #116676 (June 2025) - "UnsafeAccessorType targeting non-existing type crashing on Linux"
- Summary: This issue reports a crash (not a clean exception) when an
UnsafeAccessorType
references a non-existent type. The crash occurs after many iterations, with no error message, on Linux and macOS. The discussion involves deep debugging of exception handling and stack unwinding in the runtime, with several comments from core runtime engineers (e.g., @janvorli, @AaronRobinsonMSFT, @jkotas). The root cause is related to how exceptions are propagated and handled when type resolution fails in the context ofUnsafeAccessorType
. - Relevance: Demonstrates that incorrect or invalid usage of
UnsafeAccessorType
can lead to runtime failures, includingBadImageFormatException
or even process crashes, depending on the scenario and platform.
2. PR #115583 (May–June 2025) - "Use UnsafeAccessorType in System.Private.CoreLib and the BCL"
- Summary: This PR migrates internal usage in the BCL to the new
UnsafeAccessorTypeAttribute
, replacing older reflection-based approaches. The discussion includes details about the attribute's design, limitations (e.g., generic support), and type safety. There are questions about how to represent certain types (e.g., generics, byrefs) and how the attribute interacts with the trimmer and NativeAOT. - Relevance: The PR is likely the source of the breaking change referenced in #116698. The comments confirm that the new attribute is stricter and can throw
BadImageFormatException
for invalid usage, such as mismatched signatures or unsupported type references. There is also discussion about the need for exact type names and the limitations of the current implementation.
3. PR #114881 (April–May 2025) - "Implementation for UnsafeAccessorTypeAttribute"
- Summary: This PR implements the
UnsafeAccessorTypeAttribute
feature. The discussion covers the attribute's syntax, type safety, generic support, and error handling. There is extensive debate about how to handle byrefs, generics, and type resolution, as well as the kinds of exceptions that should be thrown for invalid usage (e.g.,TypeLoadException
,BadImageFormatException
). - Relevance: The implementation details and design discussions here directly inform the behavior seen in #116698. The PR confirms that invalid usage of the attribute (such as mismatched types or signatures) will result in
BadImageFormatException
at runtime.
4. Issue #105738 (July–August 2024) - "Using UnsafeAccessorAttribute throws BadImageFormatException on .NET9-preview6"
- Summary: Reports that using
UnsafeAccessorAttribute
incorrectly (e.g., on a struct or with a mismatched signature) throwsBadImageFormatException: Invalid usage of UnsafeAccessorAttribute.
The issue was resolved as a user error: after cleaning the build output, the problem disappeared. - Relevance: Confirms that
BadImageFormatException
is the expected failure mode for invalid usage ofUnsafeAccessorAttribute
(and by extension,UnsafeAccessorTypeAttribute
). Also highlights that stale build artifacts can cause or mask these errors.
5. Issue #102151 (May 2024) - "Using UnsafeAccessorAttribute (.NET 8) on struct throws 'System.BadImageFormatException'"
- Summary: Reports that using
UnsafeAccessorAttribute
on a struct (instead of a class) throwsBadImageFormatException
. The workaround is to cast the struct to a dummy class. - Relevance: Another example of how signature mismatches or unsupported usage patterns with
UnsafeAccessorAttribute
result inBadImageFormatException
.
6. PR #55384 (July 2021) - "Include native underlying handler support in HttpClientHandler for iOS/tvOS/MacCatalyst and Android"
- Summary: This PR introduced the infrastructure for native HTTP handlers on mobile platforms, which is the code path affected by the recent changes. The comments discuss handler selection and platform-specific behaviors.
- Relevance: Provides context for the code path in question and the importance of correct handler instantiation.
Key Takeaways for Triage
- The error in #116698 is a direct result of stricter validation in the new
UnsafeAccessorTypeAttribute
implementation, which now throwsBadImageFormatException
for invalid usage. - The most likely cause is a signature mismatch or incorrect usage of the attribute in the native handler creation code, as suspected by the issue author.
- The correct fix is to ensure that the
CallNative
method's signature and its use ofUnsafeAccessorType
exactly match the expected native handler type, as the user suggests in their code snippet. - This is a breaking change introduced by the recent PRs implementing and adopting
UnsafeAccessorTypeAttribute
in the BCL.
Actionable References
- PR #115583 and PR #114881: Review for the exact requirements and examples of correct usage of
UnsafeAccessorTypeAttribute
. - Issues #105738, #102151: Reference for expected failure modes and user workarounds.
- Issue #116676: For deeper runtime implications and platform-specific behaviors.
If you need more details on any of these issues or PRs, let me know!
Metadata
Metadata
Assignees
Labels
No labels