Crash in production is not reported to Sentry

[fzyzcjy]

Platform

Android

Obfuscation

Enabled

Debug Info

Enabled

Doctor

latest

Version

latest

Steps to Reproduce

When using my app in production environment, it becomes janky and then crashes (I suspect it is some memory issues, but there is no report sent to Sentry so I cannot guarantee). The problem is that, the crash is never sent to Sentry.

I can understand that, if the code or Dart VM or whatever crashes so quickly that Sentry code does not have a chance to execute, it will not report anything. However, can we somehow report a bit of thing using the Android Sentry? Or, using even more low-level mechanism?

More formally,

1. Is it possible to report crashes of Android app to Sentry, when Dart VM is unhappy and will not execute (Sentry) Dart code
2. Is it possible to report crashes to Sentry, when the app is killed by Android system without warnings

(These proposals may or may not directly solve my problem in production environment above, but instead is more general to make Sentry better)

Expected Result

Actual Result

Are you willing to submit a PR?

Yes!

[marandaneto]

@fzyzcjy thank you for the feedback.

The problem is that, the crash is never sent to Sentry.

Did the app actually crash or at least trigger an unhandled error? Sentry is only able to capture errors that are triggered by the platform or if you manually call Sentry.capture...).

I can understand that, if the code or Dart VM or whatever crashes so quickly that Sentry code does not have a chance to execute, it will not report anything. However, can we somehow report a bit of thing using the Android Sentry? Or, using even more low-level mechanism?

Sentry already listens to errors in every layer of the app for Android, the Dart VM, Flutter, the Android uncaught exception handler (Java/Kotlin), and also in the Native layer (C signal handlers), so if none of them are triggered, the exception won't be captured.

If you are having memory leaks in general, you need something similar to https://square.github.io/leakcanary/
In this case, the app becomes janky but doesn't actually crash, so Sentry cannot do anything about it.
There's a tool for leak detectors in Flutter, but it only works in debug mode, unfortunately.

I'd love more context on this issue or even a reproducible example.

[fzyzcjy]

Did the app actually crash or at least trigger an unhandled error? Sentry is only able to capture errors that are triggered by the platform or if you manually call Sentry.capture...).

The app crashes actually - i.e. I was playing with it and suddenly it exits.

Sentry already listens to errors in every layer of the app for Android, the Dart VM, Flutter, the Android uncaught exception handler (Java/Kotlin), and also in the Native layer (C signal handlers), so if none of them are triggered, the exception won't be captured.

Looks good!

If you are having memory leaks in general, you need something similar to square.github.io/leakcanary
In this case, the app becomes janky but doesn't actually crash, so Sentry cannot do anything about it.
There's a tool for leak detectors in Flutter, but it only works in debug mode, unfortunately.

I think so - if it is really a leak I need to use specialized tools to solve it. But as I mentioned above, it appeared as a crash.

At minimum, what I hope is that, I can know there exists a crash, s.t. I can know how frequently my app is crashing.

I'd love more context on this issue or even a reproducible example.

Feel free to ask anything! As for reproduction, I even cannot reproduce it on my app, so maybe not any currently...

[fzyzcjy]

Another (maybe not reasonable) thought: Is it possible we utilize Android system level crash report? e.g. sth like Android vitals (I cannot use Google Play so cannot have that console...)

[marandaneto]

@fzyzcjy on iOS, we have this: https://docs.sentry.io/platforms/apple/guides/ios/configuration/watchdog-terminations/ which pretty much describes something similar to what you want, if we cannot detect something before it crashes, it detects on restart based on heuristics.
The problem is that we've never seen that on Android, its crash handlers always are able to detect and report crashes before the process dies totally, the reason is that the Dalvik/Art always throws an eg OutOfMemoryError when something heavy is allocated, so you can recover (deallocate stuff, call GC...) and the SDK can detect the issue.

What you can do to investigate your issue is looking at events and see if you find occurrences of breadcrumbs of low memory, the Android SDK adds crumbs for that, See https://github.com/getsentry/sentry-java/blob/baa4b26a8940ca5785af4ee5cf8fa18b8aedeadd/sentry-android-core/src/main/java/io/sentry/android/core/AppComponentsBreadcrumbsIntegration.java#L140-L145

If you find some of those, maybe the reason is indeed a memory leak.

Hopefully, dart-lang/leak_tracker#25 is released for production so we can report memory leaks as well.

[fzyzcjy]

Thank you for the information!

The problem is that we've never seen that on Android, its crash handlers always are able to detect and report crashes before the process dies totally, the reason is that the Dalvik/Art always throws an eg OutOfMemoryError when something heavy is allocated, so you can recover (deallocate stuff, call GC...) and the SDK can detect the issue.

That's interesting! Then maybe my crash is due to something else that I have not guessed before. Anyway all I can confirm is that, it is a crash without reporting so Sentry, and anything else is guesses since I have no clue.

What you can do to investigate your issue is looking at events and see if you find occurrences of breadcrumbs of low memory, the Android SDK adds crumbs for that

Well, no issues are reported at all, thus I cannot see any breadcrumbs...

[marandaneto]

@fzyzcjy you can look at random error events and check if they have the low memory crumbs, even though they are not related to this issue at all, it might be an indicator that you are indeed having memory leak issues.
I guess I can't do much here without a repro, unfortunately, but let us know if you manage to repro this or find a pattern.

[fzyzcjy]

Good idea! I will add "low memory events" tracking in my own infra and see how frequently it is happening.

I guess I can't do much here without a repro, unfortunately, but let us know if you manage to repro this or find a pattern.

I know, it is really hard to debug without repro or any clues. I will update when finding anything more!

[marandaneto]

Closing the issue as a part of large repository cleanup, due to it being inactive and/or outdated.
Please do not hesitate to ping me if it is still relevant, and I will happily reopen and work on it.
Cheers!