6.0.3 iOS native crash - Attempted to dereference null pointer. #3112
Labels
Comments
|
Another one popped out today... May be related: We have been getting a significant amount of crashes ever since 5.0.3 to 6.x migration from Realm. |
|
@cristianoccazinsp did you not get these errors with 5.03? I just started testing my first app with realm and already ran into these errors (specifically the 2nd one you posted) |
|
I definitely got various similar errors with 5.0.3, but they have become much more frequent with 6.x, and also look like new errors (and possibly even a memleak). |
|
Another similar one just popped, yet different: Why would "sync session" even be used if the database is used entirely offline? Either way, there are about 10 crashes / day for an app that's actively used by about 2000 people. The number seem to have increased significantly after the 5 to 6 migration. Looking at breadcrumbs, this one seemed to happen in a very curious scenario:
|
|
Here's another crash stack trace, looks like this is a recurring crash. I wish I could provide more info: |
|
Sorry for the spam, here's another one (new) crash, a SIGABRT this time. These crashes are happening too frequently. |
|
Crash logs from XCode reporting. Interestingly, it says it should be reported here:
@kneth I have attached the XCode crash log files, perhaps this can help with diagnosing the problem. |
|
This is a new one, also on 6.0.3: Perhaps this is caused by having a single global realm instance across the app instead of creating a new one before each query? |
Closed
|
@cristianoccazinsp As we are trying to get a hold on this issue, I would like to know if you see the same error on Android? |
|
Haven't seen this on Android at all. |
Can it be related to #3162? |
|
@kneth the crash seems different, and I'm not entirely sure how to reproduce that one. Does realm just crash if the app is in background and the phone is locked? I'm sure I have seen the app run just fine in that situation since we use background tasks all the time. |
|
@cristianoccazinsp When an iOS app is suspended (in recent iOS versions), the data and files are encrypted. Once the app is activated, the decryption might happen later than Realm's access to the realm files. Then Realm will believe the file is corrupted. Unfortunately it is easy to solve (a pure Objective C or Swift app can be fixed: realm/realm-swift#5912 (comment)). I wanted to bring it to your attention and have you verify it is not the same issue. |
|
@kneth I will try to reproduce the scenario locally to see if it is in fact the same issue. I never noticed any crash when the phone is suspended though, but perhaps I wasn't giving it enough time. On the other hand, the crash / stack trace message seems different, doesn't it? |
|
@cristianoccazinsp Thanks for the update.
Indeed but corruption (true or due to an encrypted file) will turn up is many random ways. You mention that you are not using sync, but the original stack trace hints otherwise: |
|
Hmm, I'm definitely not using sync, at least not on purpose. Having said this, I have never been able to reproduce the crash myself, not even locking the device. Would it be too complex to add some extra defensive programming here and there to add null checks and prevent crashes? It would be great to have just the query crash rather than the whole app, even if we don't know why the object was suddenly garbage collected / null. |
It is possible, and a JavaScript exception will be better in many cases. I'll add it to the backlog and get it prioritized. |
|
I keep seeing iOS crashes with similar stack traces, and they all seem to happen with very little free memory (~45mb reported by the crash analytics tool). Not sure how easy it would be to debug a possible memory leak within the C++ or Objective C Realm's code, or even in the non Realm code. I've tried to profile the app for a while and didn't observe any memory leak or anything that would cause the app to end up with so little memory. Here's another stack trace: |
|
@cristianoccazinsp We have released v6.1.1 with core fixes which addresses these issues. Could I ask you to upgrade & test this out? |
|
I will, it may take some days or a few weeks until the release is live and we get enough testing, but I will keep you posted. |
|
@cristianoccazinsp any update on this? |
|
@steffenagger I'm still seeing crashes. See the following stack trace (different app but updated Realm (6.1.2) with the same code): |
Does it also happen when you don't sort? |
|
I will need to go through the various stack traces to see if there are other similar crashes with realm in it, but it's impossible to tell since it happens randomly and only in production (i.e., can't reproduce locally). |
|
Here's another crash report, this time from XCode (seems more comprehensive than the above): |
|
Seeing that all previous stack-traces springs from @cristianoccazinsp It could be that the errors we're seeing here, happens when the app is closed/goes to the background AND is terminated prematurely (in context of RN). |
|
@steffenagger I have updated to RN 0.62 a while ago and some of these crashes still happen (like the one from the most recent stack trace I've uploaded). |
|
The stacktrace is a bit confusing since it looks like you are using sync: Moreover, do you observe the crashes on Android? |
|
@kneth I'm definitely not using sync. Also, no, I am only seeing this on iOS. Lastly, the same crash occurred to the same user twice already in less than 1 day, so it is also that happens "frequently". I'm sorry I can't get a more detailed stack trace. |
|
Hey @kneth, just to dive in here, I'm also seeing crash logs similar to @cristianoccazinsp's most recent one - only on iOS and not using sync. Would it help for me to also upload an example? Another note, is that Sentry (and our own internal logging systems) show that the user has put the app in the background prior to the crash occurring. Might be related? |
I think it is actually an important observation. When you bring back an app from the background, the (encrypted) file system might not be ready so quickly. And since Realm instances are tied to Realm files (using |
|
@kneth Interesting! We had a suspicion internally that something like that would be the cause. We’ve been trying to guard against it at the JS layer by observing app state changes (and we only access realm from a wrapper, rather than multiple points in the codebase, so there's only one point to guard against), but I presume this is something that’ll need to be handled within Realm itself? Would you be able to advice on any potential remedies, for until a fix for this is released? |
|
@kneth if that was the case, shouldn't the errors be much more "friendlier" or reveal such issue? Also, shouldn't the crash be much more reproducible? Reading from here https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/encrypting_your_app_s_files?language=objc , which encryption level do you think Realm files use? My app works in background, and realm works in background just fine (most of the time at least), so it is either |
|
Here's another one, no background it seems, or right after getting into background.
|
|
@kneth I've just got this kind of crash during debugging. The crash seemed to happen right after "swiping out" the app (killing it) and while realm was doing something. Here's a capture of the debugger stack trace, hopefully it helps a bit.
|
|
@cristianoccazinsp Thank you for sharing. We will create a simple app and try to reproduce it by killing the app while doing some Realm operations. |
I created an app that can reproduce this latest reported crash: https://github.com/kraenhansen/realm-js-issue-3112 .. perhaps that will provide us a hint to eventually solve some of the shutdown related crashes. |
|
I'm facing the same error "Attempted to deference garbage pointer ..." daily with our production app. Fortunately, no users have noticed the crashes, which would indicate that the crash probably happens only when the app is closing / inactive. The realm DB is encrypted and the version is 6.1.X. Regular offline use without syncing. |
|
We're also seeing these in our production app which uses Realm v.10.2.0 |
|
@kneth just checking in, has this been resolved or is it still under investigation? Happy to provide more details / logs if required. Thanks! :) |
|
Unfortunately we haven't been able to find the root cause yet. @ryanbourneuk Do you see the same pattern as described earlier (that it happens when the app is killed/swiped out)? |
|
I've seen this pretty consistently, a few a week. Always seems to be in the background. Not sure if it's being backgrounded, or coming out.
|
|
@kneth i see this in 100% background (swiped out), 100% iOS 14. Realm: 10.2.0 |
|
We also see similar crashes in one app (realm 10.8.0 / RN: 0.66.1): I think also thread 0 from same crash report is interesting, but dont know enough iOS to tell if this is related: |
|
FYI, still getting multiple of those crashes daily in version 10.20.0 and RN 0.67.3. |
|
Looks like this is still happening on 10.20.0-beta.2 and iOS 15.3. The crash happened with the app in background right after swiping it out (to fully terminate it). Normally invisible to the user, but makes a mess with crash statistics. @kneth was there another bug report for this kind of crash or is this the right place? I feel like I've opened way too many similar crashes, but this is the one that has the most comments. |
|
@cristianoccazinsp My best guess is that there is a race condition when you swipe out an app - and it indicates that we hang on for too long. Since you experience it with 10.20.0-beta.2, a fresh issue is better. |
|
@kneth it's not really an app hang, but rather a crash right after the app is being terminated. Somewhere in the code trying to use resources that have been already released. |
|
@cristianoccazinsp Yes, I agree that it must the order of events but I am not sure if it is deterministic. |
|
@kneth I've opened a new issue with as much detail as I could gather, including multiple stack traces (#4473) One thing I've discovered when building Objective-C/Swift code for other native modules, memory exceptions will not be handled by any try/catch block, they will always crash the app, no matter what, so proper cleanup/access of pointers is required. |
|
Since v12 will be a complete rewrite, we assume that the bug has been fixed. Try outer latest release candidate: If the issue is still observed, please create a new issue. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Goals
Regular offline use (no syncing)
Expected Results
No crashes
Actual Results
Random crash due to garbage / null reference.
The following crash was reported from Realm code.
While I understand this is probably extremely hard to debug/reproduce in a controlled environment, it would be great for Realm to attempt to handle null pointer exceptions in a way that won't crash the whole app, but rather cause a query error or something. This is probably one out of 10 different realm-related native crashes that are reported daily from our crash reporting tool.
Similar crashes:
#3111
#2853
#2828
#2713
Steps to Reproduce
Regular realm usage without any sync/online features.
Code Sample
Regular offline use, no special code required.
Version of Realm and Tooling
The text was updated successfully, but these errors were encountered: