sentry-native
sentry-native copied to clipboard
getsentry
Android Crash on newer SDK version
Environment
SaaS (https://sentry.io/)
Version
No response
Steps to Reproduce
- Upgrade to
sentry.java.androidversion5.5.2 - Use it as you normally would
Expected Result
No Sentry's SDK internal crash should happen.
Actual Result
An internal crash does happen from time to time (never experienced before version 5.5.2).
OS Version: None None (None)
Report Version: 104
Exception Type: Unknown (SIGBUS)
Application Specific Information:
BusError
Thread 0 Crashed:
0 <unknown> 0x358b358b358b358b <unknown>
1 libsentry.so 0x7f7601ac10 sentry__transport_dump_queue (sentry_transport.c:113)
2 libsentry.so 0x7f76021180 handle_ucontext (sentry_backend_inproc.c:276)
3 libsentry.so 0x7f76020ebc handle_signal (sentry_backend_inproc.c:300)
4 app_process64 0x555d61ebd4 InvokeUserSignalHandler
5 libart.so 0x7f98ea1cfc art::FaultManager::HandleFault
6 linker64 0x7f9d2404e0 __kernel_rt_sigreturn
7 libart.so 0x7f98c387fc art::Mutex::ExclusiveLock
8 libart.so 0x7f98c39c74 art::ConditionVariable::Wait
9 libart.so 0x7f98e21ec8 art::Monitor::Wait
10 libart.so 0x7f98e2296c art::Monitor::Wait
11 system@[email protected] 0x733849e8 <unknown>
More info here:
@39otrebla, how often do you get this error? Does it happen only on specific devices?
Moving this to the java repo as this is related to the Java/Android SDK.
@Swatinem would you mind having a look? the underlying sentry-native version is https://github.com/getsentry/sentry-native/releases/tag/0.4.12
This is interesting, the code is this:
https://github.com/getsentry/sentry-native/blob/521860373df1cc02607546c3474d78b42042b459/src/sentry_transport.c#L113
So it is calling a function pointer, with a value that looks pretty much like some kind of poison value (358b358b358b358b). I will have a look.
Super interesting that sentry can report a crash that happens during its own crash handler.
@philipphofmann not very often, but the number of sessions on that app version is still low (it is an update with incremental rollout). We have had literally millions of sessions with no crashes in the past year, and we started seeing this with much lower numbers so we thought something may be wrong.
@Swatinem thank you for looking into this. Unfortunately, we have no context: the crash came up without any information other than the trace and an auto-generated user UUID.
Yes, it's super interesting it can report a crash in its own crash handler. By the way, we have OOM tracking enabled, in case that helps).
Given the stack trace, and that you do get the crash itself (and probably the original crash that caused this one), I figure that the SDK itself operates fine, and on restart, the transport was working properly (handing of the crashes to the Java part for sending).
This makes me wonder what might have poisoned the memory of the transport (which otherwise works fine). Does this coincide with any other crash reports?
@39otrebla, can you maybe reply to the question of @Swatinem
Does this coincide with any other crash reports?
@Swatinem I'm not sure how to reconstruct whether it coincides with other crashes. Of course, there are other few crashes in the same release, but none of them is close (the closest is more than 30 minutes before) or reported on the same user ID.
We very recently reported a crash on the Network Tracking component of the Sentry Cocoa SDK. This too did appear in recent versions of the SDK as well, perhaps is it related? I know they are different SDKs, but maybe you are using shared libs under the hood...
Cocoa is a completely different codebase that does not share any code with sentry-native/NDK/Android.
The reason I am curious is because the crash handler crashed while handling a crash. And I wonder if the original reason made it to sentry as well.
I’m also not sure if we have some kind of re-entrancy protection here. This could potentially result in infinite recursion…
@Swatinem have you identified a possible code path that would lead to corrupted memory or something? not sure how we can help here.
I haven’t made any progress on this.
@Swatinem should we maybe move this issue to sentry-native repo then? Since the linked code lives there.
@39otrebla, did those crashes ever reoccur? There is very little to act on based on the exchange in the pre-transfer issue.
