sentry-native: Extremely high Segfault crash rate on Android

Description

Hi there, we are experiencing extremely high rate of Segfault crashes since roughly one week (70k+ events right now). Currently we’re using v0.4.4 (probably transitive through the normal Sentry SDK right?). Now the latest version 0.4.5 shows an interesting changelog entry Fixed a potential segfault when doing concurrent scope modification., so could anyone tell us if this fix would apply to our Segfault crashes as well?

We’ll definitely update as soon as possible, is the new version already used somewhere? We’re using both @sentry_react-native and sentry-android in our project, I think you will release a new version of sentry-android that includes the native SDK soon, correct?

When does the problem happen

  • During build
  • During run-time
  • When capturing a hard crash (?)

Environment

All kind of Android devices, crashes like this happen to us since quite a while, but with the latest release of our app, it totally escalated and destroys our Sentry quota at the moment.

Steps To Reproduce

Log output

Couple example crash outputs (raw):

OS Version: Android 8.0.0 (AGS2-W09 8.0.0.317(OCEC431))
Report Version: 104

Exception Type: Unknown (SIGSEGV)

Application Specific Information:
Segfault

Thread 0 Crashed:
0   libhwui.so                      0x7efef09860        <unknown> + 545443059808
1   libhwui.so                      0x7efeee18e4        <unknown> + 545442896100
2   libhwui.so                      0x7efef09930        <unknown> + 545443060016
3   libhwui.so                      0x7efeee18e4        <unknown> + 545442896100
4   libhwui.so                      0x7efef09930        <unknown> + 545443060016
5   libhwui.so                      0x7efeee18e4        <unknown> + 545442896100
6   libhwui.so                      0x7efef09930        <unknown> + 545443060016
7   libhwui.so                      0x7efeee18e4        <unknown> + 545442896100
8   libhwui.so                      0x7efef09930        <unknown> + 545443060016
9   libhwui.so                      0x7efeee18e4        <unknown> + 545442896100
10  libhwui.so                      0x7efef09930        <unknown> + 545443060016
11  libhwui.so                      0x7efeee18e4        <unknown> + 545442896100
12  libhwui.so                      0x7efef09930        <unknown> + 545443060016
13  libhwui.so                      0x7efeee18e4        <unknown> + 545442896100
14  libhwui.so                      0x7efef09930        <unknown> + 545443060016
15  libhwui.so                      0x7efeee18e4        <unknown> + 545442896100
16  libhwui.so                      0x7efef09930        <unknown> + 545443060016
17  libhwui.so                      0x7efeee18e4        <unknown> + 545442896100
18  libhwui.so                      0x7efef09930        <unknown> + 545443060016
19  libhwui.so                      0x7efef09680        android::uirenderer::RenderNode::prepareTree
20  libandroid_runtime.so           0x7eff3d5d94        <unknown> + 545448091028
21  libhwui.so                      0x7efeec3b44        <unknown> + 545442773828
22  libhwui.so                      0x7efeec784c        <unknown> + 545442789452
23  libhwui.so                      0x7efeec7664        <unknown> + 545442788964
24  libhwui.so                      0x7efeecdf20        android::uirenderer::renderthread::RenderThread::threadLoop
25  libutils.so                     0x7f010a06f8        android::Thread::_threadLoop
26  libandroid_runtime.so           0x7eff38c3a0        android::AndroidRuntime::javaThreadShell
27  libc.so                         0x7f003f91bc        <unknown> + 545465012668
28  libc.so                         0x7f003b0ee8        <unknown> + 545464717032
29  <unknown>                       0x0                 <unknown>



EOF
OS Version: Android 10 (QPYS30.52-22-8-7)
Report Version: 104

Exception Type: Unknown (SIGSEGV)

Application Specific Information:
Segfault

Thread 0 Crashed:
0   libandroid_runtime.so           0xb0dd0420          <unknown> + 2967274528
1   libandroid_runtime.so           0xb0dd037d          <unknown> + 2967274365
2   boot-core-libart.oat            0x70f303bb          <unknown> + 1894974395



EOF
OS Version: Android 10 (EML-L29 10.0.0.171(C432E5R1P3))
Report Version: 104

Exception Type: Unknown (SIGSEGV)

Application Specific Information:
Segfault

Thread 0 Crashed:
0   libhermes.so                    0x780419ab00        <unknown> + 515464866560
1   libhermes.so                    0x780410d908        <unknown> + 515464288520
2   libhermes.so                    0x78040d55fc        <unknown> + 515464058364
3   libhermes.so                    0x78040d681c        <unknown> + 515464063004
4   libhermes.so                    0x78040d5940        <unknown> + 515464059200
5   libhermes.so                    0x78040c5b10        <unknown> + 515463994128
6   libhermes.so                    0x78040d4a0c        <unknown> + 515464055308
7   libhermes.so                    0x78040d7e38        <unknown> + 515464068664
8   libhermes.so                    0x78040d5940        <unknown> + 515464059200
9   libhermes.so                    0x78040c5b10        <unknown> + 515463994128
10  libhermes.so                    0x78040d4a0c        <unknown> + 515464055308
11  libhermes.so                    0x78040d7e38        <unknown> + 515464068664
12  libhermes.so                    0x78040d5940        <unknown> + 515464059200
13  libhermes.so                    0x78040c4e2c        <unknown> + 515463990828
14  libhermes.so                    0x7804146b64        <unknown> + 515464522596
15  libhermes.so                    0x78040c5fb0        <unknown> + 515463995312
16  libhermes.so                    0x78040d49f4        <unknown> + 515464055284
17  libhermes.so                    0x78040d7e38        <unknown> + 515464068664
18  libhermes.so                    0x78040d5940        <unknown> + 515464059200
19  libhermes.so                    0x78040c5b10        <unknown> + 515463994128
20  libhermes.so                    0x78040b610c        facebook::hermes::HermesRuntimeImpl::call
21  libhermes-executor-release.so   0x7811a7d338        facebook::jsi::Function::call<T>
22  libhermes-executor-release.so   0x7811a7d194        <unknown> + 515692286356
23  libhermes-executor-release.so   0x7811a775e8        std::__ndk1::__invoke_void_return_wrapper<T>::__call<T>
24  libhermes-executor-release.so   0x7811a7a038        facebook::react::JSIExecutor::callFunction
25  libreactnativejni.so            0x77f3e61d5c        <unknown> + 515193052508
26  libreactnativejni.so            0x77f3e63354        <unknown> + 515193058132
27  libreactnativejni.so            0x77f3e29d4c        <unknown> + 515192823116
28  libreactnativejni.so            0x77f3e1aa74        facebook::jni::detail::MethodWrapper<T>::dispatch
29  libreactnativejni.so            0x77f3e1a9f0        facebook::jni::detail::FunctionWrapper<T>::call
30  base.odex                       0x782e7d8780        <unknown> + 516176054144



EOF

If you need more information, just let me know… Thanks in advance!

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 17 (10 by maintainers)

Most upvoted comments

@marandaneto We did not use the shouldInitializeNativeSdk flag as far as I know.

Final update

Sorry for the late reply, but it took us quite some time to ship the release to all users. We are now fully live since some days and don’t see any new Segfault crashes, so I’d say this is fixed. Still not 100% sure what the actual problem was, but since we are good again, I’ll close this issue and definitely advise no one to use both SDKs at the same time.

Thanks a lot for the help everybody!

Hi everybody, quick update here:

We did some changes under the hood (enabled native symbolication and removed the initialization of sentry-java to leave the whole handling to sentry-react-native) and published a new release in our beta group. So far, we don’t see any strange native crashes, we’ll slowly take the release to the public channel in the coming days and hope it stays like that.

@marandaneto Our special handling with both SDKs was due to the fact, that we didn’t want to miss out on crashes, that happen directly at startup of the app before React Native was initialized (and therefore sentry-react-native). However, we’ll try to stick with the Google Play crash reporting for these kind of crashes now to see if that’s enough for us…

I’ll keep you guys updated if there are any news!

Cheers

@marandaneto Yes it actually is possible to sync scope from RN -> Java -> Native if they set enableNdkScopeSync = true in the RN options since 2.0.0. However I agree that it’s probably not that as they’ve been on 2.0.2 on RN alongside Android 3.1.3.

@jan-auer What I forgot to say is that we updated sentry-android from v3.1.3 to v3.2.0 and @sentry/react-native from v2.0.2 to v2.1.0 with the release that has exploding Segfault crashes, so this is probably related to some changes in the implementation. Additionally, we don’t see the high number of crashes in our Play Console, which normally correlates pretty good.