https://kotlinlang.org logo
Title
t

Thomas

08/30/2019, 1:06 PM
Hello, I was wondering if someone from Ktor is looking into the following issue. I would really like a solution for this. If anyone has any suggestions how I could fix this, please let me know. https://github.com/ktorio/ktor/issues/1263
2
Hey @e5l, you self assigned this issue. Is there anything I can do to help?
e

e5l

09/02/2019, 11:45 AM
Nope, we’re already working on improving stack traces quality.
👍 1
t

Thomas

09/03/2019, 11:36 AM
Hi again @e5l, good to hear you are working on it. Is this already included in 1.2.4? I updated Ktor to 1.2.4 and my app. The stack traces are still the same. Lots of users are getting this crash and I really want to fix this.
e

e5l

09/03/2019, 11:37 AM
Nope, but changes are in
master
t

Thomas

09/03/2019, 11:45 AM
@e5l wow that's great! Could you link to the commit so I can try it out?
If so, is it ready to use or is it still a work in progress?
e

e5l

09/03/2019, 12:17 PM
It’s ready, but there are few things to do for exceptions with custom state. Still WIP
t

Thomas

09/03/2019, 12:21 PM
Ok so what would happen for those exceptions? Should it be safe to try out in my app?
e

e5l

09/03/2019, 12:22 PM
They don’t recover the stack. It’s safe to try it out 🙂. I would be happy to hear the feedback.
t

Thomas

09/03/2019, 12:23 PM
Ok great, I will try it out and give feedback. I really appreciate your help!
:tnx: 1
Hi @e5l, I cherry picked that commit onto the 1.2.x branch and built with mavenLocal. I made sure that this version was included in my app. I got the same crash again on Firebase, but unfortunately the stack trace does not show more information. None of the affected users (375+ users in last 7 days) so far, have reported how they got the crash. I have no idea how they get the crash. Here is the new stack trace (with coroutines debug mode enabled as well): https://gist.github.com/Thomas-Vos/75a037a2e0de62380f4b31bbf211c8d8 Is there anything I can do to help?
@e5l Does a
java.net.SocketTimeoutException
fall under a "custom state" exception?
e

e5l

09/09/2019, 9:14 AM
Nope. Are you installing
DebugProbes
before executing the request?
t

Thomas

09/09/2019, 10:19 AM
@e5l No, I only have the following:
System.setProperty(DEBUG_PROPERTY_NAME, DEBUG_PROPERTY_VALUE_ON)
Do I need to add
DebugProbes
as well? Would that work for an Android app?
e

e5l

09/09/2019, 10:21 AM
Yep, there is no way to make it without debug probes
t

Thomas

09/09/2019, 10:27 AM
@e5l Ok, but the documentation says that it is not compatible with Android. Is that no longer true? https://github.com/Kotlin/kotlinx.coroutines/blob/master/kotlinx-coroutines-debug/README.md#debug-agent-and-android
e

e5l

09/09/2019, 10:28 AM
@Vsevolod Tolstopyatov [JB]
v

Vsevolod Tolstopyatov [JB]

09/09/2019, 10:30 AM
Unfortunately, it’s still not compatible with Android
t

Thomas

09/09/2019, 10:32 AM
That’s disappointing. Any ideas how I could get a real stack trace so I can solve this issue?
I really need a fix for this crash as it is affecting a lot of users in my app.
I am not able to reproduce this exception myself in my app. A stack trace would really make this a lot easier. @e5l do you have any ideas?
There are some other people who responded to the GitHub issue with the same issue (https://github.com/ktorio/ktor/issues/1263)
Hello @Dominaezzz, @Santosh Astagi, @spierce7. On GitHub you responded with a similar issue. Do any of you have more details which could help solve this issue?
d

Dominaezzz

09/09/2019, 11:49 AM
I think it's just a stack frame building issue.
t

Thomas

09/09/2019, 12:10 PM
@Dominaezzz thanks for your response. I don’t exactly get what you are trying to say, but without a stack trace I just cannot find the cause in my app.
Here is a small example:
GlobalScope.launch {
    val deferred = async {
        val client = HttpClient(OkHttp) {
            engine {
                config {
                    // Make sure there is a timeout
                    readTimeout(1, TimeUnit.MILLISECONDS)
                }
            }
        }
        client.get<String>("<https://google.com>")
    }
    deferred.await()
}
This throws the following exception: https://gist.github.com/Thomas-Vos/adca67cc732d87691662725e56fc59b3 As you can see it does not show a stack trace referencing my code. @e5l How am I supposed to find the cause in my app? I have Kotlin debug mode enabled, but without the DebugPropes as that is not compatible with Android.
d

Dominaezzz

09/09/2019, 12:26 PM
Suspend functions "break" the stack frame. Since the JVM doesn't know what coroutines are. So kotlin tries to fake a stack frame that looks like what we expect.
t

Thomas

09/09/2019, 12:29 PM
Yes, that explains why the stack trace is missing. Would something like this make sense? At least temporarily until one of the users gets this exception again? This way at least I know where in my code I called this suspend function, right?
try {
    deferred.await()
} catch (throwable: Throwable) {
    throw RuntimeException(throwable)
}
d

Dominaezzz

09/09/2019, 1:08 PM
Yes, that could work for now.
s

Santosh Astagi

10/22/2019, 8:37 PM
Sorry just seeing this, reading through, @Thomas did that help you uncover the issue?
t

Thomas

10/22/2019, 8:42 PM
@Santosh Astagi no, unfortunately it didn't. I am still unable to find the cause of the exception. Currently my worst crash in Firebase.
I would really like to solve it but just do not know how
One user reported that my app did not crash with WiFi off (so no timeout exception but probably an immediate socket exception). Apperantly that did not crash, but I do catch both types of exceptions so not sure why.
s

Santosh Astagi

10/22/2019, 8:51 PM
hmmm, we are also stumped, we are unable to reproduce it, but see this crash in our logs
Did you update to 1.2.5?
t

Thomas

10/22/2019, 10:10 PM
@Santosh Astagi I'm still on version 1.2.4.
s

Santosh Astagi

10/22/2019, 10:10 PM
1.2.5 seemed to have some promising updates
check release log
Planning to use 1.2.5 and check the crash logs
t

Thomas

10/22/2019, 10:16 PM
I'll look into it tomorrow, thanks.
Just updated to Ktor 1.2.5 and got a reported crash with a different stack trace. I think it is the same issue. Does this give someone any ideas what could be going wrong?
s

Santosh Astagi

10/24/2019, 6:10 PM
This is a little promising atleast
So, I have been digging around a bit
and I found this bug, could this be related to ktor:
kotlin native may have an issue with some segment pooling of threads. Look at the last comment @Thomas
t

Thomas

10/24/2019, 6:23 PM
@Santosh Astagi How exactly is that related? It is a different exception and those GitHub comments are about Kotlin Native. I am using Kotlin JVM on Android
Have you updated your app with Ktor 1.2.5? I am curios what your stack trace will be. It looks like the cause for my stack trace is happening inside an AsyncTask. I am not using them myself, The only place I can think of they are used by the system in my app are in the Android Widgets / JobIntentService. They probably use an AsyncTask in the background. But that is just a guess.
s

Santosh Astagi

10/24/2019, 6:30 PM
I am releasing next week, will update here
the reason I brought that up, is ktor is native, it's underlying engine may not be
t

Thomas

10/24/2019, 6:35 PM
ktor is native, it’s underlying engine may not be
As far as I know that is not possible. Kotlin/Native means that it compiles to C for e.g. iOS. I am using Kotlin JVM (so no Kotlin/Native at all). Could you explain in more detail?
s

Santosh Astagi

10/24/2019, 7:16 PM
While the networking is happening completely at at the platform level, there are other things that are in native i.e. other features that you install in ktor that run in the JVM but it is implemented in the common layer, just wondering if this may be connected.
t

Thomas

10/25/2019, 7:57 AM
Code in the mpp common layer still compiles to Kotlin JVM
s

Santosh Astagi

11/08/2019, 8:39 PM
@Thomas we released last week with the upgraded versiona nd we are not seeing that appear as a crash, but instead is listed as a non-fatal. Just though I'd let you know.
t

Thomas

11/08/2019, 9:26 PM
@Santosh Astagi do you mean non fatal in Firebase? That means you are catching the exception and logging it to Firebase manually.
s

Santosh Astagi

11/08/2019, 9:26 PM
yes
We started catching SerializationExceptions, that is the only new exception, we started catching
That was a false alarm, we are seeing it again, now, but it showed up more than a week after releasing.
This has stopped happening for us now.