io.realm.exceptions.RealmFileException: Realm file is currently open in another process which cannot share access with this process. All processes sharing a single file must be the same architecture. (Incompatible lock file. Shared info version doesn't match, 771 10.) (/data/data/com.anghami/files/default.realm) in /home/cc/repo/realm/release/realm/realm-library/src/main/cpp/io_realm_internal_SharedRealm.cpp line 252 Kind: INCOMPATIBLE_LOCK_FILE.
at io.realm.internal.SharedRealm.nativeGetSharedRealm(SharedRealm.java)
at io.realm.internal.SharedRealm.<init>(SharedRealm.java:186)
at io.realm.internal.SharedRealm.getInstance(SharedRealm.java:239)
at io.realm.BaseRealm.<init>(BaseRealm.java:91)
at io.realm.BaseRealm.<init>(BaseRealm.java:81)
at io.realm.Realm.<init>(Realm.java:149)
at io.realm.Realm.createAndValidateFromCache(Realm.java:392)
at io.realm.Realm.createInstance(Realm.java:371)
at io.realm.RealmCache.doCreateRealmOrGetFromCache(RealmCache.java:346)
at io.realm.RealmCache.createRealmOrGetFromCache(RealmCache.java:284)
at io.realm.Realm.getDefaultInstance(Realm.java:281)
This comes from our crash-reporting tool, so I don't have information other than the stack trace. However, this seems to be a persistent issue for the one user that's having it(7 crashes reported from that one device in the span of a few hours).
We only have a single process(our android app) accessing that realm, so why are we getting this error? And what can we do to recover from it?
Realm version(s): 3.5.0
Realm sync feature enabled:no
Android Studio version: Android Studio 3 beta 2
Which Android version and device:
Android: 7.0
Android Build: NRD90M.G955FXXU1AQH3
Manufacturer: samsung
Model: SM-G955
This has been reported before https://github.com/realm/realm-core/issues/2443
It is a very strange issue since it seems that the lock file has been written by someone with a magic number 0x03 0x03.
If i remembered correctly, you have only released the apk with realm-java 3.5.0, correct?
That is correct, we've never released a different version
How can I recover from this though? Is the only solution deleting the file in question?
it should be recovered when the user restart the app.
but crashed 7 times on one device sounds wrong. can you tell if the user is using a customized ROM?
I might be able to, not from that crash report itself(that comes from the play console and barely any information beyond device model and Android version). But I might be able to see if I can find that same user from our other analytics tools where I could get better info
That would be very helpful!! If it can be constantly reproduced with the specific device, we can try to get one and debug it.
Well, it doesn't look phone-specific, this is where we're at now from the dashboard:

That's a lot of them, but just from 2 devices and those aren't exactly very obscure devices to say the least. Maybe it's some custom rom though... I'll let you know if I can come up with any further info
So I'm getting more of these, we're slowly rolling out to production and now have ~3k daily actives on the new app. So far, I have 24 instances of this crash coming in from 6 different users.
However, this coupled with multiple issues I've filed here(#5302 #5175) and another one I'm noticing now(failure to decrypt a Realm well after the launch of the app at a point where I'm 100% sure that realm has already been queried before by the same process and config hasn't changed). This leads me to thinking there's a deeper issue here causing realm file corruption and I'd really like to know how best to help you determine what it is.
Some of those crashes/corrupted realms come from devices running vanilla android(the segfaulting Realm comes from a google pixel running Oreo that didn't even have developer options enabled, it's in use by a non-engineering colleague). So modded/rooted phones are very probably not the issue here.
It's gotten to the point where we have to do the following procedure:
private static void verifyRealmConfig(@Nonnull RealmConfiguration configuration, boolean restoreOnFail) {
if (!beginUnrecoverableErrorProtection(configuration)) {
handleCorruptRealm(configuration, restoreOnFail);
markUnrecoverableErrorProtectionDone(configuration);
return;
}
try {
RealmHelper.runWithRealm(new RealmRunnable() {
@Override
public void run(Realm realm) {}
}, configuration);
} catch (Throwable t) {
String errorHandling = restoreOnFail ? "restore from backup":"delete";
ZLog.e("Error opening realm(will "+ errorHandling +"): " + configuration, t);
handleCorruptRealm(configuration, restoreOnFail);
}
markUnrecoverableErrorProtectionDone(configuration);
}
Where basically, I'm checkpointing the critical data when the app goes in background so not too much data loss occurs if it gets corrupted. The unrecoverable error protection is for when the error in question isn't something I can catch(like the above-mentioned segfault).
This is not a sustainable long-term solution though...
For the record, I run that procedure on every single realm(we have 3, one cache, one default for most data, and one encrypted account info) at launch, so any crashes on opening a realm we get happen after that thing has already run, so I'm 100% sure the realm isn't corrupt beyond the launch, it gets corrupted and fails to open midway through(this procedure runs as the third thing in the application's onCreate, the first being setting up the logging system and the second being establishing the realm configurations)
We have another independent report of this issue with the same mismatch (771, 10).
Reported in https://github.com/realm/realm-java/issues/5011#issuecomment-332186669 by @trr-amsiq
Fatal Exception: java.lang.RuntimeException: An error occured while executing doInBackground()
at android.os.AsyncTask$3.done(AsyncTask.java:300)
at java.util.concurrent.FutureTask.finishCompletion(FutureTask.java:355)
at java.util.concurrent.FutureTask.setException(FutureTask.java:222)
at java.util.concurrent.FutureTask.run(FutureTask.java:242)
at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:231)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
at java.lang.Thread.run(Thread.java:818)
Caused by io.realm.exceptions.RealmFileException: Realm file is currently open in another process which cannot share access with this process. All processes sharing a single file must be the same architecture. (Incompatible lock file. Shared info version doesn't match, 771 10.) (/data/data/com.app/files/default.realm) in /home/cc/repo/realm/release/realm/realm-library/src/main/cpp/io_realm_internal_SharedRealm.cpp line 91
at io.realm.internal.SharedRealm.nativeGetSharedRealm(SharedRealm.java)
at io.realm.internal.SharedRealm.(SharedRealm.java)
at io.realm.internal.SharedRealm.getInstance(SharedRealm.java:227)
at io.realm.BaseRealm.(BaseRealm.java)
at io.realm.BaseRealm.(BaseRealm.java)
at io.realm.Realm.(Realm.java)
at io.realm.Realm.createInstance(Realm.java:417)
at io.realm.RealmCache.doCreateRealmOrGetFromCache(RealmCache.java:348)
at io.realm.RealmCache.createRealmOrGetFromCache(RealmCache.java:281)
at io.realm.Realm.getDefaultInstance(Realm.java:325)
at com.app.Account.CollectionAccount$1.doInBackground(CollectionAccount.java:112)
at com.app.Account.CollectionAccount$1.doInBackground(CollectionAccount.java:108)
at android.os.AsyncTask$2.call(AsyncTask.java:288)
at java.util.concurrent.FutureTask.run(FutureTask.java:237)
at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:231)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
at java.lang.Thread.run(Thread.java:818)
<?xml version="1.0" encoding="utf-8"?>
<full-backup-content>
<exclude
domain="database"
path="default.realm"/>
<exclude
domain="database"
path="default.realm.lock" />
<exclude
domain="database"
path="default.realm.management" />
</full-backup-content>
You know, I have this wild guess that we would need to specify that the lock file should not get backed up by the auto-backup.
@raja-baz or @beeender is there any way to tell if the problems with the lock file happen after an update/migration? Are users that made a fresh install not affected? (Just an idea for an investigation)
@ironage sorry for the delay. In answer to your question, no, I'm pretty sure that new users get affected normally. Given that these crash reports come from live data(and we weren't able to replicate), this wasn't easy to determine. But I basically tracked users from the crash reports using data from Amplitude(both include the same user identifier). I found quite a few(before stopping) where they got this crash within their first session after installing the app for the first time.
Also from data on Amplitude I can tell things like this:
For the case of one particular user, they updated to the version of our app that uses Realm on Sept 20, they used the app normally for a while. Later on that afternoon, they launched the app and got 8 instances of this crash when launching the app and gave up. 24hrs later, they launched the app and it worked just fine.
So this isn't something triggered by App updates(which includes migrations and whatnot, also the presumed android bug I see in other issues with simultaneous processes), also, it seems that when it happens it happens a lot in quick succession, but somehow doesn't happen anymore later on
@raja-baz thank you for the detailed information!
Are you using the compact on launch feature?
No we are not. We used to use it, but turned it off(because we were asked that exact question on every crash or ANR we created an issue for). The issue still occurs, we're hoping the line in the changelog on the newest release about corruption issues due to multi-process access has something to do with this. We'll be testing that in a future update and seeing if it resolves these issues
@raja-baz thank you for the information. This is an especially tricky bug to track down because we have not been able to reproduce it so far. Please let us know if the latest release solves the problem. If not, you should also check if https://github.com/realm/realm-core/pull/2902 fixes these crashes. It should be released soon most likely in core 4.0.3.
https://github.com/realm/realm-core/pull/2902 could be a potential fix for this issue which has been released with realm-java 4.2.0. Please let us know if this still happens with the fix.
Issue again here with log:
io.realm.exceptions.RealmFileException: Realm file is currently open in another process which cannot share access with this process. All processes sharing a single file must be the same architecture. (Incompatible lock file. Shared info version doesn't match, 771 10.) (/data/data/xx.xxx.xxx.debug/files/default.realm) in /Users/cm/Realm/realm-java/realm/realm-library/src/main/cpp/io_realm_internal_OsSharedRealm.cpp line 101 Kind: INCOMPATIBLE_LOCK_FILE.
at io.realm.internal.OsSharedRealm.nativeGetSharedRealm(Native Method)
at io.realm.internal.OsSharedRealm.(OsSharedRealm.java:171)
at io.realm.internal.OsSharedRealm.getInstance(OsSharedRealm.java:241)
at io.realm.BaseRealm.(BaseRealm.java:136)
at io.realm.BaseRealm.(BaseRealm.java:105)
at io.realm.Realm.(Realm.java:164)
at io.realm.Realm.createInstance(Realm.java:435)
at io.realm.RealmCache.doCreateRealmOrGetFromCache(RealmCache.java:342)
at io.realm.RealmCache.createRealmOrGetFromCache(RealmCache.java:282)
at io.realm.Realm.getDefaultInstance(Realm.java:343)
at xx.xxx.xxx.ApplicationBase$onCreate$client$1.intercept(ApplicationBase.kt:88)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121)
at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:200)
at okhttp3.RealCall$AsyncCall.execute(RealCall.java:147)
at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
at java.lang.Thread.run(Thread.java:776)`
Android: 7.0
Manufacturer: Honor
Model: HONOR 8 (FRD-L09)
Realm version : 5.1.0
In my Application.kt I have something like this :
val client = OkHttpClient.Builder()
.retryOnConnectionFailure(true)
.addInterceptor {
...
//Some code
...
Realm.getDefaultInstance().use {
it.executeTransaction {
...
//Some code
...
}
}
...
//Some code
...
}
.readTimeout(5, TimeUnit.MINUTES)
.writeTimeout(5, TimeUnit.MINUTES)
.build()
If it can help.
@beeender Note that we are still seeing it in Realm 4.3.4 so can this ticket be reopened? The potential fixes that went in for Realm 4.2.0 did not resolve the issue for us. Our only options at this point are to a) live with it, b) fix it ourselves (not very promising as contributors have not been able to find a root cause), or c) not use Realm.
o.realm.exceptions.RealmFileException: Realm file is currently open in another process which cannot share access with this process. All processes sharing a single file must be the same architecture.
(Incompatible lock file. Shared info version doesn't match, 771 10.)
(/data/data/XXXX/files/default.realm) in /Users/Nabil/Dev/realm/master/realm-java/realm/realm-library/src/main/cpp/io_realm_internal_OsSharedRealm.cpp line 101
at io.realm.internal.OsSharedRealm.nativeGetSharedRealm(Native Method) ~[na:0.0]
It's weird because I saw this one comment https://github.com/realm/realm-java/issues/2459#issuecomment-288588618 that says it is possible to verify whether it is possible to do things or not
You need to use java's exposed flock system api to implement you own process lock safety checks. We have seen alarm intents sent by android on some older android to be processed in different processes despite multiProcess feature disabled in manifest. You need to detect this and ignore what operations you are doing if you can't acquire a flock.
I have no idea what it means though 😄
I assume he is referring to the FileLock API: https://docs.oracle.com/javase/7/docs/api/java/nio/channels/FileLock.html
See e.g.:
https://stackoverflow.com/questions/15143195/how-to-use-filelock-on-android
But good find with that comment. I completely missed that. If this is indeed a bug in the Android operating system, there is very little we can do to work around it on the Realm side (besides implementing encryption support across processes).
As a minimum should probably write this up as an FAQ item on the website and show how to use the FileLock API or how to catch the exception from Realm, since the end result is more or less the same.
Actually, this is probably the same problem that causes permission denied on huawei devices.
We have recently ported from another DB to realm and seeing this issue frequently enough during development. However we can't figure out specific steps to reproduce this.
We're on realm 5.3.1.
Caused by: io.realm.exceptions.RealmFileException: Realm file is currently open in another process which cannot share access with this process. All processes sharing a single file must be the same architecture. (Incompatible lock file. Shared info version doesn't match, 771 10.) (/data/data/com.alkymia.pop.preprod/files/default.realm) in /Users/Nabil/Dev/realm/master/realm-java/realm/realm-library/src/main/cpp/io_realm_internal_OsSharedRealm.cpp line 101 Kind: INCOMPATIBLE_LOCK_FILE.
at io.realm.internal.OsSharedRealm.nativeGetSharedRealm(Native Method)
at io.realm.internal.OsSharedRealm.
at io.realm.internal.OsSharedRealm.getInstance(OsSharedRealm.java:241)
at io.realm.BaseRealm.
at io.realm.BaseRealm.
at io.realm.Realm.
➤ Brian Munkholm commented:
Closing as stale - can't be reproduced.
Most helpful comment
We have recently ported from another DB to realm and seeing this issue frequently enough during development. However we can't figure out specific steps to reproduce this.
We're on realm 5.3.1.
Caused by: io.realm.exceptions.RealmFileException: Realm file is currently open in another process which cannot share access with this process. All processes sharing a single file must be the same architecture. (Incompatible lock file. Shared info version doesn't match, 771 10.) (/data/data/com.alkymia.pop.preprod/files/default.realm) in /Users/Nabil/Dev/realm/master/realm-java/realm/realm-library/src/main/cpp/io_realm_internal_OsSharedRealm.cpp line 101 Kind: INCOMPATIBLE_LOCK_FILE.(OsSharedRealm.java:171)(BaseRealm.java:136)(BaseRealm.java:105)(Realm.java:164)
at io.realm.internal.OsSharedRealm.nativeGetSharedRealm(Native Method)
at io.realm.internal.OsSharedRealm.
at io.realm.internal.OsSharedRealm.getInstance(OsSharedRealm.java:241)
at io.realm.BaseRealm.
at io.realm.BaseRealm.
at io.realm.Realm.