realm-kotlin icon indicating copy to clipboard operation
realm-kotlin copied to clipboard

Invalid streaming format cookie

Open charleshberlin opened this issue 2 years ago • 14 comments

How frequently does the bug occur?

Sometimes

Description

We have two users who are currently experiencing a crash [RLM_ERR_INVALID_DATABASE]: Failed to open Realm file at path '/data/user/0/*******/files/********.realm': file is in streaming format but has an invalid footer cookie (0). The file is probably truncated.

It appears to happen when the app is started (potentially woken up via a worker) and we attempt to open a realm, however we do not understand what could be causing this issue because neither user had any other errors around the time this occurred (that we can see). It seems like it may have started overnight when the device was sleeping because both instances started in the early am hours and then the user reported it repeatedly crashing after attempting to use it.

Currently we have no way of resolving this issue, so our only course of action for now is to have the user re-install the application. For now we are planning on simply catching this error and then deleting the realm and re-opening a new one, but this is not an ideal solution either.

Stacktrace & log output

Fatal Exception: java.lang.IllegalStateException: [RLM_ERR_INVALID_DATABASE]: Failed to open Realm file at path '/data/user/0/*******/files/********.realm': file is in streaming format but has an invalid footer cookie (0). The file is probably truncated.
       at io.realm.kotlin.internal.interop.CoreErrorConverter.asThrowable(CoreErrorConverter.kt:44)
       at io.realm.kotlin.internal.interop.realmcJNI.open_realm_with_scheduler(realmcJNI.java)
       at io.realm.kotlin.internal.interop.realmc.open_realm_with_scheduler(realmc.java)
       at io.realm.kotlin.internal.interop.RealmInterop.realm_open(RealmInterop.kt:193)
       at io.realm.kotlin.internal.interop.RealmInterop.realm_open$default(RealmInterop.kt:181)
       at io.realm.kotlin.internal.ConfigurationImpl.openRealm$suspendImpl(ConfigurationImpl.kt:107)
       at io.realm.kotlin.internal.ConfigurationImpl.openRealm(ConfigurationImpl.kt)
       at io.realm.kotlin.internal.RealmImpl$1.invokeSuspend(RealmImpl.kt:107)
       at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
       at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
       at kotlinx.coroutines.EventLoopImplBase.processNextEvent(EventLoop.common.kt:284)
       at kotlinx.coroutines.BlockingCoroutine.joinBlocking(BlockingCoroutine.java:85)
       at kotlinx.coroutines.BuildersKt__BuildersKt.runBlocking(BuildersKt__Builders.kt:59)
       at kotlinx.coroutines.BuildersKt.runBlocking(Builders.kt:1)
       at io.realm.kotlin.internal.platform.CoroutineUtilsSharedJvmKt.runBlocking(CoroutineUtilsSharedJvm.kt:22)
       at io.realm.kotlin.internal.platform.CoroutineUtilsSharedJvmKt.runBlocking$default(CoroutineUtilsSharedJvm.kt:21)
       at io.realm.kotlin.internal.RealmImpl.<init>(RealmImpl.kt:106)
       at io.realm.kotlin.internal.RealmImpl.<init>(RealmImpl.kt)
       at io.realm.kotlin.internal.RealmImpl$Companion.create$io_realm_kotlin_library(RealmImpl.kt:263)
       at io.realm.kotlin.Realm$Companion.open(Realm.kt:82)
       ******************************************************************************************
       at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
       at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
       at android.os.Handler.handleCallback(Handler.java:942)
       at android.os.Handler.dispatchMessage(Handler.java:99)
       at android.os.Looper.loopOnce(Looper.java:201)
       at android.os.Looper.loop(Looper.java:288)
       at android.os.HandlerThread.run(HandlerThread.java:67)

Can you reproduce the bug?

No

Reproduction Steps

No response

Version

1.8.0

What Atlas App Services are you using?

Local Database only

Are you using encryption?

No

Platform OS and version(s)

Android 13

Build environment

Android Studio version: Android Studio Flamingo | 2022.2.1 Patch 2 Android Build Tools version: 30.0.3 Gradle version: 7.5

charleshberlin avatar Jun 29 '23 16:06 charleshberlin

Yes, that error does point to the Realm file being corrupted somehow.

Can you provide some more information about how you are using Realm?

  • Are you using encryption?
  • Are you using compaction? Either RealmConfiguration.compactOnLaunch or manual?
  • Are you using RealmConfiguration.initialRealmFile?
  • Are you manually copying or moving the Realm file around?
  • Where are you using Realm. Judging from the stack trace it looks like an Android app?
  • Do you have Android Backup enabled? https://developer.android.com/guide/topics/data/backup

cmelchior avatar Jun 30 '23 06:06 cmelchior

I am also seeing this. The original realm is fine, but I am writing copies of the realm files and these gets corrupted. I have only been getting a few bug reports so it doesn't seem to be frequent. I do use encryption and compactOnLaunch. No initial realm file. It is an Android app. I do allow backups but is using backup_rules.txt to exclude .realm files. Are there more files I should exclude?

sipersso avatar Jun 30 '23 11:06 sipersso

@sipersso How are you writing these copies? Using the Realm.writeCopyTo API or some other API?

A Realm actually contains more than the database file itself, there is also a <realmFileName>.note (which we use to track communication between processes) and a <realmFileName>.management directory that contains a few files.

If these files are restored and combined with a new Realm file, this could definitely lead to errors like this one.

cmelchior avatar Jun 30 '23 11:06 cmelchior

Yes, I use write copy to. The strange thing is that these are in "cache" directories and only used for uploading data once to a server. I am never actually reading from these files from within the app. So I doubt the backup rules will matter since the realm files are just temporary. The user realm file is untouched and doesn't have the issue.

Now that I think of it, the configuration for these files is not using using encryption or compaction, and the folders are deleted once the file is uploaded to my server.

sipersso avatar Jun 30 '23 11:06 sipersso

Are you using encryption? No Are you using compaction? Either RealmConfiguration.compactOnLaunch or manual? Yes we are using compactOnLaunch with the default callback Are you using RealmConfiguration.initialRealmFile? No Are you manually copying or moving the Realm file around? No Where are you using Realm. Judging from the stack trace it looks like an Android app? Android app Do you have Android Backup enabled? https://developer.android.com/guide/topics/data/backup No, we explicitly set allowBackup to false

charleshberlin avatar Jun 30 '23 11:06 charleshberlin

Do you have access to any of these corrupted Realm files?

clementetb avatar Jul 04 '23 11:07 clementetb

Sadly no, they were on release builds on customer phones and they were instructed to delete the app and reinstall

charleshberlin avatar Jul 04 '23 12:07 charleshberlin

I have sample files... where should I send them?

sipersso avatar Jul 13 '23 09:07 sipersso

@sipersso send them to [email protected]

clementetb avatar Jul 14 '23 10:07 clementetb

@clementetb Files sent. Not sure if this helps, but an interesting observation is that the files all seem to have even sizes (512kb, 1024kb, 2048kb, etc).

sipersso avatar Jul 14 '23 10:07 sipersso

Thanks, we have received them.

clementetb avatar Jul 14 '23 10:07 clementetb

The core team is investigating the issue. As a workaround to prevent this issue you could disable compactOnLaunch.

clementetb avatar Jul 14 '23 12:07 clementetb

@clementetb Just to clarify a bit on the files I uploaded.

1: I have a default realm that the user typically writes to. This realm does have compactOnLaunch enabled. 2: The user can write a copy using writeCopyTo(tmpConfiguration). The tmpConfiguration does not have compactOnLaunch enabled

It is the copy that gets corrupted. The default realm, which is using compaction is fine as far as I can see in my case.

sipersso avatar Jul 14 '23 19:07 sipersso

Thanks for the clarification, I will forward these details to the core team.

clementetb avatar Jul 14 '23 23:07 clementetb