Crash - Assertion failed: m_lock_info && m_lock_info->m_file.get_path() == m_filename about realm-swift HOT 5 CLOSED

➤ PM Bot commented:

Jira ticket: RCOCOA-2301

from realm-swift.

Are you ever deleting the Realm files? This could happen if you delete the file while it's open and then a new file is created at a different path and it happens to get the same inode number.

There also might be a race condition in InterprocessMutex when a file is reopened while in the process of being closed on another thread. The code appears to have correct locking but it's somewhat complicated and this could definitely happen if the locking is slightly wrong, so I'll review it to see if I can find anything.

from realm-swift.

We do delete Realm files on occasion, but it's quite rare (a few times per year), so I don't think it's the cause of this issue.

The second scenario you mentioned, opening a file that is in the process of being closed is very possible. We have a lot of code paths that open Realm files on different threads (i.e., user interaction, background tasks, and APNs). Most Realm interactions are wrapped in an autoreleasepool block which I imagine causes a lot of Realm file closes.

Looking at our code that handles Realm file management, it's certainly possible that a race condition exists on our end. Moving some of that code into an Actor to force synchronous access might be an option.

from realm-swift.

After looking more into the code producing the assertion failure my conclusion is that we can just delete it entirely as it was a solution to a problem that we have since solved in a much better way.

from realm-swift.

👍

Glad this issue led to the discovery of some unnecessary code, but I wonder if the fact it was being triggered at all means we should take a hard look at our Realm file access code.

from realm-swift.