-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Memory leak in coroutines 1.4.x #2564
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
Comments
Able to reproduce |
Great job with a simple reproducer! Investigating this |
qwwdfsad
added a commit
that referenced
this issue
Mar 13, 2021
* Update initCancellability documentation and implementation to be aligned with current invariants * Make parentHandle non-volatile and ensure there are no races around it * Establish new reusability invariants - Reusable continuation can be used _only_ if it's state is not REUSABLE_CLAIMED - If it is, spin-loop and wait for release - Now the parent is attached to reusable continuation only if it was suspended at least once. Otherwise, the state machine can return via fast-path and noone will be able to release intercepted continuation (-> detach from parent) - It implies that the parent is attached after trySuspend call and can be concurrently reused, this is where new invariant comes into play Fixes #2564
Hey, it seems this is marked as fixed in #2581 along with a corresponding test https://github.com/Kotlin/kotlinx.coroutines/pull/2581/files#diff-ed434c42575944931c44e85218440a92177bd346ad6791cf22c45820c75413e7 Is this still an issue? |
It will be fixed in an upcoming release. Version 1.4.3 still has this issue |
pablobaxter
pushed a commit
to pablobaxter/kotlinx.coroutines
that referenced
this issue
Sep 14, 2022
* Rework reusability control in cancellable continuation * Update initCancellability documentation and implementation to be aligned with current invariants * Make parentHandle non-volatile and ensure there are no races around it * Establish new reusability invariants - Reusable continuation can be used _only_ if it states is not REUSABLE_CLAIMED - If it is, spin-loop and wait for release - Now the parent is attached to reusable continuation only if it was suspended at least once. Otherwise, the state machine can return via fast-path and no one will be able to release intercepted continuation (-> detach from parent) - It implies that the parent is attached after trySuspend call and can be concurrently reused, this is where new invariant comes into play * Leverage the fact that it's non-atomic and do not check it for cancellation prematurely. It increases the performance of fast-path, but potentially affects rare cancellation cases Fixes Kotlin#2564
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've encountered a memory leak which I believe is caused by a race condition in the coroutine library.
I've simplified the leak down to the following repro code:
This sample code leaks
Thing
s very rapidlyI haven't dug too deep, but one interesting thing is if I inline the code for receive batch, there is no leak. Example:
Tested with kotlin 1.4.30 and coroutines-core 1.4.3
The text was updated successfully, but these errors were encountered: