Closed stevenmathers closed 2 years ago
I mean, I tested the work around I released by corrupting the realm.file in my debug environment and observing the exception go on to delete the file and create a new realm in its place. I was confident this would at least prevent the crash and give me time to work out the root cause. How could it not work? Im not sure. We open the db at startup one time and retain a reference to it, never closing it. Nothing at all has changed in that respect for a long time. It may not be best practice (not sure) but it hasnt failed us before so there has been no reason to change.
My most pressing concern is protecting users from the crash. Why catching the exception and deleting the problematic xxx.realm file NOT work?
1) Either its not a problem with the file and its a problem with Realm 10.8.0 itself when it tries to open a Realm, even a new one, but then....we have been using this version for ages and had zero problems, but with this one release all of a sudden boom.
Q) would there be any dependencies that may have upgraded a minor version and been dragged into this release when it was built? What is Realm dependent on that might have a symptom like this?
2) Would I need to delete xxx.realm.lock and anything in xxx.realm.management as well in order for my workaround to work in the field? it worked in my local test when I basically replaced xxx.realm with a random text file (simulating unreadable realm file). But perhaps the issue is not the xxx.realm file but one of the other files that I am not deleting?
one more clue - I have had a report from 2 users that the problem spontaneously resolves itself in some cases (in the case of repeated fresh installs)
what I mean is that once they 'get the issue' they can delete the app and reinstall the app, and the problem persists - first app launch is fine, but subsequent app launches fail. And they can repeat this multiple times with multiple fresh installs and it keeps failing in the same pattern. Except...sometimes after a few repeats of this process, the problem 'goes away'
you can see why I am scratching my head
@stevenmathers Are you using encrypted realms? Nvm :)
The "Invalid mnemonic" error is thrown when one tried to access an encrypted realm with the wrong key/no key. How are you managing the keys (e.g., are the users entering them themselves when using the app)?
Hiya, Im using a static hardcoded key - not the most secure, but its unable to change, so we can rule out the wrong key.
heya, yes we are
we are using a static hardcoded key, so ist not a key mixup or a no-key situation.
On Fri, Feb 18, 2022 at 8:32 PM FFranck @.***> wrote:
@stevenmathers https://github.com/stevenmathers Are you using encrypted realms?
— Reply to this email directly, view it on GitHub https://github.com/realm/realm-js/issues/4358#issuecomment-1044214362, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKQ2O6PW2S35PHC2F4GJOZ3U3YG3TANCNFSM5OWPGJQQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID: @.***>
Are you doing any copying of files, either at the filesystem level, or through the writeCopyTo()
method?
The users' database files seem to have become corrupted. The "mnemonic" Realm.open()
looks for is the first four bytes of the .realm
file, which should be T-DB
.
Hi. Im using new Realm() rather than Realm.open(), but I can use Realm.open if that is preferred. Its never been an issue before.
The realm path is the mobile apps Document directory, which translates to a safe persistent space on either ios or android. (i.e. not cleaned up by the OS) Always worked , has not been changed.
writeCopyTo not used anywhere
NEW INFO: in iOS, still crashing at startup, Im seeing this. Previously I was not getting any helpful info in iOS about the nature of the exception. Perhaps my previous attempt to work around this issue is providing more info? Anyway, it is still crashing at schemaVersion, but the reason is slightly different in iOS?
Crash, Unhandled JS Exception: Error: No such table exists Exception backtrace: 0 GeoNext 0x0000000102617f8c _ZN8facebook5react11JSIExecutor21defaultTim..., stack: schemaVersion@(null):(null) openDB@890:2067 openDB@1017:606 value@426:3176 f@426:1639 lr@95:31853 bl@95:51882 ti@95:78509 ei@95:78437 Za@95:78202 qa@95:75364 qa@(null):(null)
Facing a similar kind of issue with the latest Realm when encryption is used.
Users are able to use the app normally, with some occasional crashes. After a few crashes, the database will become corrupted and thus cannot be opened anymore.
The occasional crashing seems to be related to this: https://github.com/realm/realm-swift/issues/7659
and the corruption for this: https://github.com/realm/realm-core/issues/5174
I'll write a proper issue once I have time to test this properly and find the proper logs.
@Frans-L Thanks for the links. We will follow up with the other teams to investigate any connections.
@stevenmathers @Frans-L If either of you are able to supply reproduction code, that would help us immensely in tracking down the issue.
@Frans-L @stevenmathers Do you know whether this issue can be triggered when the app is shut down manually (e.g., exiting the app from the UI), or if you're only seeing it when the OS suspends or kills the app?
@fronck
We found this bug while testing the latest Realm-JS version with our ~15 internal test users. They used our app with latest realm version for 3 days. During those 3 days:
N5realm4util16DecryptionFailedE
We haven't yet managed to make a producible demo. We tried to revert the user data back to the point before corruption, and redo the same actions, but the crash/corruption didn't happen. So, it feels like it's not a fully deterministic crash.
This could pure coincide, but in our case, the crashes have happened only during 2 different actions. In both actions, we are writing into Realm and opening the iOS native modal at the same time. During the one action, we are writing new ~30 small objects into Realm, and opening React Native default modal component. During the other action, we are opening a react-navigation (v6) modal and updating 1 property from 1 Realm object. For my understanding, the RN's default modal and the library's modal are using the same iOS native modal component. However, I want to emphasize that this could be a pure coincide.
Here's stack trace of a crash that happened before the corruption:
Here's the stack trace that happen after the database has been corrupted:
I will write mode detailed issue with all info once I have time :)
Sorry for late reply, I am on the road at the moment.
1) I have changed to unencrypted DB to protect the users in the short term, and the crashes have 100% disappeared. 2) crashes were spread equally across iOS and Android 3) weirdly, once a user has been affected, it seems to persist even if the app is reinstalled - I cant account for this, Im just reporting it.
3. weirdly, once a user has been affected, it seems to persist even if the app is reinstalled - I cant account for this, Im just reporting it.
Does the reinstallation include putting in a fresh copy of the database?
Now that I think about it, I should check with support as to whether they were asking people to delete the app before reinstalling, or not. If not, it would make more sense as it would not be reinstalling the DB.
WRT manually closing the app or OS closing it, I dont know. I have never managed to duplicate the issue myself by manually closing it, or opening apps to try to force the OS to shutdown the app due to resources. None of the reports I got could nail it down either.
What do you think might be a reason for this bug to suddenly increase in frequency with our last release - the specific release we made was so minor and did not involve the DB in any way (minor UI tweaks), plus the version of realm we (still) use is ^10.8.0 .. pretty old, even taking any minor version updates into account.
@stefoid ^10.8.0
means that NPM / YARN may install minor updates, e.g. 10.12.0 version.
Would you like to share the version number that you have in package.lock
or yarn.lock
.
I would guess that Realm-Core version 11.7.0 or 11.8.0 has introduced this bug. It seems like the same kind of crashing happens also in the Swift version after the Realm-Core version was increased to 11.8.0 from 11.6.1
So, I would guess that corruption may happen if the Realm-JS version is higher than 10.10.1. (Realm-JS 10.10.1 uses the core version 11.6.1.)
I tried to reproduce this in a react native repo. The script runApp.sh
will continually run and reopen the app at random intervals. The app itself will start making writes to realm as soon as it is opened. Unfortunately, this did not reproduce the issue. It is also using an encrypted Realm.
@finnschiermer has made some progress on a possibly related issue.
@stefoid
^10.8.0
means that NPM / YARN may install minor updates, e.g. 10.12.0 version.Would you like to share the version number that you have in
package.lock
oryarn.lock
.I would guess that Realm-Core version 11.7.0 or 11.8.0 has introduced this bug. It seems like the same kind of crashing happens also in the Swift version after the Realm-Core version was increased to 11.8.0 from 11.6.1
So, I would guess that corruption may happen if the Realm-JS version is higher than 10.10.1. (Realm-JS 10.10.1 uses the core version 11.6.1.)
problematic release : (20th feb)
realm@10.13.0
previous no issues release: (1st feb)
realm@10.11.0
not the one you were expecting, but at least it makes sense that something changed
So, it sounds like the issue has appeared with Realm-Core v11.8.0. (Realm-JS v10.11.0 uses Realm-Core v11.7.0. Realm-JS v.10.12.0 uses Realm-Core v11.8.0. I have witnessed the corruption with the Realm-JS v10.12.0 version.)
Throwing wild guesses: By looking at the stack trace, the Realm notification listener thread crashes. So, probably the Realm Core v11.8.0 changed something related to notification and introduced the bug?
At least, these PRs did modify the logic a bit and were merged into v11.8.0 according to the changelog:
➤ Finn Andersen commented:
Fixed by realm-core 11.14
Just saw the same crash with unencrypted realms (https://github.com/realm/realm-js/issues/4533) using 10.20.0-beta.4
.
➤ Finn Andersen commented:
Right - a corrupt file may still trigger this crash. The fix we did in core 11.14 was for one specific cause of corruption related to use of encryption (the initial report for this issue indicated encryption was in use).
How frequently does the bug occur?
Sometimes
Description
Crash, Error: Unable to open a realm at path '/data/user/0/xxx/files/geo.realm': Realm file initial open failed: Invalid mnemonic.
In our React Native mobile app, this error has started to appear for 10-15% of our users since our last release, yet we changed nothing to do with Realm in that release. Those users who get it, seem to get it repeatedly (locked out). The pattern is that a new install works fine, then when the app is launched subsequently, they get crashes on startup over and over, when Realm tries to read the file.
As its a small proportion of users, I have been unable to duplicate the error locally. So I released a new version that caught any exceptions from reading the realm file at startup and responded by deleting the file and creating the DB anew - downside is losing all the cached information, upside is of course they can still use the app. HOWEVER, I am finding that this hasnt fixed the problem.
Our Realm version 10.8.0 and has been for a long time.
Our encrypt key is static hardcoded.
Any insights appreciated. Is this familiar to anyone, or any suggestions at all really.
cheers
Stacktrace & log output
Can you reproduce the bug?
Not yet
Reproduction Steps
No response
Version
10.8.0
What SDK flavour are you using?
Local Database only
Are you using encryption?
Yes, using encryption
Platform OS and version(s)
ios and android all kinds
Build environment
Which debugger for React Native: ..
Cocoapods version
No response