[RuntimeAsync] Assertion failed 'lastBlockILEndOffset < beginOffs'

[VSadov]

Observed while enabling rt async in Libraires partition - #119432

There is code in CreateCheckAndSuspendAfterCall that splits the basic block that contains await. Somehow when the splitting operation infers the IL range for the shortened block, it may end up with longer IL range than before shortening, thus overlapping with the IL range of the splitted-off remainder block.

This can trigger asserts later on when introducing scopes for untracked locals.

There is a hack/workaround in 6a29721

that illustrates/suppresses the issue, but that is not a fix.

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[MihuBot]

I'm a bot. Here is a possible related and/or duplicate issue (I may be wrong):

• Assertion failed 'lastBlockILEndOffset < beginOffs' #99543

[VSadov]

I suspect this is a symptom of the same issue that breaks VisualStudio debugger when async methods are on the stack. There is something wrong with the sequence points.

When I try to debug and there is an async method frame is present on stack, sometimes I get asserts like _ASSERTE(m_sequenceMapSorted); , but most of the time debugger just stops working claiming no managed code present on the stack.

Basically - I can still hit breakpoints, but can't see anything at a point of a break if there is something async up the chain.

I can still add Debug.Writeline(Environment.StackTrace) at the points of interest and at least see the stack in debug output, but that is not as good as if debugger worked.

[jakobbotsch]

When I try to debug and there is an async method frame is present on stack, sometimes I get asserts like _ASSERTE(m_sequenceMapSorted); , but most of the time debugger just stops working claiming no managed code present on the stack.

Do you have a small code example with instructions on where to breakpoint to reproduce something like that?

I am not saying the issue is unrelated, but I think it is unlikely to be related -- the JIT does not use block IL offsets to emit IL offset mappings at all, those are stored in a different way as markers in the inline IR stream.

The _ASSERTE hitting is strange since the debugger side is the one that does the sort. I would expect it gets confused by the presence of more epilogs in some way.

[VSadov]

Also this particular assert (in this PR) does not happen for every async method. It is actually relatively rare (perhaps needs an await in a try or something like that). But the debugging is always or nearly always impacted - more often than this assert would show up. So it is probably something else.

As a repro - I just debug Libraries tests with async enabled and often I do not see stack trace or anything at breakpoints. It looks like it correlates with async methods on stack. (or maybe it is thunks or Resume stubs that upset debugger? ...)

I will check if regular async tests have similar issues, or if repro needs to be something more complex.