realm-swift: Crash when adding object to realm
How frequently does the bug occur?
Sometimes
Description
Realm seems to crash for some users when adding new objects to realm
I have seen similar issues since 10.22.0, but this is also happening since the 10.24.0 upgrade.
Stacktrace & log output
Crashed: com.apple.main-thread
SIGABRT ABORT 0x00000001b8563964
shell
Crashed: com.apple.main-thread
0 libsystem_kernel.dylib 0x28414 __pthread_kill + 8
1 libsystem_pthread.dylib 0x2b40 pthread_kill + 272
2 libsystem_c.dylib 0x76b74 abort + 104
3 MyApp 0x6806d8 std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> >::basic_stringstream() + 821 (sstream:821)
4 MyApp 0x6808dc realm::util::terminate_internal(std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> >&) + 123 (terminate.cpp:123)
5 MyApp 0x680a14 realm::util::terminate(char const*, char const*, long, std::initializer_list<realm::util::Printable>&&) + 140 (terminate.cpp:140)
6 MyApp 0x358284 realm::BPlusTree<double>::get_uncached(unsigned long) const + 371 (bplustree.hpp:371)
7 MyApp 0x4b60f0 realm::Node::calc_item_count(unsigned long, unsigned long) const + 61 (node.cpp:61)
8 MyApp 0x4b6144 realm::Node::alloc(unsigned long, unsigned long) + 76 (node.cpp:76)
9 MyApp 0x42e52c realm::Array::alloc(unsigned long, unsigned long) + 207 (array.hpp:207)
10 MyApp 0x42e9e8 realm::Array::insert(unsigned long, long long) + 447 (array.cpp:447)
11 MyApp 0x44124c realm::ArrayTimestamp::insert(unsigned long, realm::Timestamp) + 70 (array_timestamp.cpp:70)
12 MyApp 0x44d860 void realm::Cluster::do_insert_row<realm::ArrayTimestamp>(unsigned long, realm::ColKey, realm::Mixed, bool) + 28 (array_timestamp.hpp:28)
13 MyApp 0x44c9dc realm::util::FunctionRef<bool (realm::ColKey)>::FunctionRef<realm::Cluster::insert_row(unsigned long, realm::ObjKey, std::__1::vector<realm::FieldValue, std::__1::allocator<realm::FieldValue> > const&)::$_1&>(realm::Cluster::insert_row(unsigned long, realm::ObjKey, std::__1::vector<realm::FieldValue, std::__1::allocator<realm::FieldValue> > const&)::$_1&)::'lambda'(void*, realm::ColKey)::__invoke(void*, realm::ColKey) + 378 (cluster.cpp:378)
14 MyApp 0x6551dc realm::TableClusterTree::for_each_and_every_column(realm::util::FunctionRef<bool (realm::ColKey)>) const + 119 (function_ref.hpp:119)
15 MyApp 0x4482e4 realm::Cluster::insert_row(unsigned long, realm::ObjKey, std::__1::vector<realm::FieldValue, std::__1::allocator<realm::FieldValue> > const&) + 409 (cluster.cpp:409)
16 MyApp 0x449f38 realm::Cluster::insert(realm::ObjKey, std::__1::vector<realm::FieldValue, std::__1::allocator<realm::FieldValue> > const&, realm::ClusterNode::State&) + 672 (cluster.cpp:672)
17 MyApp 0x456d24 realm::ClusterTree::insert_fast(realm::ObjKey, std::__1::vector<realm::FieldValue, std::__1::allocator<realm::FieldValue> > const&, realm::ClusterNode::State&) + 882 (cluster_tree.cpp:882)
18 MyApp 0x456ec0 realm::ClusterTree::insert(realm::ObjKey, std::__1::vector<realm::FieldValue, std::__1::allocator<realm::FieldValue> > const&) + 906 (cluster_tree.cpp:906)
19 MyApp 0x654f7c realm::TableClusterTree::insert(realm::ObjKey, std::__1::vector<realm::FieldValue, std::__1::allocator<realm::FieldValue> > const&) + 47 (table_cluster_tree.cpp:47)
20 MyApp 0x64adf8 realm::Table::create_object_with_primary_key(realm::Mixed const&, std::__1::vector<realm::FieldValue, std::__1::allocator<realm::FieldValue> >&&, bool*) + 3010 (table.cpp:3010)
21 MyApp 0x2f3de8 realm::Table::create_object_with_primary_key(realm::Mixed const&, bool*) + 463 (vector:463)
22 MyApp 0x2e924c realm::Object realm::Object::create<objc_object* __strong, RLMAccessorContext>(RLMAccessorContext&, std::__1::shared_ptr<realm::Realm> const&, realm::ObjectSchema const&, objc_object* __strong, realm::CreatePolicy, realm::ObjKey, realm::Obj*) + 298 (object_accessor.hpp:298)
23 MyApp 0x2e8c70 RLMAccessorContext::createObject(objc_object*, realm::CreatePolicy, bool, realm::ObjKey) + 1093 (RLMAccessor.mm:1093)
24 MyApp 0x330774 RLMAddObjectToRealm + 139 (RLMObjectStore.mm:139)
25 MyApp 0x75150 thunk for @callee_guaranteed () -> (@error @owned Error) + 4343763280 (<compiler-generated>:4343763280)
26 MyApp 0x24c788 partial apply for thunk for @callee_guaranteed () -> (@error @owned Error) + 4345694088 (<compiler-generated>:4345694088)
27 MyApp 0x24d6b4 thunk for @callee_guaranteed () -> (@error @owned Error)partial apply + 4345697972
28 MyApp 0x75a0a4 Realm.write<A>(withoutNotifying:_:) + 255 (Realm.swift:255)
Can you reproduce the bug?
Not yet
Reproduction Steps
No response
Version
10.24.0
What SDK flavour are you using?
Local Database only
Are you using encryption?
No, not using encryption
Platform OS and version(s)
iOS 15
Build environment
Xcode version: 13.2.1 Dependency manager and version: SPM
About this issue
- Original URL
- State: open
- Created 2 years ago
- Comments: 24 (4 by maintainers)
@shimastripe I don’t think you won’t be able to reproduce this. The transaction causing corrupted data could have happened anywhere. I am seeing fewer issues now than I did in the 10.22.0 update, but I still have customers reaching out every week with realms that are corrupted 😕 I don’t know if that is because they were using the 10.22.0 update and then waited to reach out or if this is still an issue.
I was in contact with support and since Realm is using hard asserts when bad data is discovered I can not provide the user with an error dialog informing them that there is a problem with their data. The ticket was basically closed as a won’t fix as the app probably won’t function anyway with corrupt data in there and the assertion would be justified. But it does lead to a bad user experience. All I can do is wait for the negative reviews and angry customers to reach out 😦