Infinite loop in spin-lock implementation if CancellableContunuation reusability #3613
Comments
qwwdfsad
added a commit
that referenced
this issue
Feb 21, 2023
…block throws an exception Otherwise, continuation instance is left in REUSABLE_CLAIMED state that asynchronous resumer awaits in an infinite spin-loop, potentially causing deadlock with 100% CPU consumption. Originally, the bug was reproduced on old (pre-#3020) implementation where this very pattern was encountered: it was possible to fail owner's invariant check right in the supplied 'block'. This is no longer the case, so the situation is emulated manually (but still is possible in production environments, e.g. when OOM is thrown). Also, suspendCancellableCoroutineReusable is removed from obsolete BroadcastChannel implementation. Fixes #3613
This was referenced Feb 21, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Cherry-picked internal report, so not much details are here.
I'll provide a detailed explanation along with test and a fix in a follow-up PR.
TL;DR it is caused by an exceptional path (i.e.
Mutex.lock(owner)) along with acquiring reusability tokenThe text was updated successfully, but these errors were encountered: