You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Previously, the get*ConfigValue APIs had only been called by the JIT during jitStartup, which is called only once ever for the load of the JIT. Now, it's being called per compile. This exposes a race condition in the superpmi collection shim jithost implementation, which swaps out the stored MethodContext on a per-compile basis, in the shim compileMethod function. But the jithost is shared amongst threads, so one thread can trash the other thread's stashed MethodContext. Previously, it didn't matter because it was never used except for allocateMemory/freeMemory, which doesn't use the stashed MethodContext.
The text was updated successfully, but these errors were encountered:
PR dotnet#52427 introduced a per-compilation call to getIntConfigValue
on "SuperPMIMethodContextNumber". This pseudo-config should not
be collected. It exposed a pre-existing multi-threading issue in
the superpmi collector shim. I got rid of the per-compilation
override of the jithost MethodContext, which is problematic, and
currently unneeded, but documented the considerations around collecting
per-compilation data.
Fixesdotnet#53440
* Fix SuperPMI collect with getIntConfigValue
PR #52427 introduced a per-compilation call to getIntConfigValue
on "SuperPMIMethodContextNumber". This pseudo-config should not
be collected. It exposed a pre-existing multi-threading issue in
the superpmi collector shim. I got rid of the per-compilation
override of the jithost MethodContext, which is problematic, and
currently unneeded, but documented the considerations around collecting
per-compilation data.
Fixes#53440
* Update src/coreclr/ToolBox/superpmi/superpmi-shim-collector/jithost.cpp
Co-authored-by: Kunal Pathak <Kunal.Pathak@microsoft.com>
Co-authored-by: Kunal Pathak <Kunal.Pathak@microsoft.com>
ghost
removed
the
in-pr
There is an active PR which will close this issue when it is merged
label
May 28, 2021
ghost
locked as resolved and limited conversation to collaborators
Jun 28, 2021
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
Crash doing superpmi PMI collection using:
stack:
This is due to #52427, which introduced this call to compInit():
Previously, the get*ConfigValue APIs had only been called by the JIT during jitStartup, which is called only once ever for the load of the JIT. Now, it's being called per compile. This exposes a race condition in the superpmi collection shim jithost implementation, which swaps out the stored MethodContext on a per-compile basis, in the shim
compileMethod
function. But the jithost is shared amongst threads, so one thread can trash the other thread's stashed MethodContext. Previously, it didn't matter because it was never used except for allocateMemory/freeMemory, which doesn't use the stashed MethodContext.The text was updated successfully, but these errors were encountered: