-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Debugger retains strong reference to all coroutines #2117
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
One less trivial reproducer: lazy child coroutine that was cancelled before it was even started.
|
elizarov
added a commit
that referenced
this issue
Jul 8, 2020
It should not prevent garbage-collection of coroutines that were otherwise lost, which included the following practically-useful cases: * Synchronous coroutines (iterator/sequence). * Lazy coroutines that were not started. * Abandoned coroutines that suspend forever without strong references to them in GlobalScope. Two kinds of tests cover this functionality: * A test via FieldWalker ensures that debugger impl does not keep a strong reference. This tests works fast and provides good diagnostics if anything goes wrong, but it is fragile, as futures changes to debugger my introduce static references to running coroutines elsewhere. * A stress-test that ensures that no OOM indeed happens when you run a lot of such lost coroutines. Longer-running, more stable to code change, but fragile in a difference sense as it may accidentally start passing in the future if lots of memory get allocated for tests. Fixes #2117
elizarov
added a commit
that referenced
this issue
Jul 8, 2020
It should not prevent garbage-collection of coroutines that were otherwise lost, which included the following practically-useful cases: * Synchronous coroutines (iterator/sequence). * Lazy coroutines that were not started. * Abandoned coroutines that suspend forever without strong references to them in GlobalScope. Two kinds of tests cover this functionality: * A test via FieldWalker ensures that debugger impl does not keep a strong reference. This tests works fast and provides good diagnostics if anything goes wrong, but it is fragile, as futures changes to debugger my introduce static references to running coroutines elsewhere. * A stress-test that ensures that no OOM indeed happens when you run a lot of such lost coroutines. Longer-running, more stable to code change, but fragile in a difference sense as it may accidentally start passing in the future if lots of memory get allocated for tests. Fixes #2117
elizarov
added a commit
that referenced
this issue
Jul 8, 2020
It should not prevent garbage-collection of coroutines that were otherwise lost, which included the following practically-useful cases: * Synchronous coroutines (iterator/sequence). * Lazy coroutines that were not started. * Abandoned coroutines that suspend forever without strong references to them in GlobalScope. Two kinds of tests cover this functionality: * A test via FieldWalker ensures that debugger impl does not keep a strong reference. This tests works fast and provides good diagnostics if anything goes wrong, but it is fragile, as futures changes to debugger my introduce static references to running coroutines elsewhere. * A stress-test that ensures that no OOM indeed happens when you run a lot of such lost coroutines. Longer-running, more stable to code change, but fragile in a difference sense as it may accidentally start passing in the future if lots of memory get allocated for tests. Fixes #2117
elizarov
added a commit
that referenced
this issue
Jul 8, 2020
It should not prevent garbage-collection of coroutines that were otherwise lost, which included the following practically-useful cases: * Synchronous coroutines (iterator/sequence). * Lazy coroutines that were not started. * Abandoned coroutines that suspend forever without strong references to them in GlobalScope. Two kinds of tests cover this functionality: * A test via FieldWalker ensures that debugger impl does not keep a strong reference. This tests works fast and provides good diagnostics if anything goes wrong, but it is fragile, as futures changes to debugger my introduce static references to running coroutines elsewhere. * A stress-test that ensures that no OOM indeed happens when you run a lot of such lost coroutines. Longer-running, more stable to code change, but fragile in a difference sense as it may accidentally start passing in the future if lots of memory get allocated for tests. Fixes #2117
elizarov
added a commit
that referenced
this issue
Jul 8, 2020
It should not prevent garbage-collection of coroutines that were otherwise lost, which included the following practically-useful cases: * Synchronous coroutines (iterator/sequence). * Lazy coroutines that were not started. * Abandoned coroutines that suspend forever without strong references to them in GlobalScope. Two kinds of tests cover this functionality: * A test via FieldWalker ensures that debugger impl does not keep a strong reference. This tests works fast and provides good diagnostics if anything goes wrong, but it is fragile, as futures changes to debugger my introduce static references to running coroutines elsewhere. * A stress-test that ensures that no OOM indeed happens when you run a lot of such lost coroutines. Longer-running, more stable to code change, but fragile in a difference sense as it may accidentally start passing in the future if lots of memory get allocated for tests. Fixes #2117
recheej
pushed a commit
to recheej/kotlinx.coroutines
that referenced
this issue
Dec 28, 2020
…Kotlin#2129) It should not prevent garbage-collection of coroutines that were otherwise lost, which included the following practically-useful cases: * Synchronous coroutines (iterator/sequence). * Lazy coroutines that were not started. * Abandoned coroutines that suspend forever without strong references to them in GlobalScope. Two kinds of tests cover this functionality: * A test via FieldWalker ensures that debugger impl does not keep a strong reference. This tests works fast and provides good diagnostics if anything goes wrong, but it is fragile, as futures changes to debugger my introduce static references to running coroutines elsewhere. * A stress-test that ensures that no OOM indeed happens when you run a lot of such lost coroutines. Longer-running, more stable to code change, but fragile in a difference sense as it may accidentally start passing in the future if lots of memory get allocated for tests. Fixes Kotlin#2117
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
With the debugger agent attached, each invocation of
iterator { }
leaks memory as the debugging agent keeps a strong reference to the coroutines that runs forever here.The text was updated successfully, but these errors were encountered: