Crash on Realm.write

[NZQN23]

How frequently does the bug occur?

Sometimes

Description

My app crashes in production during write operations

Stacktrace & log output

0   libsystem_kernel.dylib        	0x00000001c92ef200 0x1c92e8000 + 29184
1   libsystem_pthread.dylib       	0x00000001d97511ac 0x1d974a000 + 29100
2   libsystem_c.dylib             	0x0000000193e11c8c 0x193df1000 + 134284
3   Realm                         	0x0000000105daf8e4 please_report_this_issue_in_github_realm_realm_core_v_12_9_0 + 12
4   Realm                         	0x0000000105dafbcc realm::util::terminate_internal(std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> >&) + 260
5   Realm                         	0x0000000105dafa2c realm::util::terminate(char const*, char const*, long, std::initializer_list<realm::util::Printable>&&) + 328
6   Realm                         	0x0000000105b3e27c 0x105ae0000 + 385660 (terminate.hpp:45)
7   Realm                         	0x0000000105c40788 realm::ArrayBigBlobs::insert(unsigned long, realm::BinaryData, bool) + 336
8   Realm                         	0x0000000105c59168 void realm::Cluster::do_insert_row<realm::ArrayString>(unsigned long, realm::ColKey, realm::Mixed, bool) + 188
9   Realm                         	0x0000000105c58834 realm::util::FunctionRef<realm::IteratorControl (realm::ColKey)>::FunctionRef<realm::Cluster::insert_row(unsigned long, realm::ObjKey, realm::FieldValues const&)::$_1&>(realm::Cluster::insert_row(u... + 456
10  Realm                         	0x0000000105d7bfcc realm::TableClusterTree::for_each_and_every_column(realm::util::FunctionRef<realm::IteratorControl (realm::ColKey)>) const + 84
11  Realm                         	0x0000000105c53f80 realm::Cluster::insert_row(unsigned long, realm::ObjKey, realm::FieldValues const&) + 208
12  Realm                         	0x0000000105c55f3c realm::Cluster::insert(realm::ObjKey, realm::FieldValues const&, realm::ClusterNode::State&) + 240
13  Realm                         	0x0000000105c65f5c realm::ClusterNodeInner::insert(realm::ObjKey, realm::FieldValues const&, realm::ClusterNode::State&)::$_1::operator()(realm::ClusterNode*, realm::ClusterNodeInner::ChildInfo&) const + 72
14  Realm                         	0x0000000105c61278 realm::ClusterNodeInner::insert(realm::ObjKey, realm::FieldValues const&, realm::ClusterNode::State&) + 232
15  Realm                         	0x0000000105c64a28 realm::ClusterTree::insert_fast(realm::ObjKey, realm::FieldValues const&, realm::ClusterNode::State&) + 48
16  Realm                         	0x0000000105c64c90 realm::ClusterTree::insert(realm::ObjKey, realm::FieldValues const&) + 48
17  Realm                         	0x0000000105d7bb18 realm::TableClusterTree::insert(realm::ObjKey, realm::FieldValues const&) + 52
18  Realm                         	0x0000000105d6db44 realm::Table::create_object_with_primary_key(realm::Mixed const&, realm::FieldValues&&, realm::Table::UpdateMode, bool*) + 860
19  Realm                         	0x0000000105af7cf4 realm::Table::create_object_with_primary_key(realm::Mixed const&, bool*) + 80 (table.hpp:260)
20  Realm                         	0x0000000105aed67c 0x105ae0000 + 54908 (object_accessor.hpp:306)
21  Realm                         	0x0000000105aed090 RLMAccessorContext::createObject(objc_object*, realm::CreatePolicy, bool, realm::ObjKey) + 744 (RLMAccessor.mm:1102)
22  Realm                         	0x0000000105b3ce90 0x105ae0000 + 380560 (RLMObjectStore.mm:119)
23  RealmSwift                    	0x000000010549aea0 Realm.add(_:update:) + 16 (Realm.swift:540)
24  RealmSwift                    	0x000000010549aea0 Realm.add<A>(_:update:) + 316 (Realm.swift:564)
25  Geory                         	0x0000000104a89540 0x1049f8000 + 595264
26  RealmSwift                    	0x000000010549a2c4 Realm.write<A>(withoutNotifying:_:) + 228 (Realm.swift:258)
27  Geory                         	0x0000000104a86be8 0x1049f8000 + 584680 (DatabaseManagement.swift:93)
28  Geory                         	0x0000000104a894ac 0x1049f8000 + 595116
29  Geory                         	0x0000000104a219a0 thunk for @escaping @callee_guaranteed () -> () + 28 (<compiler-generated>:0)
30  libdispatch.dylib             	0x0000000193dac4b4 0x193daa000 + 9396
31  libdispatch.dylib             	0x0000000193dadfdc 0x193daa000 + 16348
32  libdispatch.dylib             	0x0000000193dbfb8c 0x193daa000 + 88972
33  libdispatch.dylib             	0x0000000193dc0284 0x193daa000 + 90756
34  libsystem_pthread.dylib       	0x00000001d974adbc 0x1d974a000 + 3516
35  libsystem_pthread.dylib       	0x00000001d974ab98 0x1d974a000 + 2968

Can you reproduce the bug?

Not yet

Reproduction Steps

No response

Version

10.31.0

What SDK flavour are you using?

Local Database only

Are you using encryption?

No, not using encryption

Platform OS and version(s)

iOS 16.1

Build environment

Xcode version: 14.0.1
Dependency manager and version: Cocoapods 1.11.3

[NZQN23]

Could you please take a look into this as this is causing massive problems at the moment for my app? Many thanks.

[ejm01]

@NZQN23
Are you able to reproduce on your own devices? Can you share what the write transaction is? What percent of users is this happening to?
What are the properties on the type of object being added? Is it either a list or mixed?

[ejm01]

I'm going to move this to realm-core because the stack trace shows this just going from realm.add() to RLMAccessorContext::createObject.
Looking at ArrayBigBlobs::insert, is it possible that the asserts on 107 and 108 are failing? Or would that mean the error message would be different?

[NZQN23]

@NZQN23
Are you able to reproduce on your own devices? Can you share what the write transaction is? What percent of users is this happening to?
What are the properties on the type of object being added? Is it either a list or mixed?

I'm not able to reproduce it on any of my devices unfortunately but I'm receiving numerous crash reports.

About the write transaction:

func writeObjectsToDatabase(qos: DispatchQoS.QoSClass, objectsToWrite: [Object], completion: @escaping () -> () = {}) {
    
    DispatchQueue.global(qos: qos).async {
        
        autoreleasepool {
            
            do {
                
                let realm = try Realm(configuration: Realm.Configuration(schemaVersion: realmSchemaVersion))
                
                if realm.isInWriteTransaction {
                    
                    print("Realm is in write transaction, returning")
                    
                    completion()
                    
                    return
                    
                }
                
                try realm.write() {
                    
                    realm.add(objectsToWrite, update: .modified)
                    
                }
                
                let locations = realm.objects(LocationObject.self).sorted(byKeyPath: "ts_timestamp", ascending: true)
                
                localDatabase.lastLocation = locations.last?.freeze()
                localDatabase.firstLocation = locations.first?.freeze()
                
                localDatabase.visits = Array(realm.objects(VisitObject.self).sorted(byKeyPath: "ts_arrival", ascending: false).freeze())
                
                localDatabase.labels = Array(realm.objects(LabelObject.self).sorted(byKeyPath: "info_text", ascending: true).freeze())
                
                localDatabase.workouts = Array(realm.objects(WorkoutObject.self).sorted(byKeyPath: "ts_start", ascending: false).freeze())
                
                completion()
                
            }
            
            catch {
                
                print(error.localizedDescription)
                
                completion()
                
            }
            
        }
        
    }
    
}

Is this enough or do you need the object structure as well?

[jedelbo]

@NZQN23 If you have several crash reports, could I ask you to check if all stacktraces show a crash on realm::ArrayBigBlobs::insert?

[NZQN23]

@jedelbo yes, all of them have this line.

[jedelbo]

... and the rest of the call stack does also look the same?

[NZQN23]

Mostly. Would you prefer if I send all logs per email?

[jedelbo]

Yes, that would be great. You can send them to me: jorgen.edelbo@mongodb.com.

[sync-by-unito]

➤ Jørgen Edelbo commented:

Internal note: The crash reports show 2 different symptoms:

• Error when inserting into ArrayBigBlobs in a 2nd level cluster node.
• Error when trying to initialize a root cluster when opening the realm file.

[NZQN23]

Hello @jedelbo, do you have any updates on these issues?

[jedelbo]

Unfortunately not. But I can assure you that several people are working on it.

[NZQN23]

If it's helpful at all: these errors first showed mid-september. At the same time I got a lot of warnings in Xcode regarding the app referencing non-public selectors for Realm: authenticationDidCompleteWithError.

Also I checked for changes in my Object models, the only difference from the version without these errors to the one with was changing some Double attributes to optional Double.

Both versions were using Realm 10.29.0.

[jedelbo]

@NZQN23 You say that the problems started mid-september. Can you relate that to a change in the Realm version used?

[NZQN23]

No, it was the same (10.29.0). It explicitly checked this. Maybe something with iOS 16?

[jedelbo]

Yes, we are beginning to suspect that there has been a change in the platform.

[NZQN23]

➤ Jørgen Edelbo commented:

Internal note: The crash reports show 2 different symptoms:

• Error when inserting into ArrayBigBlobs in a 2nd level cluster node.
• Error when trying to initialize a root cluster when opening the realm file.

Hi @jedelbo, I have just checked the latest crash reports for last ten days. So far I have 84 crash reports of which 36 reference to realm/realm-swift#7999, 13 seem to be the issue with ArrayBigBlobs, 24 seem to be the initialize issue and 7 are new within the last days for a slightly different stacktrace, I have opened #5982 for that. Maybe these numbers help.

[aehlke]

is this a widespread issue?

[jedelbo]

This is probably not due to a change in the platform. We are close to have found the root cause.

[NZQN23]

There might be something interesting here: in my latest release I have integrated 10.32.0 and have removed a particular string attribute from one object. Since then, I never had any of this issue or of the issue from realm/realm-swift#7999. And yes, it was the workoutUUID attribute.