Stacktrace recovery #792
Merged
Stacktrace recovery #792
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
qwwdfsad
commented
Nov 4, 2018
|
This is still work-in-progress. It is worth reviewing, but I am actively trying to adjust this branch for debug agent purposes and won't merge it until debug agent is ready. For example, I've found that recovery is stable only if stacktrace is recovered from |
qwwdfsad
commented
Nov 4, 2018
core/kotlinx-coroutines-core/src/internal/ExceptionsConstuctor.kt
Outdated
Show resolved
Hide resolved
qwwdfsad
force-pushed
the
develop
branch
3 times, most recently
from
bc68d63 to
3179683
Compare
* Implement CoroutineStackFrame in CancellableContinuationImpl, DispatchedContinuation and ScopeCoroutine * On coroutine resumption try to reflectively instantiate exception instance of the same type, but with augmented stacktrace * Recover stacktrace by walking over CoroutineStackFrame * Recover stacktrace on fast-path exceptions without CoroutineStackFrame walking to provide more context to an exception * Unwrap exceptions when doing aggregation in JobSupport * Add kill-switch to disable stacktrace recovery, introduce method to recover stacktrace on the exceptional fast-path * Add `suspendCoroutineOrReturn` on exceptional fast-path in await in order to provide "real" stacktrace Design rationale: All recovery of *suspended* continuations takes place in Dispatched.kt file, the only place where all calls to "resume*" ends up, so we don't have to remember about stacktrace recovery in every primitive we are implementing. But to provide more accurate stacktraces we *have to* recover it on every fast-path for better debuggability. Fixes #493
* Extract call to suspendCoroutineUninterceptedOrReturn behind recoverability check * Cache exceptions constructors into WeakHashMap in order to avoid expensive ctor lookup
qwwdfsad
force-pushed
the
stacktrace-recovery
branch
from
9013717 to
25a886e
Compare
This comment has been minimized.
This comment has been minimized.
qwwdfsad
force-pushed
the
stacktrace-recovery
branch
2 times, most recently
from
27a100e to
b8295d1
Compare
elizarov
suggested changes
Nov 28, 2018
This comment has been minimized.
This comment has been minimized.
qwwdfsad
force-pushed
the
stacktrace-recovery
branch
from
55e9ff6 to
f7c3e6b
Compare
qwwdfsad
commented
Nov 30, 2018
qwwdfsad
force-pushed
the
stacktrace-recovery
branch
2 times, most recently
from
a0cd925 to
ca3acc0
Compare
* Recover stacktraces via both fast and slow paths in scoped builders * Merge stracktraces of nested scoped builders, eliminate common prefix so it looks like a flat profile * Optimize stacktrace-related machinery * Copy meaningful part of original exception into recovered one, rename "Current coroutine stacktrace" to "Coroutien boundary" * Rename Exception.kt to StackTraceRecovery.kt to avoid name clash with another Exception.kt
qwwdfsad
force-pushed
the
stacktrace-recovery
branch
from
1e37d13 to
1032f58
Compare
elizarov
reviewed
Dec 7, 2018
* Can be installed dynamically or from command line * Captures coroutine creation stacktrace and stores it in completion, automatically enhancing stacktrace recovery mechanism * Allows to dump and introspect all active coroutines * Allows to dump Job hierarchy * When installed from command line, dumps all coroutines on kill -5 * Probe support in undispatched coroutines
elizarov
suggested changes
Dec 10, 2018
common/kotlinx-coroutines-core-common/src/internal/StackTraceRecovery.common.kt
Outdated
Show resolved
Hide resolved
* Do not store creation stacktrace of the coroutine, recover it from ArtificialStackFrame * Reduce lock window where possible to avoid contention * Avoid stacktrace copying where possible
# Conflicts: # common/kotlinx-coroutines-core-common/src/JobSupport.kt # core/kotlinx-coroutines-core/test/exceptions/SuppressionTests.kt
* Readme * Do not fail on Windows during signal handler installation * Do not warn about missing artificial stackframe
…endency of target process), use shadow plugin for that to avoid clashes with other byte-buddy versions and publish shadow jar instead of regular one for debug module
Coroutines debug agent Fixes #772
…me and jvm.internal.CoroutineStackFrame
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Basic exception stacktrace recovery mechanism
suspendCoroutineOrReturnon exceptional fast-path in await in order to provide "real" stacktraceDesign rationale:
All recovery of suspended continuations takes place in Dispatched.kt file, the only place where all calls to "resume*" ends up, so we don't have to remember about stacktrace recovery in every primitive we are implementing. But to provide more accurate stacktraces we have to recover it on every fast-path for better debuggability.
Fixes #493