Skip to content

Exception handling not working correctly with InlinedCallFrames #34524

Description

@fadimounir

This bug was discovered based on the GC-Stress results I got from #33733

What's very interesting about it is that I wasn't able to see failing results (on Windows at least) in the Helix gcstress runs using the master branch (twice), however I can consistently and easily reproduce the failures locally.

The main issue here is a disconnect between what the JIT produces, and the assumption we had around it in the EH code:
https://github.com/dotnet/runtime/blob/master/src/coreclr/src/vm/exceptionhandling.cpp#L1824

Clearly this is not what the JIT does:
https://github.com/dotnet/runtime/blob/master/src/coreclr/src/jit/lower.cpp#L3497

This means that it is not correct to limit this define to only 32-bit targets:
https://github.com/dotnet/runtime/blob/master/src/coreclr/src/vm/exceptionhandling.h#L16

To fix this issue, we should have one standard for all targets (which is the case today anyways): The ICF is always initialized and linked in the prolog of any method that contains PInvokes, and unlinked at the method epilog for jitted code (R2R is a slightly different story)

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

GCStressarea-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMIarea-ExceptionHandling-coreclronly use for closed issuestenet-reliabilityReliability/stability related issue (stress, load problems, etc.)

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions