Skip to content

Triage for dotnet/runtime#116698 by rolfbjarne - Creating the native http handler throws BadImageFormatException #1134

Open
@MihuBot

Description

@MihuBot

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 of UnsafeAccessorType.
  • Relevance: Demonstrates that incorrect or invalid usage of UnsafeAccessorType can lead to runtime failures, including BadImageFormatException 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) throws BadImageFormatException: 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 of UnsafeAccessorAttribute (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) throws BadImageFormatException. 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 in BadImageFormatException.

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 throws BadImageFormatException 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 of UnsafeAccessorType 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

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions