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

[mononz]

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)

[swankjesse]

Any particular manufacturers for these devices? Typically ‘impossible’ problems like this indicate a faulty VM or CPU.

[mononz]

Manufacturer seems to vary, most come from the HTC desire 526/626 but also lenovo and sony there too. A handful of devices from my hockey crash reports are:

• HTC Desire 526GPLUS
• HTC Desire 626G
• SONY Xperia E4 E2105
• BQ Aquaris E4.5
• Wiko Sunset2
• BLU Studio 5.0 K
• Lenovo Tab 2 A7-10
• Lenovo A8-50 A5500
• Lenovo S820
• Acer Liquid Z520

(all running either 4.4.2 or 4.4.4)

Edit, Just looked up all those phones, common Cortex-A7 chip... mind blown!

Is it possible to get a fix for this chip in the lib or would I have to deal with these devices in a separate manner?

[abbath0767]

i have similar problem for HTC Desire 620G dual sim 4.4.2:

Fatal Exception: java.lang.AssertionError
       at okio.AsyncTimeout.scheduleTimeout(AsyncTimeout.java:101)
       at okio.AsyncTimeout.enter(AsyncTimeout.java:80)
       at okio.AsyncTimeout$1.write(AsyncTimeout.java:178)
       at okio.RealBufferedSink.flush(RealBufferedSink.java:216)
       at okhttp3.internal.http1.Http1Codec.finishRequest(Http1Codec.java:166)
       at okhttp3.internal.http.CallServerInterceptor.intercept(CallServerInterceptor.java:72)
       at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
       at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.java:45)
       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:93)
       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:120)
       at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
       at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
       at com.myApp.network.ReceivedCookiesInterceptor.intercept(ReceivedCookiesInterceptor.kt:11)
       at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
       at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
       at com.myApp.network.AddCookiesInterceptor.intercept(AddCookiesInterceptor.kt:18)
       at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
       at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
       at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:185)
       at okhttp3.RealCall$AsyncCall.execute(RealCall.java:135)
       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:841)

[lucastsantos]

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

[steelbytes]

I'm getting the same. (with studio/gradle 3.0 with D8)

Lenovo A536 (A536), 1024MB RAM, Android 4.4
Verizon Wireless Ellipsis 7 (QMV7A) (QMV7A), 1024MB RAM, Android 4.4

will disable D8 ...

[steelbytes]

quick thought - maybe D8 causes problems with experimental/beta version of ART in 4.4 (hidden in developer options)

https://issuetracker.google.com/issues/68358860

[dhabensky]

Tested on my Lenovo S650 Android 4.4.2

Works fine on Dalvik runtime without D8,
always throws AssertionError on ART.

[Hackforid]

rct6773w22
touch smart fly 3g
e2104
Huawei HOL-U19
Micromax A310
OPPO A11w
OPPO 1201
and so on...

I found manay 4.4 device have the same issue

[rafaelfukuda]

I have the same problem. Will disable D8 for now

[moni890185]

disabling D8 worked for us.

[haniha]

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

[sherhut]

We have tried to reproduce this using the android emulator with no luck so far. Either it does not happen on stock versions of Dalvik/Art or our example code is wrong. @dhabensky could you post the full example that you have used to replicate this? Either here or to the bug on the google tracker at https://issuetracker.google.com/issues/70909581.

It would also help if you could compile your example with a more recent Android Studio 3.1 canary build and check whether it still fails.

And to clarify, with dx your example works on Dalvik but fails on the experimental version of Art, whereas with D8 it fails on both Dalvik and Art?

[Dimillian]

Same problem reported for us. A lot of crash in my interceptors on:

return chain.proceed(request);

on 4.4

[sherhut]

It would help if we had an actual reproduction to use and a list of devices where this happens. So far, we have not been able to reproduce it.

[SkyleKayma]

Found same issue (Crashlytics reports) on these devices :

Hisense STARSHINE 4
Lenovo A3500-FL
Archos 101D Neon
Lenovo A5500-H

All running with Android 4.4.2

Will try to disable D8

[Arshadse]

I have found this issue, how to resolve this,,
Today, 12:23 PM on app version 3
Oppo A11w (A11w), 1024MB RAM, Android 4.4
Report 1

java.lang.NoClassDefFoundError:

at suma.screen.recorder.capture.video.RecordScreenActivity.onCreate (RecordScreenActivity.java:100)

at android.app.Activity.performCreate (Activity.java:5361)

at android.app.Instrumentation.callActivityOnCreate (Instrumentation.java:1088)

at android.app.ActivityThread.performLaunchActivity (ActivityThread.java:2331)

at android.app.ActivityThread.handleLaunchActivity (ActivityThread.java:2440)

at android.app.ActivityThread.access$800 (ActivityThread.java:151)

at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1342)

at android.os.Handler.dispatchMessage (Handler.java:110)

at android.os.Looper.loop (Looper.java:193)

at android.app.ActivityThread.main (ActivityThread.java:5344)

at java.lang.reflect.Method.invokeNative (Native Method)

at java.lang.reflect.Method.invoke (Method.java:515)

at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:860)

at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:676)

at dalvik.system.NativeStart.main (Native Method)

[swankjesse]

Duplicate of this Okio bug:
https://github.com/square/okio/issues/334

Need guidance from the D8 folks on this.

[nfuller]

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

[swankjesse]

@nfuller please do.

[Sirvanalie]

I have the same problem Too. I disable D8, but error: Default or static interface method used without --min-SDK-version >= 24 appear in message tab. I don't know, what is last solution for this issue?

[madsager]

The D8 bug report for this is https://issuetracker.google.com/70909581

We have attempted to reproduce this on multiple devices and emulators and have failed. If you have a reproduction we would love to get our hands on it.

We have inspected the code generated with D8 and with DX and have yet to find anything that could explain this (which makes sense since this only seems to happen on 4.4.2 indicating a potential VM bug).

It looks like all of the devices listed here contain MediaTek chips. We know that MediaTek has done vendor customization of Android Runtimes and have seen other bugs in their custom Android Runtime versions. But even on one of the devices listed here (HTC Desire 626G) we have not been able to reproduce.

We will continue to investigate, but at this point it is a dead end. Any help finding reproductions would be much appreciated. If you guys have apps built with D8 where you see these crashes it would be great if you could attach the apk to the D8 bug report: https://issuetracker.google.com/70909581 so we can see if we can reproduce.

[juliolopeztorres]

I'm starting to have these errors in one of my projects. I got reports from Google Developer Console with unknown android devices for me (keytak72_cwet_lca, ratech92_cwet_rlk_kk and a831_324_ax_cht_z6_plus).

All devices are in Android 4.4. Here is the stacktrace:

java.lang.AssertionError: 
  at okio.AsyncTimeout.scheduleTimeout (AsyncTimeout.java:101)
  at okio.AsyncTimeout.enter (AsyncTimeout.java:80)
  at okio.AsyncTimeout$2.read (AsyncTimeout.java:235)
  at okio.RealBufferedSource.read (RealBufferedSource.java:46)
  at okhttp3.internal.http1.Http1Codec$AbstractSource.read (Http1Codec.java:360)
  at okhttp3.internal.http1.Http1Codec$FixedLengthSource.read (Http1Codec.java:404)
  at okio.RealBufferedSource.read (RealBufferedSource.java:46)
  at okhttp3.internal.cache.CacheInterceptor$1.read (CacheInterceptor.java:174)
  at okio.RealBufferedSource.request (RealBufferedSource.java:67)
  at okhttp3.logging.HttpLoggingInterceptor.intercept (HttpLoggingInterceptor.java:240)
  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)

I cannot reproduce this bug.

Hope this would help

[haniha]

my crashlytics report[old version of app with d8 enable]:

This issue has 111 crashes affecting 29 users. [last 7d]

68% HUAWEI
15% HTC
8% LENOVO
5% Blackview
4% Other (2)

56% Android 4.4.2
44% Android 4.2.2

Some Example Devices:
HUAWEI G750-U10
HUAWEI G750-T01
HUAWEI Hol-U19
HTC Desire 816G dual sim
HTC Desire 626G+ dual sim
HTC Desire 820G PLUS dual sim
Lenovo A7-30GC
Lenovo A3300-GV

with d8 disabled it disappeared but seems that 'android.enableD8' is deprecated now:

"The option 'android.enableD8' is deprecated and should not be used anymore.
Use 'android.enableD8=true' to remove this warning.
It will be removed in AGP version 3.3."

[madsager]

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

[haniha]

@madsager
are these two issue related ? [disabling d8 fixed both]
https://github.com/square/okio/issues/323

[madsager]

@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]

@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.