Help: Destruction of mutex in use #5578
Comments
|
can you reproduce it locally? can you get a full logcat for us? with |
|
|
Do you use primitive list we introduced in |
|
Yes |
|
it is also happend on android 7 (galaxy s8+) same realm version |
|
05-30 12:35:23.726 2344-2446/com.ajinkyabadve.mywatchlist E/REALM: /mnt/jenkins/workspace/lm_realm-core_release_5.4.2-7MRDQ2N52D4436PA46O7GFYLIKQGV37WCE5DFMFVZ5J6WJYDBC3A@2/src/realm/util/thread.cpp:183: [realm-core-5.4.2] Destruction of mutex in use App crashes looks like the same issue Realm version(s): |
|
Detail logcat in case if needed
|
|
Here is more log:
|
|
So, this issue has persisted and seemingly nothing I've changed has been able to mitigate it, but I recently may have identified a fix. We were only getting this crash very occasionally in our integration tests, but it hasn't happened for several days. Here's what the code now looks like: We have between 30-40 realm classes, so that might be a viable path for reproducing the issue, or at least specifically understanding that this crash might be directly caused by deleting all realm classes with several realms open on multiple threads. |
*
* @throws IllegalStateException if attempting to refresh from within a transaction.
*/
public void refresh() {
checkIfValid();
if (isInTransaction()) {
throw new IllegalStateException("Cannot refresh a Realm instance inside a transaction.");
}
sharedRealm.refresh();
}Considering |
|
Ah, you're correct in pointing this out. Well, clearly it's fixing the issue by causing the underlying transaction to fail (there are more layers to this in our system) That being said, this still shows that the issue is internal to realm and triggered at least in our case by deleting most of the realm classes, which is obviously something that we should be able to do. |
|
I definitely agree! Unfortunately I'm not actually a Realm member and I don't have any workarounds for this particular error. 😞 |
|
@bentemple Interesting. It might point to the underlying error though. As @Zhuinden points out, calling This could e.g. be because you had a Do you know if this is a possibility? In general, we have not done much to guard against this scenario as it is very difficult to detect across threads and is a pretty rare scenario (I only ever seen one other person reporting issues around it). If you suspect this is happening. The safest is trying to completely close the Realm (which will remove the resources) before opening the Realm and deleting the schemas. Alternatively, you can flag the schemas that need to be deleted and do it as the first thing the next time the app starts. |
|
By schema, what do we mean by schema? |
I would need to validate, but I think that trying to delete a schema from a typed Realm would throw an exception since it needs a migration, but doing it from a DynamicRealm is allowed and has the side effects mentioned above. |
|
@cmelchior I feel strongly that it does point to the underlying issue. That being said, I'm not deleting schemas here, I'm deleting all the objects in a schema, this is the I think that as you pointed out this is likely directly related to RealmList, RealmResults referencing the deleted objects. I went ahead and moved the refresh outside of the delete transaction, and I just recently saw my first crash as a result of fixing the transaction from failing. Also, this isn't a dynamic realm It actually seems like this crash could be triggered by deleting even a single object from a schema, albeit probably not likely, but if I can't clear the table, can I even safely delete a single object? |
|
@bentemple Yeah, I guess I misunderstood what your delete method does and my explanation definitely doesn't hold in your case. Deleting objects should work perfectly fine. We do that all over the place in our unit tests and have never seen any issues due to it. That doesn't mean there couldn't be a bug there, I would just be very surprised. Are you in any position to share the crashing code? You can do it privately to help@realm.io ? |
😲 |
I think I can share the crashing code, but our system has some layers on-top of realm so I'm not sure how much that will help. I'm guessing a more detailed high-level overview of the processes happening right before the crash might be more useful, but idk. I'll email directly and see if I can provide what you need. |
|
A high-level description of the system would also work. From the stack trace it is our finalizer thread that throws the exception meaning it happens when some kind of object from Realm with a native resource is GC'ed. |
|
Looking at the code in question you sent I do not see anything alarming. |
|
I have been experiencing a similar issue, also getting the error We are using Realm 5.10.0. Our app communicates with external sensors and we save their data in Realm. We read the data from Realm to display it on screen and calculate various statistics from it. Occasionally the crash occurs generating a tombstone file, and we can’t figure out what’s causing it as we can’t find a pattern. Even when we simulate the sensors, allowing us to always save identical data, it often crashes, but never at the same data points. It appears to be very random. Our target SDK is Android 9 and so far the crash is occuring on Samsung Galaxy Tab Active 2 running Android 8.1 & Android 9. We are not clearing or deleting any data when the crash happens, in contrary to what comments above have been suggesting. I don't know if that means my issue is different altogether or if the assumption that it's caused by clearing data is wrong. It is possible that data in a RealmResults object no longer fit the query applied so data is removed from the RealmResults though. Here's the logcat: |
|
We're seeing the same thing: At least for me, happening on a Pixel emulator running API 28. This is very reproducible, but we have a lot of Realm code so it's unclear what specifically is causing it. @cmelchior is there any steps for obtaining more information that can help the team investigate? |
cmelchior
added
Reproduction-Required
and removed
Blocked
|
@ParthPadg What version of Realm are you running, then I can try to de-obfuscate your stacktrace. Hopefully that can reveal some more. The error comes from the GC, which triggers the cleanup of some Realm resource that may already be destroyed, but it is unclear exactly what and how. In another thread, you mentioned this happened if the app was left on for a number of minutes. Is the screen on during that time or does the phone go to sleep and this crash happens when you wake up? |
|
Hey @cmelchior, . I'm running this on 5.15.1. If there's specific metrics you want around invocations or anything, let me know here or on the other thread, I'll do my best to get you what you need. Thanks so much!! |
|
Ok, so the crash above, happens by normal use of the app? |
|
Yeah, the only potentially weird thing I'm doing is attempting to remove "orphaned" DB entries from a table, but to the DB it just looks like a transaction with a few insertions and a bunch of deletions. |
|
The unrolled stack trace is this: It looks like the destruction of a |
|
Unfortunately yeah, our model files are littered with RealmLists :( |
|
Do these lists all contain references to other RealmObjects or do they also contain primitives like |
|
It is this one: realm/realm-core#2944 We have so far not been able to fix it in the context of current Core. It will be fixed by Core-6. |
|
@cmelchior both, we have "primitive" RealmLists as well as lists that reference other RealmObjects |
|
This is fixed by realm/realm-core#3460 |
|
@cmelchior if there isn't a realm-java build that has the RealmCore 6.x included, why has this issue been closed? |
|
Technically it is in Realm-Core 5.23.7, but the question is valid. |
|
@ParthPadg We close issues when fixes are merged, not when they are released. Github issue handling works best that way as you write "This PR fixes #xyz" and github will auto close when the PR is merged. |
Where to find log and how to upload log?
Version of Realm and tooling
Realm version(s):
4.2.0
Android Studio version:
4.4.4
Which Android version and device:
Samsung Galaxy S3
The text was updated successfully, but these errors were encountered: