Unconditionally skip GC reporting for non-interruptible aborted methods

[jkotas]

Fixes#119363

[Copilot]

Pull Request Overview

This PR fixes issue #119363 by unconditionally skipping GC reporting for non-interruptible aborted methods. The change simplifies the logic for handling execution-aborted methods in the GC info decoder by removing unnecessary conditional checks and variable declarations.

Key changes:

• Removes the noTrackedRefs variable and associated logic that was never actually used
• Moves the countIntersections variable declaration outside the conditional block to ensure proper scoping
• Fixes incorrect brace placement that was causing logic errors in the interruptible ranges handling

[jkotas]

This is reverting part of https://github.com/dotnet/coreclr/pull/9869/files#diff-e5013db5f0394027d19785d4928e535fb1157889556c72677037bd39e20d27ebR660 .

@dotnet/jit-contrib Could you please validate that the JIT does not depend on the behavior that's being reverted here?

[jkotas]

I see number of tests failing with:

 Starting: ComInterfaceGenerator.Unit.Tests (parallel test collections = on [2 threads], stop on fail = off)
ASSERT FAILED
Expression: executionAborted
Location: line 812 in /__w/1/s/src/coreclr/vm/gcinfodecoder.cpp
Function: EnumerateLiveSlots
Process: 34
[createdump] Gathering state for process 34 dotnet

so the JIT GC info emission depends on the code being deleted.

It seems that m_NumInterruptibleRanges == 0 meaning is overloaded. The original meaning was what its name says "no interruptible ranges".

dotnet/coreclr#9869 overloaded it to mean "or untracked slots only". It sounds like that we may want to have a separate state for "untracked slots only" to disambiguate these two cases. Does it sound right?

[AndyAyersMS]

Is it that the method in the issue (and the repro) have only call site safe points and so maybe no interruptible ranges, and the skip reporting logic only kicks in for aborted frames with interruptible ranges, so we end up reporting when we shouldn't?

[jkotas]

Is it that the method in the issue (and the repro) have only call site safe points

I do not think that the existence of call site safe points is necessary to hit the bug. We may skip reporting of the callsites in the special noTrackedGCSlots mode, so the method can have calls but no reported callsites in GC info

no interruptible ranges, and the skip reporting logic only kicks in for aborted frames with interruptible ranges, so we end up reporting when we shouldn't?

Right, this is the problem. My latest commit is tweaking the condition to skip the reporting even with no interruptible ranges.

[AndyAyersMS]

Latest version looks reasonable to me.

Do you think this has gone unnoticed for years because it's rare to have GC in the middle of EH handling, so there's just a small window where this can cause trouble?

[jkotas]

/azp run runtime-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

/azp run runtime-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

it's rare to have GC in the middle of EH handling, so there's just a small window where this can cause trouble?

Yes, I think it is that combined with the specific structure required to hit the bug (untracked slots + no interruptible regions, untracked slot is not yet initialized when the exception is thrown).

[jkotas]

I have added your test and validated that the test fails as expected before the fix.

[jkotas]

/azp run runtime-coreclr gcstress-extra, runtime-coreclr gcstress0x3-gcstress0xc

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[jkotas]

Fixes#119363

[Copilot]

Pull Request Overview

This PR fixes issue #119363 by unconditionally skipping GC reporting for non-interruptible aborted methods. The change simplifies the logic for handling execution-aborted methods in the GC info decoder by removing unnecessary conditional checks and variable declarations.

Key changes:

• Removes the noTrackedRefs variable and associated logic that was never actually used
• Moves the countIntersections variable declaration outside the conditional block to ensure proper scoping
• Fixes incorrect brace placement that was causing logic errors in the interruptible ranges handling

[jkotas]

This is reverting part of https://github.com/dotnet/coreclr/pull/9869/files#diff-e5013db5f0394027d19785d4928e535fb1157889556c72677037bd39e20d27ebR660 .

@dotnet/jit-contrib Could you please validate that the JIT does not depend on the behavior that's being reverted here?

[jkotas]

I see number of tests failing with:

 Starting: ComInterfaceGenerator.Unit.Tests (parallel test collections = on [2 threads], stop on fail = off)
ASSERT FAILED
Expression: executionAborted
Location: line 812 in /__w/1/s/src/coreclr/vm/gcinfodecoder.cpp
Function: EnumerateLiveSlots
Process: 34
[createdump] Gathering state for process 34 dotnet

so the JIT GC info emission depends on the code being deleted.

It seems that m_NumInterruptibleRanges == 0 meaning is overloaded. The original meaning was what its name says "no interruptible ranges".

dotnet/coreclr#9869 overloaded it to mean "or untracked slots only". It sounds like that we may want to have a separate state for "untracked slots only" to disambiguate these two cases. Does it sound right?

[AndyAyersMS]

Is it that the method in the issue (and the repro) have only call site safe points and so maybe no interruptible ranges, and the skip reporting logic only kicks in for aborted frames with interruptible ranges, so we end up reporting when we shouldn't?

[jkotas]

Is it that the method in the issue (and the repro) have only call site safe points

I do not think that the existence of call site safe points is necessary to hit the bug. We may skip reporting of the callsites in the special noTrackedGCSlots mode, so the method can have calls but no reported callsites in GC info

no interruptible ranges, and the skip reporting logic only kicks in for aborted frames with interruptible ranges, so we end up reporting when we shouldn't?

Right, this is the problem. My latest commit is tweaking the condition to skip the reporting even with no interruptible ranges.

[AndyAyersMS]

Latest version looks reasonable to me.

Do you think this has gone unnoticed for years because it's rare to have GC in the middle of EH handling, so there's just a small window where this can cause trouble?

[jkotas]

/azp run runtime-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

/azp run runtime-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

it's rare to have GC in the middle of EH handling, so there's just a small window where this can cause trouble?

Yes, I think it is that combined with the specific structure required to hit the bug (untracked slots + no interruptible regions, untracked slot is not yet initialized when the exception is thrown).

[jkotas]

I have added your test and validated that the test fails as expected before the fix.

[jkotas]

/azp run runtime-coreclr gcstress-extra, runtime-coreclr gcstress0x3-gcstress0xc

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[jkotas]

Fixes#119363

[Copilot]

Pull Request Overview

This PR fixes issue #119363 by unconditionally skipping GC reporting for non-interruptible aborted methods. The change simplifies the logic for handling execution-aborted methods in the GC info decoder by removing unnecessary conditional checks and variable declarations.

Key changes:

• Removes the noTrackedRefs variable and associated logic that was never actually used
• Moves the countIntersections variable declaration outside the conditional block to ensure proper scoping
• Fixes incorrect brace placement that was causing logic errors in the interruptible ranges handling

[jkotas]

This is reverting part of https://github.com/dotnet/coreclr/pull/9869/files#diff-e5013db5f0394027d19785d4928e535fb1157889556c72677037bd39e20d27ebR660 .

@dotnet/jit-contrib Could you please validate that the JIT does not depend on the behavior that's being reverted here?

[jkotas]

I see number of tests failing with:

 Starting: ComInterfaceGenerator.Unit.Tests (parallel test collections = on [2 threads], stop on fail = off)
ASSERT FAILED
Expression: executionAborted
Location: line 812 in /__w/1/s/src/coreclr/vm/gcinfodecoder.cpp
Function: EnumerateLiveSlots
Process: 34
[createdump] Gathering state for process 34 dotnet

so the JIT GC info emission depends on the code being deleted.

It seems that m_NumInterruptibleRanges == 0 meaning is overloaded. The original meaning was what its name says "no interruptible ranges".

dotnet/coreclr#9869 overloaded it to mean "or untracked slots only". It sounds like that we may want to have a separate state for "untracked slots only" to disambiguate these two cases. Does it sound right?

[AndyAyersMS]

Is it that the method in the issue (and the repro) have only call site safe points and so maybe no interruptible ranges, and the skip reporting logic only kicks in for aborted frames with interruptible ranges, so we end up reporting when we shouldn't?

[jkotas]

Is it that the method in the issue (and the repro) have only call site safe points

I do not think that the existence of call site safe points is necessary to hit the bug. We may skip reporting of the callsites in the special noTrackedGCSlots mode, so the method can have calls but no reported callsites in GC info

no interruptible ranges, and the skip reporting logic only kicks in for aborted frames with interruptible ranges, so we end up reporting when we shouldn't?

Right, this is the problem. My latest commit is tweaking the condition to skip the reporting even with no interruptible ranges.

[AndyAyersMS]

Latest version looks reasonable to me.

Do you think this has gone unnoticed for years because it's rare to have GC in the middle of EH handling, so there's just a small window where this can cause trouble?

[jkotas]

/azp run runtime-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

/azp run runtime-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

it's rare to have GC in the middle of EH handling, so there's just a small window where this can cause trouble?

Yes, I think it is that combined with the specific structure required to hit the bug (untracked slots + no interruptible regions, untracked slot is not yet initialized when the exception is thrown).

[jkotas]

I have added your test and validated that the test fails as expected before the fix.

[jkotas]

/azp run runtime-coreclr gcstress-extra, runtime-coreclr gcstress0x3-gcstress0xc

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[jkotas]

Fixes#119363

[Copilot]

Pull Request Overview

This PR fixes issue #119363 by unconditionally skipping GC reporting for non-interruptible aborted methods. The change simplifies the logic for handling execution-aborted methods in the GC info decoder by removing unnecessary conditional checks and variable declarations.

Key changes:

• Removes the noTrackedRefs variable and associated logic that was never actually used
• Moves the countIntersections variable declaration outside the conditional block to ensure proper scoping
• Fixes incorrect brace placement that was causing logic errors in the interruptible ranges handling

[jkotas]

This is reverting part of https://github.com/dotnet/coreclr/pull/9869/files#diff-e5013db5f0394027d19785d4928e535fb1157889556c72677037bd39e20d27ebR660 .

@dotnet/jit-contrib Could you please validate that the JIT does not depend on the behavior that's being reverted here?

[jkotas]

I see number of tests failing with:

 Starting: ComInterfaceGenerator.Unit.Tests (parallel test collections = on [2 threads], stop on fail = off)
ASSERT FAILED
Expression: executionAborted
Location: line 812 in /__w/1/s/src/coreclr/vm/gcinfodecoder.cpp
Function: EnumerateLiveSlots
Process: 34
[createdump] Gathering state for process 34 dotnet

so the JIT GC info emission depends on the code being deleted.

It seems that m_NumInterruptibleRanges == 0 meaning is overloaded. The original meaning was what its name says "no interruptible ranges".

dotnet/coreclr#9869 overloaded it to mean "or untracked slots only". It sounds like that we may want to have a separate state for "untracked slots only" to disambiguate these two cases. Does it sound right?

[AndyAyersMS]

Is it that the method in the issue (and the repro) have only call site safe points and so maybe no interruptible ranges, and the skip reporting logic only kicks in for aborted frames with interruptible ranges, so we end up reporting when we shouldn't?

[jkotas]

Is it that the method in the issue (and the repro) have only call site safe points

I do not think that the existence of call site safe points is necessary to hit the bug. We may skip reporting of the callsites in the special noTrackedGCSlots mode, so the method can have calls but no reported callsites in GC info

no interruptible ranges, and the skip reporting logic only kicks in for aborted frames with interruptible ranges, so we end up reporting when we shouldn't?

Right, this is the problem. My latest commit is tweaking the condition to skip the reporting even with no interruptible ranges.

[AndyAyersMS]

Latest version looks reasonable to me.

Do you think this has gone unnoticed for years because it's rare to have GC in the middle of EH handling, so there's just a small window where this can cause trouble?

[jkotas]

/azp run runtime-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

/azp run runtime-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

it's rare to have GC in the middle of EH handling, so there's just a small window where this can cause trouble?

Yes, I think it is that combined with the specific structure required to hit the bug (untracked slots + no interruptible regions, untracked slot is not yet initialized when the exception is thrown).

[jkotas]

I have added your test and validated that the test fails as expected before the fix.

[jkotas]

/azp run runtime-coreclr gcstress-extra, runtime-coreclr gcstress0x3-gcstress0xc

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[jkotas]

Fixes#119363

[Copilot]

Pull Request Overview

This PR fixes issue #119363 by unconditionally skipping GC reporting for non-interruptible aborted methods. The change simplifies the logic for handling execution-aborted methods in the GC info decoder by removing unnecessary conditional checks and variable declarations.

Key changes:

• Removes the noTrackedRefs variable and associated logic that was never actually used
• Moves the countIntersections variable declaration outside the conditional block to ensure proper scoping
• Fixes incorrect brace placement that was causing logic errors in the interruptible ranges handling

[jkotas]

This is reverting part of https://github.com/dotnet/coreclr/pull/9869/files#diff-e5013db5f0394027d19785d4928e535fb1157889556c72677037bd39e20d27ebR660 .

@dotnet/jit-contrib Could you please validate that the JIT does not depend on the behavior that's being reverted here?

[jkotas]

I see number of tests failing with:

 Starting: ComInterfaceGenerator.Unit.Tests (parallel test collections = on [2 threads], stop on fail = off)
ASSERT FAILED
Expression: executionAborted
Location: line 812 in /__w/1/s/src/coreclr/vm/gcinfodecoder.cpp
Function: EnumerateLiveSlots
Process: 34
[createdump] Gathering state for process 34 dotnet

so the JIT GC info emission depends on the code being deleted.

It seems that m_NumInterruptibleRanges == 0 meaning is overloaded. The original meaning was what its name says "no interruptible ranges".

dotnet/coreclr#9869 overloaded it to mean "or untracked slots only". It sounds like that we may want to have a separate state for "untracked slots only" to disambiguate these two cases. Does it sound right?

[AndyAyersMS]

Is it that the method in the issue (and the repro) have only call site safe points and so maybe no interruptible ranges, and the skip reporting logic only kicks in for aborted frames with interruptible ranges, so we end up reporting when we shouldn't?

[jkotas]

Is it that the method in the issue (and the repro) have only call site safe points

I do not think that the existence of call site safe points is necessary to hit the bug. We may skip reporting of the callsites in the special noTrackedGCSlots mode, so the method can have calls but no reported callsites in GC info

no interruptible ranges, and the skip reporting logic only kicks in for aborted frames with interruptible ranges, so we end up reporting when we shouldn't?

Right, this is the problem. My latest commit is tweaking the condition to skip the reporting even with no interruptible ranges.

[AndyAyersMS]

Latest version looks reasonable to me.

Do you think this has gone unnoticed for years because it's rare to have GC in the middle of EH handling, so there's just a small window where this can cause trouble?

[jkotas]

/azp run runtime-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

/azp run runtime-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

it's rare to have GC in the middle of EH handling, so there's just a small window where this can cause trouble?

Yes, I think it is that combined with the specific structure required to hit the bug (untracked slots + no interruptible regions, untracked slot is not yet initialized when the exception is thrown).

[jkotas]

I have added your test and validated that the test fails as expected before the fix.

[jkotas]

/azp run runtime-coreclr gcstress-extra, runtime-coreclr gcstress0x3-gcstress0xc

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[jkotas]

Fixes#119363

[Copilot]

Pull Request Overview

This PR fixes issue #119363 by unconditionally skipping GC reporting for non-interruptible aborted methods. The change simplifies the logic for handling execution-aborted methods in the GC info decoder by removing unnecessary conditional checks and variable declarations.

Key changes:

• Removes the noTrackedRefs variable and associated logic that was never actually used
• Moves the countIntersections variable declaration outside the conditional block to ensure proper scoping
• Fixes incorrect brace placement that was causing logic errors in the interruptible ranges handling

[jkotas]

This is reverting part of https://github.com/dotnet/coreclr/pull/9869/files#diff-e5013db5f0394027d19785d4928e535fb1157889556c72677037bd39e20d27ebR660 .

@dotnet/jit-contrib Could you please validate that the JIT does not depend on the behavior that's being reverted here?

[jkotas]

I see number of tests failing with:

 Starting: ComInterfaceGenerator.Unit.Tests (parallel test collections = on [2 threads], stop on fail = off)
ASSERT FAILED
Expression: executionAborted
Location: line 812 in /__w/1/s/src/coreclr/vm/gcinfodecoder.cpp
Function: EnumerateLiveSlots
Process: 34
[createdump] Gathering state for process 34 dotnet

so the JIT GC info emission depends on the code being deleted.

It seems that m_NumInterruptibleRanges == 0 meaning is overloaded. The original meaning was what its name says "no interruptible ranges".

dotnet/coreclr#9869 overloaded it to mean "or untracked slots only". It sounds like that we may want to have a separate state for "untracked slots only" to disambiguate these two cases. Does it sound right?

[AndyAyersMS]

Is it that the method in the issue (and the repro) have only call site safe points and so maybe no interruptible ranges, and the skip reporting logic only kicks in for aborted frames with interruptible ranges, so we end up reporting when we shouldn't?

[jkotas]

Is it that the method in the issue (and the repro) have only call site safe points

I do not think that the existence of call site safe points is necessary to hit the bug. We may skip reporting of the callsites in the special noTrackedGCSlots mode, so the method can have calls but no reported callsites in GC info

no interruptible ranges, and the skip reporting logic only kicks in for aborted frames with interruptible ranges, so we end up reporting when we shouldn't?

Right, this is the problem. My latest commit is tweaking the condition to skip the reporting even with no interruptible ranges.

[AndyAyersMS]

Latest version looks reasonable to me.

Do you think this has gone unnoticed for years because it's rare to have GC in the middle of EH handling, so there's just a small window where this can cause trouble?

[jkotas]

/azp run runtime-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

/azp run runtime-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

it's rare to have GC in the middle of EH handling, so there's just a small window where this can cause trouble?

Yes, I think it is that combined with the specific structure required to hit the bug (untracked slots + no interruptible regions, untracked slot is not yet initialized when the exception is thrown).

[jkotas]

I have added your test and validated that the test fails as expected before the fix.

[jkotas]

/azp run runtime-coreclr gcstress-extra, runtime-coreclr gcstress0x3-gcstress0xc

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[jkotas]

Fixes#119363

[Copilot]

Pull Request Overview

This PR fixes issue #119363 by unconditionally skipping GC reporting for non-interruptible aborted methods. The change simplifies the logic for handling execution-aborted methods in the GC info decoder by removing unnecessary conditional checks and variable declarations.

Key changes:

• Removes the noTrackedRefs variable and associated logic that was never actually used
• Moves the countIntersections variable declaration outside the conditional block to ensure proper scoping
• Fixes incorrect brace placement that was causing logic errors in the interruptible ranges handling

[jkotas]

This is reverting part of https://github.com/dotnet/coreclr/pull/9869/files#diff-e5013db5f0394027d19785d4928e535fb1157889556c72677037bd39e20d27ebR660 .

@dotnet/jit-contrib Could you please validate that the JIT does not depend on the behavior that's being reverted here?

[jkotas]

I see number of tests failing with:

 Starting: ComInterfaceGenerator.Unit.Tests (parallel test collections = on [2 threads], stop on fail = off)
ASSERT FAILED
Expression: executionAborted
Location: line 812 in /__w/1/s/src/coreclr/vm/gcinfodecoder.cpp
Function: EnumerateLiveSlots
Process: 34
[createdump] Gathering state for process 34 dotnet

so the JIT GC info emission depends on the code being deleted.

It seems that m_NumInterruptibleRanges == 0 meaning is overloaded. The original meaning was what its name says "no interruptible ranges".

dotnet/coreclr#9869 overloaded it to mean "or untracked slots only". It sounds like that we may want to have a separate state for "untracked slots only" to disambiguate these two cases. Does it sound right?

[AndyAyersMS]

Is it that the method in the issue (and the repro) have only call site safe points and so maybe no interruptible ranges, and the skip reporting logic only kicks in for aborted frames with interruptible ranges, so we end up reporting when we shouldn't?

[jkotas]

Is it that the method in the issue (and the repro) have only call site safe points

I do not think that the existence of call site safe points is necessary to hit the bug. We may skip reporting of the callsites in the special noTrackedGCSlots mode, so the method can have calls but no reported callsites in GC info

no interruptible ranges, and the skip reporting logic only kicks in for aborted frames with interruptible ranges, so we end up reporting when we shouldn't?

Right, this is the problem. My latest commit is tweaking the condition to skip the reporting even with no interruptible ranges.

[AndyAyersMS]

Latest version looks reasonable to me.

Do you think this has gone unnoticed for years because it's rare to have GC in the middle of EH handling, so there's just a small window where this can cause trouble?

[jkotas]

/azp run runtime-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

/azp run runtime-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

it's rare to have GC in the middle of EH handling, so there's just a small window where this can cause trouble?

Yes, I think it is that combined with the specific structure required to hit the bug (untracked slots + no interruptible regions, untracked slot is not yet initialized when the exception is thrown).

[jkotas]

I have added your test and validated that the test fails as expected before the fix.

[jkotas]

/azp run runtime-coreclr gcstress-extra, runtime-coreclr gcstress0x3-gcstress0xc

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[jkotas]

Fixes#119363

[Copilot]

Pull Request Overview

This PR fixes issue #119363 by unconditionally skipping GC reporting for non-interruptible aborted methods. The change simplifies the logic for handling execution-aborted methods in the GC info decoder by removing unnecessary conditional checks and variable declarations.

Key changes:

• Removes the noTrackedRefs variable and associated logic that was never actually used
• Moves the countIntersections variable declaration outside the conditional block to ensure proper scoping
• Fixes incorrect brace placement that was causing logic errors in the interruptible ranges handling

[jkotas]

This is reverting part of https://github.com/dotnet/coreclr/pull/9869/files#diff-e5013db5f0394027d19785d4928e535fb1157889556c72677037bd39e20d27ebR660 .

@dotnet/jit-contrib Could you please validate that the JIT does not depend on the behavior that's being reverted here?

[jkotas]

I see number of tests failing with:

 Starting: ComInterfaceGenerator.Unit.Tests (parallel test collections = on [2 threads], stop on fail = off)
ASSERT FAILED
Expression: executionAborted
Location: line 812 in /__w/1/s/src/coreclr/vm/gcinfodecoder.cpp
Function: EnumerateLiveSlots
Process: 34
[createdump] Gathering state for process 34 dotnet

so the JIT GC info emission depends on the code being deleted.

It seems that m_NumInterruptibleRanges == 0 meaning is overloaded. The original meaning was what its name says "no interruptible ranges".

dotnet/coreclr#9869 overloaded it to mean "or untracked slots only". It sounds like that we may want to have a separate state for "untracked slots only" to disambiguate these two cases. Does it sound right?

[AndyAyersMS]

Is it that the method in the issue (and the repro) have only call site safe points and so maybe no interruptible ranges, and the skip reporting logic only kicks in for aborted frames with interruptible ranges, so we end up reporting when we shouldn't?

[jkotas]

Is it that the method in the issue (and the repro) have only call site safe points

I do not think that the existence of call site safe points is necessary to hit the bug. We may skip reporting of the callsites in the special noTrackedGCSlots mode, so the method can have calls but no reported callsites in GC info

no interruptible ranges, and the skip reporting logic only kicks in for aborted frames with interruptible ranges, so we end up reporting when we shouldn't?

Right, this is the problem. My latest commit is tweaking the condition to skip the reporting even with no interruptible ranges.

[AndyAyersMS]

Latest version looks reasonable to me.

Do you think this has gone unnoticed for years because it's rare to have GC in the middle of EH handling, so there's just a small window where this can cause trouble?

[jkotas]

/azp run runtime-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

/azp run runtime-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

it's rare to have GC in the middle of EH handling, so there's just a small window where this can cause trouble?

Yes, I think it is that combined with the specific structure required to hit the bug (untracked slots + no interruptible regions, untracked slot is not yet initialized when the exception is thrown).

[jkotas]

I have added your test and validated that the test fails as expected before the fix.

[jkotas]

/azp run runtime-coreclr gcstress-extra, runtime-coreclr gcstress0x3-gcstress0xc

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).