Some Sentry XML options (eg.: traces.user-interaction.enable) cause a C++ SIGSEV SIGFAULT error on API 21

[rolandsarosy]

Integration

sentry-android

Build System

Gradle

AGP Version

8.2.0

Proguard

Disabled

Version

7.6.0

Steps to Reproduce

1. Have Sentry enabled, and run it on an API 21 device.
2. Enable the following options in XML:

        <meta-data
            android:name="io.sentry.traces.user-interaction.enable"
            android:value="true" />
        <meta-data
            android:name="io.sentry.traces.sample-rate"
            android:value="1.0" />
        <meta-data
            android:name="io.sentry.traces.profiling.sample-rate"
            android:value="1.0" />

3. Go into your (Jetpack Compose UI) application, and start clicking on various UI elements in rapid succession. (The issue 100% happens with regular use as well, but this is the easiest way to reproduce it.)
4. After a while, the interactions will slow down a bit, then, the crash happens.

Expected Result

Application should not cause SIGSEV C++ errors on API 21.

Actual Result

The application first slows down, then crashes with a native C++ SIGSEV SIGFAULT error. Often the crash cannot even be caught by Sentry itself. When it can be, the exception looks something like this.

You can find our exact list of libraries and more information about our setup in the stacktrace above, but I'm here to answer any questions you have too.

We first encountered this issue on our android-based PoS terminals running API 21, but we were able to reproduce the issue on an emulator running the same API level too.

If you guys are unable to reproduce this issue, I'll see if I can't procure some sort of simplifed part of the codebase to help.

Something to note (maybe?) is that we're setting up Sentry with a proxy:

        SentryAndroid.init(this) { options ->
            options.environment = BuildConfig.FLAVOR
            options.proxy = SentryOptions.Proxy(BuildConfig.SENTRY_APN_PROXY_IP, BuildConfig.SENTRY_APN_PROXY_PORT)
        }

The issue goes away as soon as we remove the 3 parts mentioned above from the Manifest.

[markushi]

Thanks for reaching out @rolandsarosy, let me try to reproduce this on our end.

[markushi]

It looks like I can reproduce the issue on an API level 21 devices. @stefanosiano this only seems to be happening when profiling is active, have you ever encountered any API level 21 specific issues?

Logcat:

A  Fatal signal 11 (SIGSEGV), code 1, fault addr 0xa4c in tid 6192 (Sampling Profil)
I  *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I  Build fingerprint: 'generic_arm64/sdk_google_phone_arm64/generic_arm64:5.0.2/LSY66K/8789838:eng/test-keys'
I  Revision: '0'
I  ABI: 'arm64'
I  pid: 6066, tid: 6192, name: Sampling Profil  >>> <app> <<<
I  signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xa4c
I      x0   00000000002dc6c0  x1   000000000000000e  x2   0000000000000a5a  x3   0000000000000a4c
I      x4   0000000000000000  x5   000000000004459c  x6   0000000000000002  x7   000000756a4828b4
I      x8   0000000000000000  x9   000000000000000a  x10  000000000000000e  x11  000000000e54919c
I      x12  0000000000000018  x13  000000006633952e  x14  0000000000000000  x15  0000000070810bf0
I      x16  0000000000000000  x17  0000000000000a4c  x18  00000000000017b2  x19  0000000000000a4c
I      x20  000000756a482880  x21  0000000070810bf0  x22  0000000000000000  x23  0000000000000001
I      x24  0000000000000a4c  x25  000000000004459c  x26  0000007579769340  x27  0000007579774500
I      x28  000000757eefb000  x29  000000756afef910  x30  000000000070810b
I      sp   000000756afef910  pc   000000757ed98158  pstate 0000000060000000
I  
   backtrace:
I      #00 pc 0000000000310158  /system/lib64/libart.so (art::Trace::LogMethodTraceEvent(art::Thread*, art::mirror::ArtMethod*, art::instrumentation::Instrumentation::InstrumentationEvent, unsigned int, unsigned int)+284)
I      #01 pc 0000000000310704  /system/lib64/libart.so (art::Trace::CompareAndUpdateStackTrace(art::Thread*, std::__1::vector<art::mirror::ArtMethod*, std::__1::allocator<art::mirror::ArtMethod*> >*)+500)
I      #02 pc 00000000003108cc  /system/lib64/libart.so (art::GetSample(art::Thread*, void*)+100)
I      #03 pc 000000000030697c  /system/lib64/libart.so (art::ThreadList::ForEach(void (*)(art::Thread*, void*), void*)+48)
I      #04 pc 00000000003109e8  /system/lib64/libart.so (art::Trace::RunSamplingThread(void*)+236)
I      #05 pc 000000000001eab8  /system/lib64/libc.so (__pthread_start(void*)+52)
I      #06 pc 000000000001ae44  /system/lib64/libc.so (__start_thread+16)
I  
   Tombstone written to: /data/tombstones/tombstone_00

tombstone_00.txt

[markushi]

Next steps:

• Try other API levels < 26
• Dump native memory / log free memory right before the crash

[markushi]

I the meantime disabling user interaction tracing would at least prevent the crashes

   <meta-data
            android:name="io.sentry.traces.user-interaction.enable"
            android:value="false" />

[rolandsarosy]

Yeah, we've disabled user-interaction altogether. If the issue won't get resolved in the near future (which would be understandable as this seems like a harder-to-solve issue), we'll look into programmatically enabling/disabling user-interaction depending on API levels.

[markushi]

Quick update: After some further investigation we could reproduce the issue, but only on API level 21 devices. There's seems to be no clear root cause, and the stack traces actually indicate that the system profiler seems to be the root cause.

If you can reproduce this issue on newer device (>= API 22) please let us know and we'll take another look.

[rolandsarosy]

We could only reproduce the issue on API level 21 devices too. API level 22 and above did not replicate this behavior.

May I ask why is it being marked as done, however? This issue still persists on API level 21 and API level 21 is officially supported by Sentry.

[romtsn]

@rolandsarosy from what I can tell we've decided to just drop support for profiling on API 21 in #3478, which should mitigate the issue. There's no way for us to fix it properly, as we're relying on the OS profiler, and the original issue seems to lie there.