Unexpected OOME while loading publicsuffixes.gz

We’re seeing some strange OutOfMemoryExceptions coming from OkHttp 3.9, namely from PublicSuffixDatabase trying to read in publicsuffixes.gz. Rarely but consistently, we’ve seen OOM crashes where, according to the stacktraces, it appears the resource being read in is impossibly large (500 MB+) or the total bytes reported by the created BufferedSource is crazy large too (1.5 GB+).

I don’t have a test or reproduction scenario, as we are only seeing this in production in the crash reports we receive. While there have been instances of crashes from various OS versions and device manufacturers, the vast majority (disproportional from our typical usage distribution) comes from Samsung phones running M.

A couple of sample stacktraces can be found below:

Caused by java.lang.OutOfMemoryError: Failed to allocate a 1768847725 byte allocation with 7394266 free bytes and 490MB until OOM
       at okhttp3.internal.publicsuffix.PublicSuffixDatabase.readTheList(Twttr:319)
       at okhttp3.internal.publicsuffix.PublicSuffixDatabase.readTheListUninterruptibly(Twttr:289)
       at okhttp3.internal.publicsuffix.PublicSuffixDatabase.findMatchingRule(Twttr:110)
       at okhttp3.internal.publicsuffix.PublicSuffixDatabase.getEffectiveTldPlusOne(Twttr:83)
       at okhttp3.Cookie.parse(Twttr:311)
       at okhttp3.Cookie.parse(Twttr:219)
       at okhttp3.Cookie.parseAll(Twttr:445)
       at okhttp3.internal.http.HttpHeaders.receiveHeaders(Twttr:201)
       at okhttp3.internal.http.BridgeInterceptor.intercept(Twttr:95)
       at okhttp3.internal.http.RealInterceptorChain.proceed(Twttr:147)
       at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(Twttr:125)
       at okhttp3.internal.http.RealInterceptorChain.proceed(Twttr:147)
       at okhttp3.internal.http.RealInterceptorChain.proceed(Twttr:121)
       at okhttp3.RealCall.getResponseWithInterceptorChain(Twttr:200)
       at okhttp3.RealCall.execute(Twttr:77)

Caused by java.lang.OutOfMemoryError: Failed to allocate a 535394406 byte allocation with 8388608 free bytes and 239MB until OOM
       at java.io.ByteArrayOutputStream.expand(ByteArrayOutputStream.java:91)
       at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:201)
       at libcore.io.Streams.readFullyNoClose(Streams.java:109)
       at libcore.io.Streams.readFully(Streams.java:95)
       at java.util.jar.JarFile.readMetaEntries(JarFile.java:337)
       at java.util.jar.JarFile.(JarFile.java)
       at libcore.net.url.JarURLConnectionImpl.openJarFile(JarURLConnectionImpl.java:136)
       at libcore.net.url.JarURLConnectionImpl.findJarFile(JarURLConnectionImpl.java:113)
       at libcore.net.url.JarURLConnectionImpl.connect(JarURLConnectionImpl.java:82)
       at libcore.net.url.JarURLConnectionImpl.getInputStream(JarURLConnectionImpl.java:215)
       at java.net.URL.openStream(URL.java:470)
       at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:444)
       at java.lang.Class.getResourceAsStream(Class.java:1175)
       at okhttp3.internal.publicsuffix.PublicSuffixDatabase.readTheList(Twttr:309)
       at okhttp3.internal.publicsuffix.PublicSuffixDatabase.readTheListUninterruptibly(Twttr:289)
       at okhttp3.internal.publicsuffix.PublicSuffixDatabase.findMatchingRule(Twttr:110)
       at okhttp3.internal.publicsuffix.PublicSuffixDatabase.getEffectiveTldPlusOne(Twttr:83)
       at okhttp3.Cookie.parse(Twttr:311)
       at okhttp3.Cookie.parse(Twttr:219)
       at okhttp3.Cookie.parseAll(Twttr:445)
       at okhttp3.internal.http.HttpHeaders.receiveHeaders(Twttr:201)
       at okhttp3.internal.http.BridgeInterceptor.intercept(Twttr:95)
       at okhttp3.internal.http.RealInterceptorChain.proceed(Twttr:147)
       at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(Twttr:125)
       at okhttp3.internal.http.RealInterceptorChain.proceed(Twttr:147)
       at okhttp3.internal.http.RealInterceptorChain.proceed(Twttr:121)
       at okhttp3.RealCall.getResponseWithInterceptorChain(Twttr:200)
       at okhttp3.RealCall.execute(Twttr:77)

[JakeWharton]

Yes. We could switch it to generate a classfile or source file.

On Sat, Nov 4, 2017, 3:25 PM Yuri Schimke [e-mail] wrote:

Is it better to encode as a field in a class or similar then? Or just live with it?

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/square/okhttp/issues/3658#issuecomment-341934123, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEEEc6hiGYidNPSs1nhaB7rvs3RAnfTks5szORSgaJpZM4P_l7X .

[yschimke]

Maybe something we should consider avoiding anyway

http://blog.nimbledroid.com/2016/04/06/slow-ClassLoader.getResourceAsStream.html https://github.com/JakeWharton/ThreeTenABP http://blog.danlew.net/2013/08/20/joda_time_s_memory_issue_in_android/

@JakeWharton

Similar to the problems with using Joda-Time on Android, the threetenbp uses a JAR resource for loading timezone information. This is an extremely inefficient mechanism on Android.

This library places the timezone information as a standard Android asset and provides a custom loader for parsing it efficiently.