okhttp: AssertionError at AsyncTimeout.java:101 for some android 4.4.2 and 4.4.4 devices

Hey okhttp. I’ve been confused with this AssertionError error for a while now. It only occurs on some android 4.4.2 and 4.4.4 devices. Have I missed something or could there be a real issue?

I am using okhttp 3.8.1 with retrofit 2.3.0 and dagger 2.11

    @Provides
    @Singleton
    OkHttpClient providesOkHttpClient() {
        OkHttpClient.Builder builder = new OkHttpClient().newBuilder()
                .readTimeout(30L, TimeUnit.SECONDS)
                .connectTimeout(30L, TimeUnit.SECONDS)
                .writeTimeout(30L, TimeUnit.SECONDS)
                .addInterceptor(new NetworkInterceptor());
        return builder.build();
    }

    @Provides
    @Singleton
    Retrofit provideCall(OkHttpClient client) {
        return new Retrofit.Builder()
                .baseUrl(BuildConfig.SERVER_PATH)
                .client(client)
                .addConverterFactory(MoshiConverterFactory.create())
                .addCallAdapterFactory(RxJava2CallAdapterFactory.createAsync())
                .build();
    }

StackTrace

Android: 4.4.2
Thread: OkHttp Dispatcher-729

java.lang.AssertionError
	at okio.AsyncTimeout.scheduleTimeout(AsyncTimeout.java:101)
	at okio.AsyncTimeout.enter(AsyncTimeout.java:80)
	at okio.AsyncTimeout$1.flush(AsyncTimeout.java:193)
	at okio.RealBufferedSink.flush(RealBufferedSink.java:218)
	at okhttp3.internal.http1.Http1Codec.finishRequest(Http1Codec.java:164)
	at okhttp3.internal.http.CallServerInterceptor.intercept(CallServerInterceptor.java:84)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
	at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.java:45)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121)
	at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.java:93)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121)
	at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.java:93)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
	at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.java:125)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121)
	at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:200)
	at okhttp3.RealCall$AsyncCall.execute(RealCall.java:147)
	at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
	at java.lang.Thread.run(Thread.java:848)

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 14
Comments: 27 (3 by maintainers)

Commits related to this issue

Update D8 to latest Summary: - Fixes a critical bug on some devices involving okio - https://github.com/square/okhttp/issues/3641#issuecomment-370717021 https://issuetracker.google.com/issues/7090958... — committed to facebook/buck by deleted user 6 years ago

Most upvoted comments

We at @StudioSol had the exactly same problem. We did a series of tests trying to solve it and we ended up finding out that the problem was in the build process.

We had switched to Gradle 3.1.0-alpha1, which uses D8 compiler instead of DX compiler by default. After switching to DX compiler, the problem is no longer appearing.

A temporarily solution may be using Gradle 3.0.0 or disabling D8 compiler in gradle.properties with:

android.enableD8=false

+12

lucastsantos on Nov 6, 2017

We finally managed to reproduce this issue and identified the MediaTek JIT bug in the VM that is causing this. Certain long arithmetic and comparison instructions are incorrectly handled by the JIT. Luckily, we can workaround the issue by forcing the register allocator to avoid certain registers combinations for long operations. We are working on that fix now and will push it out ASAP. When Android Studio 3.1 goes final we expect this fix to be included. Thanks for all of the reports and help tracking this down.

Bug to follow for progress on the fix: https://issuetracker.google.com/issues/70909581

+10

madsager on Mar 6, 2018

@haniha looking at the code I find it very likely that this is the same issue. The null pointer exception is in a loop of the form:

for (; offset >= (s.limit - s.pos); s = s.next) {

Where offset is a long. So, if the comparison produces wrong results, this code can continue to do s = s.next until s becomes null and then throw an exception.

madsager on Mar 6, 2018

@haniha it definitely could be. The bug that we are working around could cause any code that performs computations and comparisons of longs to produce incorrect results on these devices when the JIT compiler kicks in. If long computations produce wrong results that can manifest in many different ways.

madsager on Mar 6, 2018

Do you have a d8 bug number yet? If not, happy to pass the bug report on to the d8 folks.

nfuller on Feb 26, 2018

same here on 4.4.2 and 4.2.2 with huawei and htc mostly any updates on this issue ?

haniha on Dec 20, 2017