Func-eval while runtime is suspended may not run due to deadlock (timing issue)

[kouvel]

One thread may be doing:

• TieredCompilationManager::TieringDelayTimerCallbackWorker
• TieredCompilationManager::ResumeCountingCalls
• MethodDesc::BackpatchToResetEntryPointSlots
• GCCoop::GCCoop
• And block for runtime suspension while holding the slot backpatching lock

After runtime suspension, the func-eval thread may be doing:

• MethodDesc::DoPrestub
• CodeVersionManager::PublishVersionableCodeIfNecessary
• MethodDescBackpatchInfoTracker::ConditionalLockHolder::ConditionalLockHolder

It cannot acquire the lock and the func-eval times out. There doesn't seem to be any other instance of notifying the debugger of a cross-thread dependency (though something like NotifyOfCrossThreadDependency) from the VM side. It still wouldn't allow the func-eval to run anyway.

Best way to fix probably would be to not enter cooperative GC mode while holding a regular lock, such that the runtime cannot be suspended while holding the lock. This would mean entering cooperative GC mode before acquiring the lock, requiring that the lock be an unsafe any-mode lock, which in turn means that no GC_TRIGGERS work may be done inside the lock. May be doable, need to see what it would entail.

[nszeitli]

If this is the "To prevent an unsafe abort" root cause, is there a known workaround at this time?

[kouvel]

Disabling tiered compilation should help when debugging, although it can't be disabled if attaching to a running app that already has it enabled. Tiered compilation may be disabled in the following ways:

Project file (with a clean build after changes to the property):

  <PropertyGroup>
    <TieredCompilation>false</TieredCompilation>
  </PropertyGroup>

.runtimeconfig.json

{
  "runtimeOptions": {
    "configProperties": {
      "System.Runtime.TieredCompilation": false
    }
  }
}

Environment variable:

COMPlus_TieredCompilation=0

[kouvel]

Fixed in 3.1 with dotnet/coreclr#28006, and fixed in master with #32250 (original PR #2380)