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)
@marandaneto We did not use the
shouldInitializeNativeSdkflag 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-javato leave the whole handling tosentry-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 = truein the RN options since2.0.0. However I agree that it’s probably not that as they’ve been on2.0.2on RN alongside Android3.1.3.@jan-auer What I forgot to say is that we updated
sentry-androidfrom v3.1.3 to v3.2.0 and@sentry/react-nativefrom 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.