Okhttp crashes app with SSLException: Unable to create application data

We were testing our app by changing the date on the device when this crash happened. I’m not sure if the crash is related to the date change or not.

Here is the crash log:

java.lang.RuntimeException: javax.net.ssl.SSLException: Unable to create application data
	at com.android.org.conscrypt.ConscryptFileDescriptorSocket.newSsl(ConscryptFileDescriptorSocket.java:161)
	at com.android.org.conscrypt.ConscryptFileDescriptorSocket.<init>(ConscryptFileDescriptorSocket.java:152)
	at com.android.org.conscrypt.OpenSSLSocketFactoryImpl.createSocket(OpenSSLSocketFactoryImpl.java:149)
	at okhttp3.internal.connection.RealConnection.connectTls(RealConnection.java:230)
	at okhttp3.internal.connection.RealConnection.establishProtocol(RealConnection.java:198)
	at okhttp3.internal.connection.RealConnection.buildConnection(RealConnection.java:174)
	at okhttp3.internal.connection.RealConnection.connect(RealConnection.java:114)
	at okhttp3.internal.connection.StreamAllocation.findConnection(StreamAllocation.java:193)
	at okhttp3.internal.connection.StreamAllocation.findHealthyConnection(StreamAllocation.java:129)
	at okhttp3.internal.connection.StreamAllocation.newStream(StreamAllocation.java:98)
	at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.java:42)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
	at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.java:109)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
	at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.java:93)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
	at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.java:124)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
	at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:170)
	at okhttp3.RealCall.access$100(RealCall.java:33)
	at okhttp3.RealCall$AsyncCall.execute(RealCall.java:120)
	at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
	at java.lang.Thread.run(Thread.java:764)
Caused by: javax.net.ssl.SSLException: Unable to create application data
	at com.android.org.conscrypt.NativeCrypto.SSL_new(Native Method)
	at com.android.org.conscrypt.SslWrapper.newInstance(SslWrapper.java:58)
	at com.android.org.conscrypt.ConscryptFileDescriptorSocket.newSsl(ConscryptFileDescriptorSocket.java:159)
	... 27 more

[swankjesse]

There’s a bunch of problems that can be caused by resource exhaustion: can’t open files, can’t allocate memory, can’t create threads.

We should be prudent to not exhaust resources ourselves: don’t leak memory, files, or threads. Make APIs where it’s clear who is responsible for releasing which resources.

But we shouldn’t attempt to recover from resource exhaustion problems. The process has become unstable and it’s soon going to exit.

I think this is a resource exhaustion bug and that the cause is external to OkHttp and our TLS library.

[AlbertSnow]

Yes, we should not recover from exhaust resources. But if almost file descriptor is consumed by okhttp. I think there should be some strategy to avoid the case. In our app, almost file descriptor exhaust is report from OkHttp stack. I presume there is some reason why file descriptors consume, but socket not reuse. So every https connect, will cause pip creation, consume file descriptor. So crash.

Hope the presume can give some help. Thank you;