Skip to content

StackTrace Recovery Issue #3735

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

Closed
londhep opened this issue May 3, 2023 · 2 comments
Closed

StackTrace Recovery Issue #3735

londhep opened this issue May 3, 2023 · 2 comments
Labels

Comments

@londhep
Copy link

londhep commented May 3, 2023

I'm trying to get a stack trace in code that generates error inside runBlocking.
I'm unable to get full StackTrace here. I am still facing this issue even if I enable stack trace recovery

Note:Our builds are optimised with R8 and as mentioned in https://github.com/Kotlin/kotlinx.coroutines/blob/master/ui/kotlinx-coroutines-android/README.md#optimization
When optimizations are enabled with R8 version 1.6.0 or later the following debugging features are permanently turned off to reduce the size of the resulting binary:

  • Debugging mode
  • Stacktrace recovery
  • The internal assertions in the library are also permanently removed.
    Can you confirm if this is responsible for StackTrace issue, if yes do we have any alternative?

My code looks something like this:

fun main() {
firstCall()
}

fun firstCall() {
secondCall()
}

fun secondCall() {
crashCall()
}

fun crashCall(): String {
return runBlocking {
getData().map {
it!!
}.catch { e ->
throw e
}.flowOn(Dispatchers.IO)
.first()
}
}

fun getData(): Flow<String?> {
val temp: String? = null
return flowOf(temp)
}

StackTrace looks like this:
Exception in thread "main" java.lang.NullPointerException
at package.TestKt$crashCall$1$invokeSuspend$$inlined$map$1$2.emit(Emitters.kt:224)
at kotlinx.coroutines.flow.FlowKt__BuildersKt$flowOf$$inlined$unsafeFlow$2.collect(SafeCollector.common.kt:113)
at package.TestKt$crashCall$1$invokeSuspend$$inlined$map$1.collect(SafeCollector.common.kt:113)
at kotlinx.coroutines.flow.FlowKt__ErrorsKt.catchImpl(Errors.kt:156)
at kotlinx.coroutines.flow.FlowKt.catchImpl(Unknown Source)
at kotlinx.coroutines.flow.FlowKt__ErrorsKt$catch$$inlined$unsafeFlow$1.collect(SafeCollector.common.kt:113)
at kotlinx.coroutines.flow.internal.ChannelFlowOperatorImpl.flowCollect(ChannelFlow.kt:195)
at kotlinx.coroutines.flow.internal.ChannelFlowOperator.collectTo$suspendImpl(ChannelFlow.kt:157)
at kotlinx.coroutines.flow.internal.ChannelFlowOperator.collectTo(ChannelFlow.kt)
at kotlinx.coroutines.flow.internal.ChannelFlow$collectToFun$1.invokeSuspend(ChannelFlow.kt:60)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
at kotlinx.coroutines.internal.LimitedDispatcher.run(LimitedDispatcher.kt:42)
at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:95)
at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:570)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:750)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:677)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:664)

@londhep londhep added the bug label May 3, 2023
@dkhalanskyjb
Copy link
Collaborator

Duplicate of #1998

Yes, as the docs you linked say, stack trace recovery is disabled in the release builds.

@londhep
Copy link
Author

londhep commented May 3, 2023

@dkhalanskyjb So do we have any alternative with which we can see StakTrace in production?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants