segfault in /system/lib/libssl.so (SSL_CTX_set_alpn_protos+20) #647
Comments
|
@andaag which version of Android? I think this is a dalvik bug and I'd like to report it upstream. (That said, we can probably do something to work-around in OkHttp.) |
|
getContentLengthLong() and getHeaderFieldLong() won't exist in Android until the next release. They were not in KitKat. https://android-review.googlesource.com/#/c/82755/ If you can tell: Did the problem occur at class load time or in response to a call to one of the actual methods? I had figured it would be ok providing OkHttp avoided the calls and nobody attempted to use reflection on OkHttp's HttpURLConnectionImpl. I'm clearly wrong about something. Perhaps another thing for Platform? |
|
@swankjesse It's on a nexus7, 4.2.2. @nfuller It happened on startup, but I strongly suspect it was on a method call. I THINK I saw a progress bar before the crash. I'm not sure though, wish I could be more helpfull there. If I'm able to reproduce it and get any more information I'll let you know. |
|
I couldn't see any calls to those methods within the snapshot of OkHttp I have so that's why I think it is either a call your app is making, or some kind of linkage problem I hadn't anticipated. A Java 1.6 development environment won't have those methods either. Are you using Java 1.7 for development, or down-casting and HttpURLConnection to an okhttp.internal.http.HttpURLConnectionImpl or something like that? As a short term fix, if you do make calls to getHeaderFieldLong() / getContentLengthLong() from your app you can change it to use getContentLength() / getHeaderFieldInt(), or getHeaderField() + Long.parseLong() instead. Longer term, if there is a chance of those calls being made then OkHttp could implement these methods via Platform, which would be able to do the right thing based on reflection. That said, I hadn't anticipated the need so I'd definitely be interested in more details when you have them. |
|
I think the warning is a red herring. The crash contains this: So it's something to do with ALPN... |
|
We've got version.jdk set to 1.6 in our maven build environment, I've seen some weird issues in production builds when targeting 1.7 which I haven't been able to look into yet. (I strongly suspect it's a quick fix though). We're not casting anything to anything in okhttp.internal. And we're not using get*Long in our code. It might be in one of our dependencies, but I really doubt it. Our network stack consists of volley+okhttp, but we also have some dependencies with their own network stack. Such as google analytics and adobe analytics (which is a nice binary blob.. although I know from previous debugging experiments it's not obfuscated ;) ). |
|
@andaag the problem is unrelated to getHeaderFieldLong. What's happening is that you're using the same SSLContext for an OkHttp request and a non-OkHttp request. This doesn't work because of a (recently-fixed) bug in Android's SSL library. In theory, running this code before anything else should solve the problem: The best place to do this is in an |
|
@swankjesse Ahhh. We had a workaround for ssl issues (from #184), which I thought I wouldn't need anymore after okhttp 1.5. I'll add this fix to our app, thank you both 👍 . |
We just upgraded to 1.5.1 (from 1.3.x) and got this segfault. Note that it doesn't seem to happen every time.
The text was updated successfully, but these errors were encountered: