Crash when creating new objects

[maretod]

How frequently does the bug occur?

Sometimes

Description

Creating a new object should not crash the app. We're experiencing a crash for a small portion of our production users. The message for the exception is:

When inserting key '0' in 'class_<Redacted>'.

Based on my analysis, it looks like this is being raised from realm-core, and is not related to inserting objects with duplicate primary keys.

I've also observed that this is only happening for newcomers to our app, so I've ruled out an issue with migrating to newer schema versions.

Stacktrace & log output

Fatal Exception: RLMException
0  CoreFoundation                 0x129dc0 __exceptionPreprocess
1  libobjc.A.dylib                0x287a8 objc_exception_throw
2  Realm                          0xbf1c RLMAccessorContext::createObject(objc_object*, realm::CreatePolicy, bool, realm::ObjKey) + 1097 (RLMAccessor.mm:1097)
3  Realm                          0x58374 RLMAddObjectToRealm + 139 (RLMObjectStore.mm:139)
4  <Redacted>                    0x3b407c partial apply for thunk for @callee_guaranteed () -> (@error @owned Error) (<compiler-generated>)
5  <Redacted>                    0x3b4884 thunk for @callee_guaranteed () -> (@error @owned Error)partial apply
6  RealmSwift                     0x66474 Realm.write<A>(withoutNotifying:_:) + 255 (Realm.swift:255)
7  <Redacted>                    0x3ae8f4 specialized <Redacted>.update<A>(model:)
8  <Redacted>                    0x218d14 <Redacted>.saveData<A>(model:networkResponse:) + 30 (<Redacted>.swift:30)
9  <Redacted>                       0xa3cc closure #2 in static <Redacted>.dataRequest<A>(modelType:request:completion:) + 89 (<Redacted>.swift:89)
10 <Redacted>                       0xb378 partial apply for closure #1 in closure #3 in static <Redacted>.dataRequest<A>(modelType:request:completion:) (<compiler-generated>)
11 <Redacted>                    0x31a804 specialized <Redacted>.intercept(request:shouldShowErrorBanner:networkResponse:completion:) + 15 (NetworkResponse+Extension.swift:15)
12 <Redacted>                       0xa554 closure #3 in static <Redacted>.dataRequest<A>(modelType:request:completion:) + 103 (<Redacted>.swift:103)
13 <Redacted>                       0x8100 closure #1 in <Redacted>.sendRequest(request:) + 143 (<Redacted>.swift:143)
14 <Redacted>                       0x8290 thunk for @escaping @callee_guaranteed (@guaranteed Data?, @guaranteed NSURLResponse?, @guaranteed Error?) -> () (<compiler-generated>)
15 CFNetwork                      0x1f3dc CFNetServiceBrowserSearchForServices
16 CFNetwork                      0x31768 _CFHTTPMessageSetResponseProxyURL
17 libdispatch.dylib              0x2a84 _dispatch_call_block_and_release
18 libdispatch.dylib              0x481c _dispatch_client_callout
19 libdispatch.dylib              0xc004 _dispatch_lane_serial_drain
20 libdispatch.dylib              0xcc34 _dispatch_lane_invoke
21 libdispatch.dylib              0x174bc _dispatch_workloop_worker_thread
22 libsystem_pthread.dylib        0x37a4 (Missing)
23 libsystem_pthread.dylib        0xa74c (Missing)

Can you reproduce the bug?

Not yet

Reproduction Steps

Unable to reproduce.

Here is all that I am at liberty to share as far as code snippets:

func update<T: Object>(model: T) {
    do {
        let realm = try Realm(configuration: config)
        try realm.write {
            realm.add(model, update: .modified)
        }
    } catch let error {
        ...
    }
}

Version

10.19.0

What SDK flavour are you using?

Local Database only

Are you using encryption?

Yes, using encryption

Platform OS and version(s)

iOS 14, 15

Build environment

Xcode version: Xcode 12 Dependency manager and version: CocoaPods (Unsure of the version in our CI stack)

[leemaguire]

Hi @maretod

Could you attach a few more crash logs so we can investigate further?

[maretod]

@leemaguire Unfortunately, logs relating to this issue aren't abundant. Besides the crashed thread stack trace I'm afraid we don't have much more to share. I am able to share the models which seem to be causing this issue, however. It is our EmbeddedObject which is appearing the exception message: When inserting key '0' in 'class_MyEmbeddedModel'

class MyParentModel: Object, Codable {
    @Persisted(primaryKey: true) var authGuid: String?
    
    @Persisted var physicalResources = List<MyEmbeddedModel>()
    
    enum CodingKeys: CodingKey {
        case physicalResources
    }
    
    convenience required init(from decoder: Decoder) throws {
        self.init()
        let container = try decoder.container(keyedBy: CodingKeys.self)

        let physicalResources = try? container.decode([MyEmbeddedModel].self, forKey: .physicalResources)
        self.physicalResources.append(objectsIn: physicalResources ?? [])
    }
}

class MyEmbeddedModel: EmbeddedObject, Codable {
    @Persisted var macAddress: String?
    @Persisted var physicalResourceType: String?
}

[pavel-ship-it]

@maretod , it looks like you a trying to create a copy of existing MyEmbeddedModel. Can it be the case?

[jsflax]

@maretod I'm unable to reproduce this crash, though it does seem legitimate. I tried using an encrypted Realm and encoding/decoding your data model and calling the same calls you are. Do you have a sample Realm or even just a data set that we could work with?

[PhilippeWeidmann]

Hi, we also have the same problem reported on our Sentry. The error also occurs with EmbeddedObjects but we don't use encrypted realms. We also can't reproduce it, we only see it happening on some users.
Users are on realm version 10.25.1.

[leemaguire]

@maretod @PhilippeWeidmann can you update to 10.28.6 (current latest) that should solve your issue.

[PhilippeWeidmann]

Thanks ! We are gonna update and monitor the crash logs

[PhilippeWeidmann]

Well, sadly the issue is still happening with the latest version. The exception is still: RLMException When inserting key '0' in 'class_EmbeddedObject' I don't know if this is of any help but the error is triggered here: Realm/RLMAccessor.mm:1106

[github-actions[bot]]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.