sentry-cocoa: OutOfMemory error logged when the app is manually killed after the SDK is closed.
Environment
Which SDK and version? react-native-sentry 2.5.1 with sentry-cocoa 7.0.0 (but I checked and master probably has the same issue).
Steps to Reproduce
[SentrySDK close]followed byexit(0);.- App resumes, initializes the SentrySDK and logs OutOfMemory sentry event.
Expected Result
App should resume and not log an event because the SDK was closed during the crash. I can prevent this by disabling OOM tracking, but I would prefer to keep it on and have the SDK not record crashes that occurred after the SDK was closed. We re-initialize the SDK when the app launches again, and it compares to the state prior to the close, and determines it was a crash.
Actual Result
Sentry logged an OutOfMemory event.
The OS most likely terminated your app because it overused RAM.
Proposed Solution
The SentryAppState should be reset to willTerminate = YES when the SDK is closed.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 5
- Comments: 21 (7 by maintainers)
Commits related to this issue
- fix: Sending OOM when SDK is closed The SDK reported OOMs after closing it. This is fixed now by deleting the app state. Fixes GH-1185 — committed to getsentry/sentry-cocoa by philipphofmann 3 years ago
- fix: Sending OOM when SDK is closed (#1487) The SDK reported OOMs after closing it. This is fixed now by deleting the app state. Fixes GH-1185 — committed to getsentry/sentry-cocoa by philipphofmann 3 years ago
Sadly, I’m still getting this error. We are using Sentry via its React Native integration, which is on 7.3.0. It does not seem to be a legitimate OOM, and we are only getting it in our staging version where we recently upgraded sentry to the latest version (2.4.2 => 3.1.1).
The Podfile.lock shows that
Sentry/Core (= 7.3.0)is installed. It previously showed:Sentry/Core (= 6.1.4).I think this should be related to https://github.com/getsentry/sentry-cocoa/issues/1618 @denizdogan.
Thanks, for reporting this. I’m going to reopen this again. Most likely this is due to
exit(0), which our current OOM logic can’t detect reliably. We need to investigate how we can fix these false OOMs. Sorry about the inconvenience.