-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
How frequently does the bug occur?
Sometimes
Description
We get a lot of crash reports from Sentry. Below I attach the stack trace itself and the code of our function in which the crash occurred. If you need any additional information about the bug, we are ready to provide it.
Our function:
open func remove(_ objects: [Object], realm: Realm? = nil) {
guard let realm = realm ?? createRealmInstance() else
do {
try realm.write
} catch
{ print("Unexpected error: \(error).") }}
Stacktrace & log output
Unable to find source-code formatter for language: shell. Available languages are: actionscript, ada, applescript, bash, c, c#, c++, cpp, css, erlang, go, groovy, haskell, html, java, javascript, js, json, lua, none, nyan, objc, perl, php, python, r, rainbow, ruby, scala, sh, sql, swift, visualbasic, xml, yaml
Sentry stack trace: libsystem_pthread +0x0023f0 pthread_kill libsystem_c +0x073f80 abort Realm +0x2f74c8 please_report_this_issue_in_github_realm_realm_core_v_12_5_1 Realm +0x2f77b0 realm::util::terminate_internal(std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> >&) Realm +0x2f79ac realm::util::terminate_with_info(char const*, char const*, long, char const*, std::initializer_list<realm::util::Printable>&&) Realm +0x15d484 realm::util::terminate_with_info<unsigned long&, unsigned long&, unsigned long const&, unsigned long&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >(char const*, int, char const*, char const*, unsigned long&, un... Realm +0x15d25c realm::SlabAlloc::do_free(unsigned long, char*) Realm +0x1b6abc realm::WrappedAllocator::do_free(unsigned long, char*) Realm +0x165ba4 realm::Array::destroy_deep(realm::MemRef, realm::Allocator&) Realm +0x16e4e0 realm::ArrayBinary::erase(unsigned long) Realm +0x18bab0 realm::util::FunctionRef<bool (realm::ColKey)>::FunctionRef<realm::Cluster::erase(realm::ObjKey, realm::CascadeState&)::$_3&>()::{lambda(void*, realm::ColKey(void*, realm::ColKey))#1}::__invoke Realm +0x2c7318 realm::TableClusterTree::for_each_and_every_column(realm::util::FunctionRef<bool (realm::ColKey)>) const Realm +0x185568 realm::Cluster::erase(realm::ObjKey, realm::CascadeState&) Realm +0x195558 realm::ClusterNodeInner::erase(realm::ObjKey, realm::CascadeState&)::$_3::operator()(realm::ClusterNode*, realm::ClusterNodeInner::ChildInfo&) const Realm +0x191450 realm::ClusterNodeInner::erase(realm::ObjKey, realm::CascadeState&) Realm +0x1941a4 realm::ClusterTree::erase(realm::ObjKey, realm::CascadeState&) Realm +0x2bbe0c realm::Table::remove_object(realm::ObjKey) Realm +0x20a4c4 realm::Obj::remove() Realm +0x066ae4 RLMDeleteObjectFromRealm (RLMObjectStore.mm:170) RealmSwift +0x06a1e8 delete (Realm.swift:680) RealmSwift +0x06a1e8 Realm.delete<A>(A) (Realm.swift:700) AppleUtils +0x01485c ? (Database.swift:96) AppleUtils +0x01485c partial apply for closure realm/realm-swift#1 () in Database.remove(_: [RealmSwiftObject], realm: Realm?) (<compiler-generated>) AppleUtils +0x014778 partial apply for thunk for @callee_guaranteed () -> (@error @owned Error) (<compiler-generated>) AppleUtils +0x014c6c thunk for @callee_guaranteed () -> (@error @owned Error)partial apply RealmSwift +0x068dc8 Realm.write<A>(withoutNotifying: [RLMNotificationToken], _: ()) (Realm.swift:258) AppleUtils +0x013e9c Database.add(_: [RealmSwiftObject], realm: Realm?) TVPlatform_Core +0x05e64c closure realm/realm-swift#1 () in GuideCacheStore.removeItems(from: Date, till: Date) (GuideCacheStore.swift:91) TVPlatform_Core +0x103edc thunk for @escaping @callee_guaranteed () -> () (<compiler-generated>) libdispatch +0x0030ec <redacted> libdispatch +0x00491c <redacted> libdispatch +0x00b5fc <redacted> libdispatch +0x00c0a4 <redacted> libdispatch +0x015fcc <redacted> libsystem_pthread +0x003174 _pthread_wqthread
Can you reproduce the bug?
Not yet
Reproduction Steps
No response
Version
10.28.7
What SDK flavour are you using?
Local Database only
Are you using encryption?
No, not using encryption
Platform OS and version(s)
TvOS 16.0
Build environment
Xcode version: ...
Dependency manager and version: ...