bug(okhttp): Fatal SIGSEGV on Android 14+ JIT due to R8 optimization mismatch with OkHttp bytecode manipulation #6127

Integration

sentry-okhttp

Build System

Gradle

AGP Version

8.x

Proguard

Enabled

Other Error Monitoring Solution

No

Version

8.53.0

Steps to Reproduce

1. Enable Sentry HTTP Auto-Instrumentation in an Android project using the Sentry Android Gradle Plugin:

   sentry {
       tracingInstrumentation {
           enabled = true
           features = [sentryOkHttpFeature] as Set
       }
   }

2. Compile the application in Release mode with R8 Full Mode enabled:

   android.enableR8.fullMode=true

3. Run the compiled APK on any Android device running Android 14, 15, or 16 (equipped with updated Google Play Mainline ART modules).
4. Trigger rapid concurrent network requests (e.g., loading a feed) to quickly increase the execution count of OkHttp's internal execution path, forcing the ART runtime to promote the method to a "hot method" and trigger JIT compilation.

Expected Result

The network calls complete smoothly and Sentry captures HTTP spans and breadcrumbs correctly without any native stability issues.

Actual Result

The background JIT compilation thread of ART (Android Runtime) crashes with a fatal native SIGSEGV (11) segmentation fault while compiling okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain(), causing the application process to die immediately.

Obfuscated Native Tombstone Stacktrace:

    at __start_thread (<unknown>)
    at __pthread_start (<unknown>)
    ...
    at okhttp3.internal.connection.RealCall.G0 (<unknown>)  # R8 optimized getResponseWithInterceptorChain
    at io.sentry.okhttp.b.f (<unknown>)                      # Obfuscated SentryOkHttpEventListener

Detailed Technical Analysis

1. ASM Bytecode Injection: The sentry-android-gradle-plugin uses ASM bytecode manipulation (defined in ResponseWithInterceptorChainMethodVisitor.kt) to inject a complex while loop that allocates registers/variables on the fly to detect and add SentryOkHttpInterceptor inside OkHttp's okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain().
2. Missing / Obsolete Consumer Proguard Rules:
   • The sentry-okhttp module is packaged as a pure Java .jar library, meaning it cannot ship native Android .aar consumer proguard files.
   • The main sentry-android-core module ships Proguard rules, but they are obsolete: they reference the old package name io.sentry.android.okhttp.SentryOkHttpInterceptor instead of the modern io.sentry.okhttp.SentryOkHttpInterceptor (refactored in v8.x). See line 46-47 in sentry-android-core/proguard-rules.pro.
   • Therefore, there are no Proguard keep rules anywhere in Sentry's libraries protecting the io.sentry.okhttp.** package from optimization.
3. R8 Optimization Conflict: Since Sentry OkHttp classes are completely unprotected, R8 (under Full Mode) aggressively optimizes, obfuscates, and inlines them (e.g., companion objects and helpers) on top of the raw bytecode manually woven by the Sentry ASM visitor. This generates inconsistent local variables allocation and corrupt StackMapTable frames in the final .dex file.
4. JIT Compiler Crash: When ART's background JIT compiler thread (which is shared across Android 14+ via mainline system updates) attempts to compile this corrupt method into native ARM64 instructions, the strict verificator in ART fails to resolve the incorrect stack maps, resulting in a fatal native memory pointer disintegration (SIGSEGV).

Temporary Workaround

Adding these rules to the application's proguard-rules.pro file completely resolves the issue, since it prevents R8 from inlining/optimizing the woven bridge:

# Prevent R8 from optimizing/inlining the unprotected Sentry OkHttp classes
-keep class io.sentry.okhttp.** { *; }
-dontwarn io.sentry.okhttp.**

# Protect internal RealCall bytecode manipulated by the plugin
-keep class okhttp3.internal.connection.RealCall { *; }