(ssl_parse_serverhello_tlsext+262) native crash on KitKat and lower #2679
Comments
|
Looks like SSLv3 handshake fail, then doing fallback one. |
|
This will be very difficult to reproduce and fix. If you can provide an executable test case, that'd be a good start. For now there isn't much we can do. |
|
@swankjesse I can create a test project under my github profile and share with you. But will you be able to test it with your own Google API KEY? |
|
That’s trickier. Any chance you can reproduce this in a standalone test case? (And if you can’t, it’s difficult to be sure the problem is with OkHttp and not say, the TLS stack in KitKat.) |
swankjesse
added
needs info
|
Not able to reproduce anymore on Android 4.4.2 Galaxy S4 mini after RxJava threads optimizaiton, will check on S3 tomorrow and get back with details. |
|
Sorry for the delay. I was able to reproduce on S3 after code update,but only one time and it is really hard to do now. My code was something like this(simplified and removed all unnecessary things) and it was regularly failing on Android 4 and lower : So after that i moved first observeOn into io() thread and added second observeOn(mainThread) just before subscribe(view), also removed subscribeOn/unsubscribeOn for observable2 as it is already executed on io(). It is working faster now and the issue is almost gone. Now the code looks like this: Let me know your thoughts. I can try to create test case using first non-optimal model. |
|
Thanks for the followup. Heap corruption is definitely difficult to investigate. It’s unlikely OkHttp is directly the cause; we’re 100% managed code and so it isn’t possible for us to corrupt the heap. Instead it’s something adjacent: the platform’s built-in SSL stack, or the thread scheduler, or something. Next steps: unsure. If it doesn’t exist in current releases it might be a bug that’s already been fixed. If you could reliably reproduce it we could manually hack our own code to avoid triggering the bug, but we don’t have that luxury now. Consider confirming that the impacted device doesn’t have any software updates? I’m closing this ’cause there’s no obvious action we can take here. |
|
I know this is marked as closed, but random thought: maybe these droids are getting grumpy about threads v sockets ... wondering if its worth trying to keep all okhttp stuff on a single thread on kitkat as an experiment @swankjesse is there any easy-ish way I can force all okhttp to a single thread so I can try this in production (on kitkat)? PS, this is Feb 2018 and I'm using latest / 3.9.1 okhttp |
|
@steelbytes it's almost there already. Canceling is async, and HTTP/2 has many threads touching the sockets. But in HTTP/1 it's one socket per thread. The only remaining concurrency is in handoffs between the connection pool and application threads. |
|
@swankjesse Hmm .. maybe I'll just try forcing http/1 on kitkat and see if the problem goes away |
|
KitKat is already HTTP/1 only due to it missing ALPN support. |
Hello,
I'm using RxJava + Retrofit 2.1.0 (i.e OkHttp 3.3.0) to interact with Google Places Service API.
Sometimes I'm getting app crashes on SSL handshake layer on Android 4.4 and lower. Not able to reproduce on Android 5 and higher. Issue is easier to reproduce on devices with a smaller RAM ~1GB.
The issue is mostly happening when doing a lot of request at the same time and coming from one of threads used to communicate with places service.
I checked all similar issues listed in okhttp repo, but most of them are very old and suggesting to update OkHttpClient version.
Crash dumps:
Android 4.4.2 Galaxy S4 mini:
Similar crash on Android 4.1.2 Galaxy S3:
I'm using default Retrofit OkHTTPClient with no interceptors and also do not pass custom ssl context:
Accessing the following https server: "https://maps.googleapis.com/maps/api/place/"
Please advise.
The text was updated successfully, but these errors were encountered: