Closed cfeckardt closed 7 years ago
Thanks for getting in touch, and sorry you're experiencing this issue. I will get someone from the core database team to try to shed some insight into what is going on here.
Just to be clear, the stack trace enclosed represents the initial crash, and every subsequent attempt to open the Realm afterwards fails with Incompatible histories. Expected a Realm with no or in-realm history.
? It looks like the core library hit an assert and crashed, indicating a bug or some sort of inconsistent state.
Is there any way to ask the user to grab the database and send it over to you?
The stack for the crash seem consistent with a corrupt realm file. Later attempts to open the corrupt file may then trigger the assert re incompatible histories. Corruption seem to be the root cause. Are you using encryption?
@finnschiermer Yes we are using encryption.
@austinzheng Unfortunately, it is not possible to retrieve the realm file from the user.
Yes, this is the initial crash, every subsequent attempt to open the file results in 'Incompatible histories'.
@finnschiermer what would you suggest as next steps here?
I'm sorry, but I don't think we can get any further on this without the realm file.
Closing this since we have no actionable information.
Bugs We have an issue that has occurred in production. It occurred after the user experienced a crash (SIGSEGV unrelated to Realm (but possibly in the middle of a database write)). When attempting to open the users' database now we are seeing this message in the logs:
Incompatible histories. Expected a Realm with no or in-realm history.
The user was running Realm 2.5.1. Because we do not have the actual device, we are not able to provide the database, but I have attached the crash report, that seems to have caused the corruption (relevant info starts at 'Thread 7 name'):