-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crash - Assertion failed: m_lock_info && m_lock_info->m_file.get_path() == m_filename #8507
Comments
➤ PM Bot commented: Jira ticket: RCOCOA-2301 |
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. |
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. |
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. |
👍 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. |
How frequently does the bug occur?
Sometimes
Description
We are seeing this assertion failure:
Assertion failed: m_lock_info && m_lock_info->m_file.get_path() == m_filename
which asks us to:
please_report_this_issue_in_github_realm_realm_core_v_13_26_0
.The crash is happening on multiple code paths that all lead to opening a Realm and adding records via:
Based on the assertion that is being triggered we are assuming it is related to opening the realm file on disk. The crash seems to only be happening when the app is in the background. We have not had any success in reproducing the crash. All Realm files are in a subdirectory of the app's documents directory that uses
URLFileProtection.completeUntilFirstUserAuthentication
. This directory can contain multiple Realm files that the app may switch between during a session.We would appreciate any information on what scenarios might trigger this assertion. Hopefully more information can help us narrow down the cause.
Stacktrace & log output
Can you reproduce the bug?
No
Reproduction Steps
No response
Version
10.46.0
What Atlas Services are you using?
Local Database only
Are you using encryption?
No
Platform OS and version(s)
iOS 17.3.1 and 17.1.2
Build environment
Xcode version: 15.1
Dependency manager and version: SPM
The text was updated successfully, but these errors were encountered: