[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.

[VSadov]

It looks like this may be the last unaccounted failure when enabling runtime async in Libraries.

It reproduces only with -lc Debug, but with that the failure is fairly common.
If I comment out the hack marked with HACK: Not sure why it can happen, but we may see the end IL for the block and then run tests locally like:

build.cmd clr+libs+libs.tests -rc checked -lc Debug -test

I see 16 test failures with assert like:

  Assert failure(PID 33524 [0x000082f4], Thread: 41136 [0xa0b0]): Assertion failed 'lastBlockILEndOffset < beginOffs' in 'System.Linq.Tests.MinAsyncTests:EmptyInputs_NonNullable_Throws():this' during 'Generate code' (IL size 423; hash 0x427db034; MinOpts)
  
      File: E:\dotnet004\runtime\src\coreclr\jit\scopeinfo.cpp:1566
      Image: E:\dotnet004\runtime\artifacts\bin\testhost\net10.0-windows-Debug-x64\dotnet.exe

[jakobbotsch]

Thanks, I will try those instructions to reproduce the issue. I never use -lc debug and that's probably important for this repro.

BTW: if you are able to repro JIT asserts locally then collecting superpmi collection will help us debug the issues very quickly. To do that set

DOTNET_JitPath=<path to superpmi-shim-collector.dll in CORE_ROOT>
SuperPMIShimPath=<path to clrjit.dll in CORE_ROOT>
SuperPMIShimLogPath=<path to an empty directory>

When you run the tests with this config it should create .mc files inside the directory you specified to SuperPMIShimLogPath, and those can be shared for a self-contained repro of the issue.

[jakobbotsch]

This was fixed by #120303