Assertion failed 'lastBlockILEndOffset < beginOffs' #99543
Comments
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
dotnet-policy-service
bot
added
the
untriaged
|
@TIHan PTAL. |
|
Will do |
JulieLeeMSFT
removed
the
untriaged
|
For |
|
@filipnavara , your JIT dump link is giving a 404 - I guess GitHub got messed up? |
|
This assertion occurs even in a December 2023 commit - so it's likely been this way for a while. |
|
Dump from one of the x64 assertions: Edit: Ok, so GitHub is showing 404 for 'dump.txt' even when uploading new files. |
|
I suspected it's not x86 specific. Thanks for looking into it. |
|
@TIHan can you give a short description of what the problem is and where in the JIT it happens? |
|
For JIT debug compilations, when code-gen'ing a basic block, if there was a previous block, we expect its ending IL offset to be less than the current block's beginning IL offset. These IL offsets and blocks themselves correspond to user code. However, the JIT can create new basic blocks on its own that don't correspond to user code, in which case the new block needs to be marked with the The issue here is that some blocks that are marked with https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/fgbasic.cpp#L4810 IL_OFFSET splitPointILOffset = fgFindBlockILOffset(newBlock);
curr->bbCodeOffsEnd = max(curr->bbCodeOffs, splitPointILOffset);
newBlock->bbCodeOffs = min(splitPointILOffset, newBlock->bbCodeOffsEnd);
newBlock->bbCodeOffs = min(splitPointILOffset, newBlock->bbCodeOffsEnd);causes |
Can you share the dump? For debug code if we have statements with IL offsets, it seems like the blocks they are in should also have IL offsets. Seems like that means that |
|
You should be able to get the dump, GitHub is working again it looks like.
|
|
I am trying to determine what the right fix looks like. It seems like the root cause is that we are putting IL-offset carrying statements into blocks that are marked as So one possible fix is to stop putting IL offset carrying statements into internal blocks, by making sure the blocks are not marked as internal, and getting the offsets right. Another possible fix is to erase the debug info (at least from the block), which more or less what you're proposing. If we go this route, I think we should examine debug emission and make sure nothing is getting lost. Whatever direction we go in we should update the post-phase diagnostic checker so it spots these problems right away. Can you look at the first option? Things seem ok here: but not just after (seemingly BB19 is the troublemaker, so something in this expansion is not treating debug offsets the way it should). |
Sure, I can look. |
|
The BFF_INTERNAL blocks are initially created in the @AndyAyersMS Should we unmark BFF_INTERNAL from these new blocks since they will contain statements with valid IL offsets? It won't fix the issue if we do. Still looking into what is going on with the offsets. |
|
If we are required to duplicate user statements (looks like we are) then some options are:
Whichever way we go we should clarify the behavior of the jit with respect to internal blocks. For instance, we might consider to enforcing the invariant that internal blocks and their statements do not have IL offsets, or (perhaps simpler) that internal blocks do not have IL offsets and we ignore any IL offsets for statements inside (for purposes of debug emission). |
|
AFAIK, the debug format should allow to map multiple ranges, so I think it's fine that we copy user statements around. I did a lot of investigation into this issue. I believe the problem really is how we are updating the IL offsets in I tweaked the original solution in #99662 where instead of checking for BBF_INTERNAL, it will check if the original block's ending offset was BAD_IL_OFFSET. If it was, then we do not update the IL offsets. |
|
Does this mean we may lose a bit of debugging fidelity? Since this is for scopes then impact might be that at certain breakpoints or stepping, locals that should be visible suddenly are not? Should we add a diagnostic check that no BBF_INTERNAL block has valid IL offsets? |
|
If it is common to have blocks that have its ending offset set to BAD_IL_OFFSET and contain statements that have valid IL offsets, then maybe. Another solution is to set the block's ending offset to BAD_IL_OFFSET only in expanding static init call. This would limit any risk to losing fidelity. |
|
I made a compromise. I am now updating the IL offsets in Before: After: We actually gain some IL offsets here for few a few blocks. The only block that appears to lose fidelity is BB07 - which its internal statement gets modified in Before After |
Building
Loader\classloader\StaticVirtualMethods\GenericContext\GenericContextTestin NativeAOT win-x86 Debug mode yields:Native stack trace:
JIT dump for
TestEntrypoint:Test_Ldftn_GenericOverTypeParameterGenericValuetype_GenericOverString_CuriouslyRecurringGeneric_GenericMethodOverTypeParameter:GenericContextTest.txt
The text was updated successfully, but these errors were encountered: