Crash - Assertion failed: m_lock_info && m_lock_info->m_file.get_path() == m_filename

[caolsen]

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:

let realm = try Realm(configuration: configuration)
            
try realm.write {
    realm.add(records, update: .modified)
}

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

OS Version: iOS 17.3.1 (21D61)
Report Version: 104

Exception Type: EXC_CRASH (SIGABRT)
Crashed Thread: 6

Application Specific Information:
Assertion failed: m_lock_info && m_lock_info->m_file.get_path() == m_filename

Thread 6 Crashed:
0   libsystem_kernel.dylib          0x3a937dfbc         __pthread_kill
1   libsystem_pthread.dylib         0x3ee67d67c         pthread_kill
2   libsystem_c.dylib               0x32a593b8c         abort
3   ChildCareAttendance             0x201060fa4         please_report_this_issue_in_github_realm_realm_core_v_13_26_0
4   ChildCareAttendance             0x2010611e4         realm::util::terminate_internal
5   ChildCareAttendance             0x2010610c4         realm::util::terminate_with_info
6   ChildCareAttendance             0x201060fb8         realm::util::terminate
7   ChildCareAttendance             0x200e127ec         realm::util::InterprocessMutex::set_shared_part
8   ChildCareAttendance             0x200e10bac         realm::DB::open
9   ChildCareAttendance             0x200e17928         realm::DB::create
10  ChildCareAttendance             0x200ea8e08         realm::_impl::RealmCoordinator::open_db
11  ChildCareAttendance             0x200ea9a68         realm::_impl::RealmCoordinator::do_get_realm
12  ChildCareAttendance             0x200ea9984         realm::_impl::RealmCoordinator::get_realm
13  ChildCareAttendance             0x200eea67c         realm::Realm::get_shared_realm
14  ChildCareAttendance             0x200dae3f4         +[RLMRealm realmWithConfiguration:confinedTo:error:]
15  ChildCareAttendance             0x200dadf90         +[RLMRealm realmWithConfiguration:queue:error:]
16  ChildCareAttendance             0x2010e9904         RLMRealm.__allocating_init
17  ChildCareAttendance             0x2010ea618         Realm.init
18  ChildCareAttendance             0x200673ef0         ChildCareCentralRepository.updateRecords<T>
19  ChildCareAttendance             0x200711b10         AttendancePushProcessor.process
20  ChildCareAttendance             0x200711dbc         AttendancePushProcessor
21  libswift_Concurrency.dylib      0x330a29ac0         swift::runJobInEstablishedExecutorContext

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

[sync-by-unito]

➤ PM Bot commented:

Jira ticket: RCOCOA-2301

[tgoyne]

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.

[caolsen]

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.

[tgoyne]

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.

[caolsen]

👍

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.