Realm-cocoa: Crash in realm::Array::init_from_mem(realm::MemRef)
Question:
I am seeing a realm::Array::init_from_mem(realm::MemRef) crash in production.
I am unable to reproduce it my self.
Does anyone have an idea what could cause this?
Realm version 4.4.1
Actual Results
Crashed: com.apple.main-thread
0 Realm 0x105e35af4 realm::Array::init_from_mem(realm::MemRef) + 28
1 Realm 0x105ed349c realm::Group::attach(unsigned long, bool) + 112
2 Realm 0x105edfdd8 realm::SharedGroup::begin_read(realm::VersionID) + 88
3 Realm 0x105edcf64 realm::SharedGroup::do_open(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, bool, bool, realm::SharedGroupOptions) + 3608
4 Realm 0x105e06cb8 realm::SharedGroup::open(realm::Replication&, realm::SharedGroupOptions) + 1421 (string:1421)
5 Realm 0x105e0694c realm::SharedGroup::SharedGroup(realm::Replication&, realm::SharedGroupOptions) + 1421 (string:1421)
6 Realm 0x105dffffc realm::Realm::open_with_config(realm::Realm::Config const&, std::__1::unique_ptr<realm::Replication, std::__1::default_delete<realm::Replication> >&, std::__1::unique_ptr<realm::SharedGroup, std::__1::default_delete<realm::SharedGroup> >&, std::__1::unique_ptr<realm::Group, std::__1::default_delete<realm::Group> >&, realm::Realm*) + 1421 (string:1421)
7 Realm 0x105dff9f8 realm::Realm::Realm(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>) + 2637 (memory:2637)
8 Realm 0x105d33a54 realm::Realm::make_shared_realm(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>)::make_shared_enabler::make_shared_enabler(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>) + 4521 (memory:4521)
9 Realm 0x105d33874 std::__1::shared_ptr<realm::Realm::make_shared_realm(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>)::make_shared_enabler> std::__1::shared_ptr<realm::Realm::make_shared_realm(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>)::make_shared_enabler>::make_shared<realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator> >(realm::Realm::Config&&, std::__1::shared_ptr<realm::_impl::RealmCoordinator>&&) + 4521 (memory:4521)
10 Realm 0x105d2e328 realm::_impl::RealmCoordinator::do_get_realm(realm::Realm::Config, std::__1::shared_ptr<realm::Realm>&, std::__1::unique_lock<std::__1::mutex>&, bool) + 4230 (memory:4230)
11 Realm 0x105d2e194 realm::_impl::RealmCoordinator::get_realm(realm::Realm::Config) + 186 (shared_realm.hpp:186)
12 Realm 0x105e019e4 realm::Realm::get_shared_realm(realm::Realm::Config) + 186 (shared_realm.hpp:186)
13 Realm 0x105dd0d78 +[RLMRealm realmWithConfiguration:error:] + 4217 (memory:4217)
14 RealmSwift 0x106273d80 Realm.init() + 4331437440 (<compiler-generated>:4331437440)
15 App 0x104b88f40 static Realm.create(retry:) + 13 (Realm.swift:13)
16 App 0x104d986e8 closure #1 in closure #1 in static User.getUser() + 89 (User.swift:89)
17 libswiftObjectiveC.dylib 0x1e63f1d20 autoreleasepool<A>(invoking:) + 56
18 App 0x104b439d8 specialized thunk for @escaping @callee_guaranteed (@guaranteed @escaping @callee_guaranteed (@guaranteed SingleEvent<User>) -> ()) -> (@out Disposable) + 4307204568 (<compiler-generated>:4307204568)
19 RxSwift 0x1064829c0 partial apply for closure #1 in static PrimitiveSequenceType<>.create(subscribe:) + 39 (Single.swift:39)
20 RxSwift 0x10644f444 AnonymousObservableSink.run(_:) + 60 (Create.swift:60)
21 RxSwift 0x10644f668 AnonymousObservable.run<A>(_:cancel:) + 76 (Create.swift:76)
22 RxSwift 0x10645e448 Producer.subscribe<A>(_:) + 18 (Producer.swift:18)
23 RxSwift 0x106440258 ObservableType.subscribe(_:) + 25 (ObservableType+Extensions.swift:25)
24 RxSwift 0x106482ce4 PrimitiveSequenceType<>.subscribe(_:) + 61 (Single.swift:61)
25 RxSwift 0x10648320c PrimitiveSequenceType<>.subscribe(onSuccess:onError:) + 90 (Single.swift:90)
26 App 0x104b43454 closure #1 in SessionController.initialiseUser() + 108 (SessionController.swift:108)
27 App 0x104daced8 partial apply for thunk for @escaping @callee_guaranteed (@guaranteed @escaping @callee_guaranteed (@guaranteed SingleEvent<User>) -> ()) -> (@out Disposable) + 4309733080 (<compiler-generated>:4309733080)
28 RxSwift 0x1064829c0 partial apply for closure #1 in static PrimitiveSequenceType<>.create(subscribe:) + 39 (Single.swift:39)
29 RxSwift 0x10644f444 AnonymousObservableSink.run(_:) + 60 (Create.swift:60)
30 RxSwift 0x10644f668 AnonymousObservable.run<A>(_:cancel:) + 76 (Create.swift:76)
31 RxSwift 0x10645e448 Producer.subscribe<A>(_:) + 18 (Producer.swift:18)
32 RxSwift 0x10642c3e4 RetryWhenSequenceSink.subscribeToNext(_:) + 155 (RetryWhen.swift:155)
33 RxSwift 0x106449b20 TailRecursiveSink.moveNextCommand() + 130 (TailRecursiveSink.swift:130)
34 RxSwift 0x106449f78 protocol witness for InvocableWithValueType.invoke(_:) in conformance TailRecursiveSink<A, B> + 4333363064 (<compiler-generated>:4333363064)
35 RxSwift 0x10641b6e4 InvocableScheduledItem.invoke() + 20 (InvocableScheduledItem.swift:20)
36 RxSwift 0x10644a908 AsyncLock.invoke(_:) + 75 (AsyncLock.swift:75)
37 RxSwift 0x106448f84 TailRecursiveSink.schedule(_:) + 56 (TailRecursiveSink.swift:56)
38 RxSwift 0x106448e64 TailRecursiveSink.run(_:) + 42 (TailRecursiveSink.swift:42)
39 RxSwift 0x10642c610 RetryWhenSequenceSink.run(_:) + 161 (RetryWhen.swift:161)
40 RxSwift 0x10642cacc RetryWhenSequence.run<A>(_:cancel:) + 179 (RetryWhen.swift:179)
41 RxSwift 0x10645e448 Producer.subscribe<A>(_:) + 18 (Producer.swift:18)
42 RxSwift 0x106440258 ObservableType.subscribe(_:) + 25 (ObservableType+Extensions.swift:25)
43 RxSwift 0x106482ce4 PrimitiveSequenceType<>.subscribe(_:) + 61 (Single.swift:61)
44 RxSwift 0x10648320c PrimitiveSequenceType<>.subscribe(onSuccess:onError:) + 90 (Single.swift:90)
45 App 0x104da85fc closure #2 in IntroController.fetchMetaAndUser() + 165 (IntroController.swift:165)
46 RxSwift 0x106485384 closure #2 in ObservableType.do(onNext:afterNext:onError:afterError:onCompleted:afterCompleted:onSubscribe:onSubscribed:onDispose:) + 40 (Do.swift:40)
47 RxSwift 0x106485100 partial apply for closure #1 in ObservableType.do(onNext:afterNext:onError:afterError:onCompleted:afterCompleted:onSubscribe:onSubscribed:onDispose:) + 4333605120 (<compiler-generated>:4333605120)
48 RxSwift 0x106485670 DoSink.on(_:) + 66 (Do.swift:66)
49 RxSwift 0x1064858b0 protocol witness for ObserverType.on(_:) in conformance DoSink<A> + 4333607088 (<compiler-generated>:4333607088)
50 RxSwift 0x106458f88 Sink.forwardOn(_:) + 35 (Sink.swift:35)
51 RxSwift 0x10642bcd0 RetryWhenSequenceSinkIter.on(_:) + 85 (RetryWhen.swift:85)
52 RxSwift 0x10642c070 protocol witness for ObserverType.on(_:) in conformance RetryWhenSequenceSinkIter<A, B, C, D> + 4333240432 (<compiler-generated>:4333240432)
53 RxSwift 0x1064b65e8 closure #1 in ObserveOnSerialDispatchQueueSink.init(scheduler:observer:cancel:) + 186 (ObserveOn.swift:186)
54 RxSwift 0x1064b6d50 partial apply for thunk for @escaping @callee_guaranteed (@guaranteed ObserveOnSerialDispatchQueueSink<A>, @in_guaranteed Event<A.Element>) -> (@out Disposable) + 4333808976 (<compiler-generated>:4333808976)
55 RxSwift 0x1064354bc MainScheduler.scheduleInternal<A>(_:action:) + 63 (MainScheduler.swift:63)
56 RxSwift 0x1064b68f4 ObserveOnSerialDispatchQueueSink.onCore(_:) + 195 (ObserveOn.swift:195)
57 RxSwift 0x106442358 ObserverBase.on(_:) + 16 (ObserverBase.swift:16)
58 RxSwift 0x106442614 protocol witness for ObserverType.on(_:) in conformance ObserverBase<A> + 4333331988 (<compiler-generated>:4333331988)
59 RxSwift 0x106458f88 Sink.forwardOn(_:) + 35 (Sink.swift:35)
60 RxSwift 0x10647f798 SubscribeOnSink.on(_:) + 46 (SubscribeOn.swift:46)
61 RxSwift 0x10647fe18 protocol witness for ObserverType.on(_:) in conformance SubscribeOnSink<A, B> + 4333583896 (<compiler-generated>:4333583896)
62 RxSwift 0x106458f88 Sink.forwardOn(_:) + 35 (Sink.swift:35)
63 RxSwift 0x1064583c8 ZipSink.next(_:) + 60 (Zip.swift:60)
64 RxSwift 0x106458ad4 ZipObserver._synchronized_on(_:) + 128 (Zip.swift:128)
65 RxSwift 0x106454088 SynchronizedOnType.synchronizedOn(_:) + 15 (<compiler-generated>:15)
66 RxSwift 0x10645887c ZipObserver.on(_:) + 110 (Zip.swift:110)
67 RxSwift 0x106458b94 protocol witness for ObserverType.on(_:) in conformance ZipObserver<A> + 4333423508 (<compiler-generated>:4333423508)
68 RxSwift 0x106458f88 Sink.forwardOn(_:) + 35 (Sink.swift:35)
69 RxSwift 0x1064a2b50 DeferredSink.on(_:) + 49 (Deferred.swift:49)
70 RxSwift 0x1064a2cc4 protocol witness for ObserverType.on(_:) in conformance DeferredSink<A, B> + 4333726916 (<compiler-generated>:4333726916)
71 RxSwift 0x106458f88 Sink.forwardOn(_:) + 35 (Sink.swift:35)
72 RxSwift 0x10644f330 AnonymousObservableSink.on(_:) + 50 (Create.swift:50)
73 RxSwift 0x10644f544 protocol witness for ObserverType.on(_:) in conformance AnonymousObservableSink<A> + 4333385028 (<compiler-generated>:4333385028)
74 RxSwift 0x1064b0e64 partial apply + 4333784676 (<compiler-generated>:4333784676)
75 RxSwift 0x10642e454 AnyObserver.on(_:) + 36 (AnyObserver.swift:36)
76 RxSwift 0x106482b60 closure #1 in closure #1 in static PrimitiveSequenceType<>.create(subscribe:) + 42 (Single.swift:42)
77 App 0x104efca68 closure #1 in closure #1 in static ProfileMeta.getMeta(gender:) + 25 (ProfileMeta.swift:25)
78 RxSwift 0x1064829c0 partial apply for closure #1 in static PrimitiveSequenceType<>.create(subscribe:) + 39 (Single.swift:39)
79 RxSwift 0x10644f444 AnonymousObservableSink.run(_:) + 60 (Create.swift:60)
80 RxSwift 0x10644f668 AnonymousObservable.run<A>(_:cancel:) + 76 (Create.swift:76)
81 RxSwift 0x10645e448 Producer.subscribe<A>(_:) + 18 (Producer.swift:18)
82 RxSwift 0x1064b11b0 protocol witness for ObservableType.subscribe<A>(_:) in conformance Observable<A> + 4333785520 (<compiler-generated>:4333785520)
83 RxSwift 0x1064a2aa4 DeferredSink.run() + 37 (Deferred.swift:37)
84 RxSwift 0x1064a2ddc Deferred.run<A>(_:cancel:) + 73 (Deferred.swift:73)
85 RxSwift 0x10645e448 Producer.subscribe<A>(_:) + 18 (Producer.swift:18)
86 RxSwift 0x10646deb8 ZipSink3_.run() + 196 (Zip+arity.swift:196)
87 RxSwift 0x10646e614 Zip3.run<A>(_:cancel:) + 230 (Zip+arity.swift:230)
88 RxSwift 0x10645ea58 closure #1 in Producer.subscribe<A>(_:) + 26 (Producer.swift:26)
89 RxSwift 0x10645eb28 partial apply for thunk for @escaping @callee_guaranteed () -> (@out Disposable) + 4333447976 (<compiler-generated>:4333447976)
90 RxSwift 0x106455554 specialized CurrentThreadScheduler.schedule<A>(_:action:) + 101 (CurrentThreadScheduler.swift:101)
91 RxSwift 0x10645e5b8 Producer.subscribe<A>(_:) + 24 (Producer.swift:24)
92 RxSwift 0x1064b11b0 protocol witness for ObservableType.subscribe<A>(_:) in conformance Observable<A> + 4333785520 (<compiler-generated>:4333785520)
93 RxSwift 0x10647fb94 closure #1 in SubscribeOnSink.run() + 59 (SubscribeOn.swift:59)
94 RxSwift 0x10645e5f8 thunk for @escaping @callee_guaranteed () -> (@out Disposable) + 4333446648 (<compiler-generated>:4333446648)
95 RxSwift 0x1064291b4 closure #1 in DispatchQueueConfiguration.schedule<A>(_:action:) + 27 (DispatchQueueConfiguration.swift:27)
96 RxSwift 0x106429204 thunk for @escaping @callee_guaranteed () -> () + 4333228548 (<compiler-generated>:4333228548)
97 libdispatch.dylib 0x1b1026610 _dispatch_call_block_and_release + 24
98 libdispatch.dylib 0x1b1027184 _dispatch_client_callout + 16
99 libdispatch.dylib 0x1b100a34c _dispatch_main_queue_callback_4CF$VARIANT$armv81 + 996
100 CoreFoundation 0x1b12d73a8 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
101 CoreFoundation 0x1b12d239c __CFRunLoopRun + 2004
102 CoreFoundation 0x1b12d18a0 CFRunLoopRunSpecific + 464
103 GraphicsServices 0x1bb229328 GSEventRunModal + 104
104 UIKitCore 0x1b53c2740 UIApplicationMain + 1936
105 App 0x104b34c4c main + 15 (SignUpInputTextViewController.swift:15)
106 libdyld.dylib 0x1b115c360 start + 4
Realm Object Server version: ?
Xcode version: 11.2
iOS/OSX version: iOS 11, 12, 13
Dependency manager + version: Carthage 0.34.0
trr-amsiq
All 37 comments
Hi,
Could you tell us the version of Realm that you are using and also a code snippet with how you are using Realm?
Thanks,
Lee
leemaguire
on 25 Feb 2020
Version: 3.18.2 -> 4.3.2
Usage looks like this:
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool
Database.shared.setupRealm(compactIfNeeded: true)
}
class Database: NSObject {
func setupRealm(compactIfNeeded: Bool = false) {
let fileUrl = getFileURL()
var configuration = Realm.Configuration.defaultConfiguration
configuration.deleteRealmIfMigrationNeeded = true
configuration.fileURL = fileUrl
debugPrint("Realm - file url: \(fileUrl)")
if compactIfNeeded {
configuration.shouldCompactOnLaunch = { (totalBytes: Int, usedBytes: Int) -> Bool in
let maxSize = 150 * 1024 * 1024
guard totalBytes > maxSize else { return false }
ServiceHandler.logEventNonFatal(name: "Setup realm - Compact:", reason: "Size exeeds \(maxSize) MB")
let usage = 0.5
guard Double(usedBytes) / Double(totalBytes) < usage else { return false }
ServiceHandler.logEventNonFatal(name: "Setup realm - Compact:", reason: "Size exeeds \(maxSize) MB and usage of it is less than \(usage * 100)%")
let shouldCompact = (totalBytes > maxSize) && (Double(usedBytes) / Double(totalBytes)) < usage
ServiceHandler.logEventNonFatal(name: "Setup realm - Compact:", reason: "shouldCompact = \(shouldCompact)")
return shouldCompact
}
}
do {
_ = try Realm(configuration: configuration)
} catch {
ServiceHandler.logEventNonFatal(name: "Setup realm - Compact failed with:", reason: "\(error.localizedDescription)")
}
if compactIfNeeded {
setupRealm(compactIfNeeded: false)
} else {
Realm.Configuration.defaultConfiguration = configuration
}
}
}
Did you change something? I have the same crash in my app too :(
Realm (5.0.1)
YuryRadchenko
on 29 May 2020
I started having this too after transition from 4.4.1 -> 5.0.2
zapsleep
on 11 Jun 2020
I have a similar crash on 5.0.3:
#0 0x000000010faf7634 in realm::Array::init_from_mem(realm::MemRef) ()
#1 0x000000010fbad890 in realm::GroupWriter::GroupWriter(realm::Group&, realm::DBOptions::Durability) ()
#2 0x000000010fba6c74 in realm::DB::low_level_commit(unsigned long long, realm::Transaction&) ()
#3 0x000000010fba6aa4 in realm::DB::do_commit(realm::Transaction&) ()
#4 0x000000010fba7074 in realm::Transaction::commit_and_continue_as_read() ()
#5 0x000000010f9726dc in realm::_impl::RealmCoordinator::commit_write(realm::Realm&) ()
#6 0x000000010fa4bb4c in realm::Realm::commit_transaction() ()
#7 0x000000010fa19018 in -[RLMRealm commitWriteTransactionWithoutNotifying:error:] ()
#8 0x000000010fa18eb0 in -[RLMRealm commitWriteTransaction:] ()
For me it happens sporadically on commitwritetransaction
pkrmf
on 20 Jun 2020
Btw, I am only getting these type of crashes when using frozen objects. I have a UITableView powered by a datasource full of frozen objects. In a background thread, I have a "synchronizer" that every X minutes pulls new data from the backend, does some "merge" logic between the pulled data(unmanaged objects) and the locally stored data(managed but not frozen) and then tells the datasource to refresh with those local objects(freezing them first).
The crash was happening, in my scenario, when the synchronizer was doing all the merging logic between unmanaged objects and managed objects while the datasource was holding references to frozen objects. If the datasource, instead of holding references to frozen objects hold references to normal managed objects, I never get the crash doing the merging.
I really want to make usage of the frozen objects, its a good case scenario for my datasource, but at this point it is just impossible without getting all sort of different errors and crashes.
pkrmf
on 24 Jun 2020
any update in this crash? i have same issue, using with realm-cocoa "v.5.2.0"
cashwalk-bzjoowan
on 14 Jul 2020
This is the No. 1 crash in our app, and there are many different call stacks, which always end with init_from_mem crashing with EXC_BAD_ACCESS KERN_INVALID_ADDRESS. Started to happen after migration to v5
A few examples:
Crashed: background.thread
0 openphone 0x102d9967c realm::Array::init_from_mem(realm::MemRef) + 3465908
1 openphone 0x102e29e38 realm::Group::attach(unsigned long, bool, bool) + 555092
2 openphone 0x102e2f62c realm::Group::advance_transact(unsigned long, unsigned long, realm::_impl::NoCopyInputStream&, bool) + 577608
3 openphone 0x102a56934 void realm::Transaction::rollback_and_continue_as_read<realm::_impl::NullInstructionObserver>(realm::_impl::NullInstructionObserver*) + 3933 (memory:3933)
4 openphone 0x102a556cc realm::_impl::transaction::cancel(realm::Transaction&, realm::BindingContext*) + 555 (vector:555)
5 openphone 0x102a310ec realm::Realm::cancel_transaction() + 2636 (memory:2636)
6 openphone 0x102a00f20 -[RLMRealm cancelWriteTransaction] + 735 (RLMRealm.mm:735)
7 openphone 0x102a011a0 -[RLMRealm dealloc] + 809 (RLMRealm.mm:809)
8 libobjc.A.dylib 0x1960cc04c AutoreleasePoolPage::releaseUntil(objc_object**) + 180
9 libobjc.A.dylib 0x1960cbf44 objc_autoreleasePoolPop + 224
10 libdispatch.dylib 0x196053504 _dispatch_last_resort_autorelease_pool_pop + 40
11 libdispatch.dylib 0x1960315a4 _dispatch_lane_invoke$VARIANT$armv81 + 484
12 libdispatch.dylib 0x19603a84c _dispatch_workloop_worker_thread + 580
13 libsystem_pthread.dylib 0x1960a4b74 _pthread_wqthread + 272
14 libsystem_pthread.dylib 0x1960a7740 start_wqthread + 8
Crashed: background.thread
0 openphone 0x100ffd67c realm::Array::init_from_mem(realm::MemRef) + 3465908
1 openphone 0x10108de38 realm::Group::attach(unsigned long, bool, bool) + 555092
2 openphone 0x10109b420 realm::Transaction::Transaction(std::__1::shared_ptr<realm::DB>, realm::SlabAlloc*, realm::DB::ReadLockInfo&, realm::DB::TransactStage) + 609852
3 openphone 0x101097c60 realm::DB::start_read(realm::VersionID) + 595580
4 openphone 0x100bc184c realm::_impl::RealmCoordinator::begin_read(realm::VersionID, bool) + 138800
5 openphone 0x100c9394c realm::Realm::begin_read(realm::VersionID) + 4216 (memory:4216)
6 openphone 0x100c938a4 realm::Realm::read_group() + 3931 (memory:3931)
7 openphone 0x100c94778 realm::Realm::do_refresh() + 3933 (memory:3933)
8 openphone 0x100c6521c -[RLMRealm refresh] + 818 (RLMRealm.mm:818)
9 openphone 0x100cdcca8 Realm.refresh() + 754 (Realm.swift:754)
...
Crashed: com.apple.main-thread
0 openphone 0x1012c167c realm::Array::init_from_mem(realm::MemRef) + 3465908
1 openphone 0x100e58fa8 realm::Array::init_from_ref(unsigned long) + 4311781288
2 openphone 0x100e7f3dc realm::_impl::GroupFriend::get_history_ref(realm::Allocator&, unsigned long) + 142 (node.hpp:142)
3 openphone 0x100f80b50 bool realm::Transaction::internal_advance_read<(anonymous namespace)::KVOTransactLogObserver>((anonymous namespace)::KVOTransactLogObserver*, realm::VersionID, realm::_impl::History&, bool) + 964 (db.hpp:964)
4 openphone 0x100f7ce94 realm::_impl::transaction::begin(std::__1::shared_ptr<realm::Transaction> const&, realm::BindingContext*, realm::_impl::NotifierPackage&) + 874 (db.hpp:874)
5 openphone 0x100e88340 realm::_impl::RealmCoordinator::promote_to_write(realm::Realm&) + 149796
6 openphone 0x100f59b80 realm::Realm::begin_transaction() + 652 (shared_realm.cpp:652)
7 openphone 0x100f28a2c -[RLMRealm beginWriteTransactionWithError:] + 672 (RLMRealm.mm:672)
8 openphone 0x100f9ef5c Realm.write<A>(withoutNotifying:_:) + 257 (Realm.swift:257)
nalexn
on 17 Jul 2020
Also have this crash in realm 5.2.2
Crashed: com.apple.root.user-initiated-qos
0 Realm 0x103cd028c realm::Array::init_from_mem(realm::MemRef) + 12
1 Realm 0x103b1bda4 realm::Array::init_from_ref(unsigned long) + 8772
2 Realm 0x103b43e20 realm::_impl::GroupFriend::get_history_ref(realm::Allocator&, unsigned long) + 142 (node.hpp:142)
3 Realm 0x103c488a8 bool realm::Transaction::internal_advance_read<(anonymous namespace)::TransactLogValidator>((anonymous namespace)::TransactLogValidator, realm::VersionID, realm::_impl::History&, bool) + 964 (db.hpp:964)
4 Realm 0x103c45218 realm::_impl::transaction::begin(std::__1::shared_ptr
5 Realm 0x103b4d500 realm::_impl::RealmCoordinator::promote_to_write(realm::Realm&) + 156
6 Realm 0x103c204c8 realm::Realm::begin_transaction() + 652 (shared_realm.cpp:652)
7 Realm 0x103beec48 -[RLMRealm beginWriteTransactionWithError:] + 672 (RLMRealm.mm:672)
8 RealmSwift 0x1040b4b94 Realm.write(withoutNotifying:_:) + 257 (Realm.swift:257)
9 Slatch 0x102483214 Realm.safeWrite(_:) + 16 (RealmExt.swift:16)
gioramixin
on 19 Jul 2020
@pkrmf
when the synchronizer was doing all the merging logic between unmanaged objects and managed objects while the datasource was holding references to frozen objects. If the datasource, instead of holding references to frozen objects hold references to normal managed objects, I never get the crash doing the merging.
Out of curiosity, how are you updating the UITableView with frozen objects? Since you can't use a notificationToken on frozen results, are you using tableView.reloadData() on the .main queue when the merging finishes? This probably isn't relevant. But when trying to produce, I want to match bug reports as closely as possible.
ericjordanmossman
on 24 Jul 2020
We are also experiencing this crash quite often in Realm 5.3.2
0 Realm 0x0000000104ac2968 realm::Array::init_from_mem(realm::MemRef) + 12
1 Realm 0x0000000104b5f9b4 realm::Group::attach(unsigned long, bool, bool) + 196
2 Realm 0x0000000104b67054 realm::Group::advance_transact(unsigned long, unsigned long, realm::_impl::NoCopyInputStream&, bool) + 360
3 Realm 0x0000000104a426b8 void realm::Transaction::rollback_and_continue_as_read<realm::_impl::NullInstructionObserver>(realm::_impl::NullInstructionObserver*) + 408 (db.hpp:928)
4 Realm 0x0000000104a41438 realm::_impl::transaction::cancel(realm::Transaction&, realm::BindingContext*) + 704 (db.hpp:576)
5 Realm 0x0000000104a1b424 realm::Realm::cancel_transaction() + 64 (shared_realm.cpp:686)
6 Realm 0x00000001049eab44 -[RLMRealm cancelWriteTransaction] + 20 (RLMRealm.mm:730)
7 Realm 0x00000001049eadc4 -[RLMRealm dealloc] + 52 (RLMRealm.mm:808)
8 libobjc.A.dylib 0x00000001a9ea3c90 object_cxxDestructFromClass(objc_object*, objc_class*) + 116 (objc-class.mm:452)
9 libobjc.A.dylib 0x00000001a9eb7fcc objc_destructInstance + 92 (objc-class.mm:467)
10 libobjc.A.dylib 0x00000001a9ebe8c8 _objc_rootDealloc + 60 (objc-runtime-new.mm:7762)
11 Realm 0x000000010497ae14 -[RLMObjectBase dealloc] + 68 (RLMObjectBase.mm:92)
12 libswiftCore.dylib 0x00000001b7c9f3a0 swift_arrayDestroy + 84 (Array.cpp:208)
13 libswiftCore.dylib 0x00000001b79f6390 _ContiguousArrayStorage.__deallocating_deinit + 48 (UnsafePointer.swift:893)
14 libswiftCore.dylib 0x00000001b7caa00c _swift_release_dealloc + 36 (HeapObject.cpp:626)
Limoo
on 6 Aug 2020
Any updates? Having the same issue in production. All of them seem to be on iOS 13 currently.
sailor002
on 14 Aug 2020
Can confirm that issue
MortyMerr
on 17 Aug 2020
@sailor002
Any updates?
No updates. I originally spent a couple of days trying to reproduce based on instructions alone. So far it's been elusive. Very difficult to control for all variables.
If anyone is able to provide a sample reproduction project, that could help immensely.
ericjordanmossman
on 17 Aug 2020
Well, actually I can't reproduce it myself too :) But Firebase reports this error in production, and more than 5% of the users are affected.
sailor002
on 20 Aug 2020
Worth noting: this issue starts with a stack trace from an older Core version and it crashes immediately during opening. All the following reports refers to Core v6.0.xxx, and are all about attaching to the top array or just below it. Since it's about attaching, they are all related to setup at transaction boundaries.
finnschiermer
on 3 Sep 2020
I have changed the way I access the realm object and the problem seems to be solved right now. Previously, I was creating a realm object in a function from a background thread and using it inside that function scope. And this background function was triggered repeatedly to perform multiple tasks. This approach did not cause any errors on my side, and neither did the 95% percent of users had any issues. However, around 5% of the users were getting this error. Then I changed the structure and created a single realm object on the UI thread. I now access this realm object from a DispatchQueue.main.async block from the background thread and the problem seems to be disappeared right now. So the difference is that instead of initializing the realm objects locally from the background thread, I now have a single realm object on the UI thread. Hope this approach helps anyone facing the same problem.
sailor002
on 9 Sep 2020
Interesting. Thx for the description @sailor002.
finnschiermer
on 10 Sep 2020
Though it looks different, there is some non-zero chance that it is fixed by https://github.com/realm/realm-core/issues/3904. It'll be valuable to know if any further sightings occur after Core 6.0.25
finnschiermer
on 10 Sep 2020
It'll be valuable to know if any further sightings occur after Core 6.0.25
For everyone's information, core 6.0.25 is in our latest realm-cocoa 5.4.0. Please upgrade and let us know.
ericjordanmossman
on 10 Sep 2020
This still happens in 5.4.0:
Realm
realm::Array::init_from_mem(realm::MemRef)
Realm
_hidden#588_ __hidden#691_:169
Realm
_hidden#2434_ __hidden#1818_:1213
Realm
_hidden#13219_ __hidden#2736_:964
Realm
realm::_impl::transaction::advance(std::__1::shared_ptr<realm::Transaction> const&, realm::BindingContext*, realm::_impl::NotifierPackage&) __hidden#13259_:524
Realm
realm::_impl::RealmCoordinator::advance_to_latest(realm::Realm&) __hidden#3043_:1075
Realm
realm::Realm::do_refresh() __hidden#11503_:846
Realm
_hidden#8989_ __hidden#9187_:818
RealmSwift
RealmSwift.Realm.refresh() -> Swift.Bool __hidden#3035_:754
shuhaodo
on 21 Sep 2020
@shuhaodo Would you be able to give us a sandbox app that reproduces this issue?
leemaguire
on 21 Sep 2020
Still in 5.4.2
Also getting mmap() failed: Cannot allocate memory size: 67108864 offset: 603979776
Crashed: com.apple.root.user-initiated-qos
0 Xxxxxx 0x1050c65b0 realm::Array::init_from_mem(realm::MemRef) + 106 (__hidden#281_:106)
1 Xxxxxx 0x1050c6848 _hidden#468_ + 170 (__hidden#600_:170)
2 Xxxxxx 0x10514fb5c realm::Group::attach(unsigned long, bool, bool) + 704 (__hidden#3983_:704)
3 Xxxxxx 0x10514bb7c realm::Transaction::Transaction(std::__1::shared_ptr<realm::DB>, realm::SlabAlloc*, realm::DB::ReadLockInfo&, realm::DB::TransactStage) + 485368
4 Xxxxxx 0x105148a80 realm::DB::start_read(realm::VersionID) + 472828
5 Xxxxxx 0x104fdeb24 realm::_impl::RealmCoordinator::begin_read(realm::VersionID, bool) + 4344212260
6 Xxxxxx 0x10501c040 realm::Realm::begin_read(realm::VersionID) + 4215 (__hidden#15_:4215)
7 Xxxxxx 0x10501bf98 realm::Realm::read_group() + 3931 (__hidden#15_:3931)
8 Xxxxxx 0x10501ceb4 realm::Realm::do_refresh() + 3933 (__hidden#15_:3933)
9 Xxxxxx 0x1050ad548 _hidden#9514_ + 818 (__hidden#9671_:818)
10 Xxxxxx 0x105259038 Realm.refresh() + 754 (__hidden#2651_:754)
11 Xxxxxx 0x1049447e8 closure #1 in static AccountCollection.privateCleanupList(lists:) + 4337289192 (<compiler-generated>:4337289192)
12 Xxxxxx 0x104997674 thunk for @callee_guaranteed () -> (@error @owned Error) + 4337628788 (<compiler-generated>:4337628788)
13 Xxxxxx 0x104947284 partial apply for thunk for @callee_guaranteed () -> (@error @owned Error) + 4337300100 (<compiler-generated>:4337300100)
14 libswiftObjectiveC.dylib 0x1be6dabcc autoreleasepool<A>(invoking:) + 56
15 Xxxxxx 0x104947198 partial apply for closure #1 in static AccountCollection.cleanupListAsync(lists:delay:) + 4337299864 (<compiler-generated>:4337299864)
16 Xxxxxx 0x104acbfe8 thunk for @escaping @callee_guaranteed () -> () + 4338892776 (<compiler-generated>:4338892776)
17 libdispatch.dylib 0x187c73524 _dispatch_client_callout + 16
18 libdispatch.dylib 0x187c4d274 _dispatch_continuation_pop$VARIANT$armv81 + 404
19 libdispatch.dylib 0x187c5d410 _dispatch_source_invoke$VARIANT$armv81 + 1220
20 libdispatch.dylib 0x187c59534 _dispatch_root_queue_drain + 344
21 libdispatch.dylib 0x187c59cd0 _dispatch_worker_thread2 + 112
22 libsystem_pthread.dylib 0x187cc4b38 _pthread_wqthread + 212
23 libsystem_pthread.dylib 0x187cc7740 start_wqthread + 8
@shuhaodo Would you be able to give us a sandbox app that reproduces this issue?
How should I do that? A test flight build?
shuhaodo
on 26 Sep 2020
@shuhaodo It would be preferred if you could pass along your app code. If that's not feasible, a decent sized code sample would be helpful to us.
jsflax
on 26 Sep 2020
using 5.4.7
Crashed: com.slatch.dataQueue
0 Realm 0x10555fe5c realm::Array::init_from_mem(realm::MemRef) + 20
1 Realm 0x1055f547c realm::Group::attach(unsigned long, bool, bool) + 196
2 Realm 0x1055fcf68 realm::Group::advance_transact(unsigned long, unsigned long, realm::_impl::NoCopyInputStream&, bool) + 276
3 Realm 0x1054d65d0 void realm::Transaction::rollback_and_continue_as_read
4 Realm 0x1054d525c realm::_impl::transaction::cancel(realm::Transaction&, realm::BindingContext) + 555 (vector:555)
5 Realm 0x1054b50fc realm::Realm::cancel_transaction() + 2608 (memory:2608)
6 Realm 0x1054848f8 -[RLMRealm cancelWriteTransaction] + 735 (RLMRealm.mm:735)
7 Realm 0x105484b78 -[RLMRealm dealloc] + 809 (RLMRealm.mm:809)
8 libobjc.A.dylib 0x1887db38c (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 676
9 libdispatch.dylib 0x18902a464 _dispatch_last_resort_autorelease_pool_pop + 40
10 libdispatch.dylib 0x188fd2778 _dispatch_lane_invoke$VARIANT$mp + 528
11 libdispatch.dylib 0x188fdaeb8 _dispatch_workloop_worker_thread + 600
12 libsystem_pthread.dylib 0x18920d0dc _pthread_wqthread + 312
13 libsystem_pthread.dylib 0x18920fcec start_wqthread + 4
still happens
gioramixin
on 8 Oct 2020
Reordered this to the initial realm call. Now the crash is completely gone
// Get our Realm file's parent directory
let folderPath = configuration.fileURL!.deletingLastPathComponent().path
// Disable file protection for this directory
try! FileManager.default.setAttributes([FileAttributeKey(rawValue: FileAttributeKey.protectionKey.rawValue): FileProtectionType.none], ofItemAtPath: folderPath)
// This is the part that used to crash
let realm = try Realm(configuration: configuration)
Before I had the same order as in the docs. Seems more safe to disable protection before opening the realm.
trr-amsiq
on 20 Nov 2020
Any updates on it?
We get the same on 10.1.4
Crashed: BaseFileSyncManager.processQueue.CC283DBC-BAFF-4CB2-9BA8-420189EA81C8
0 Xxxxxx 0x101b322a8 _hidden#113_ + 204 (__hidden#171_:204)
1 Xxxxxx 0x1019cf0a4 _hidden#645_ + 568 (__hidden#748_:568)
2 Xxxxxx 0x1019de6ec _hidden#1648_ + 135 (__hidden#802_:135)
3 Xxxxxx 0x1019e3388 _hidden#1887_ + 966 (__hidden#1414_:966)
4 Xxxxxx 0x1019df6a4 realm::_impl::transaction::advance(std::__1::shared_ptr<realm::Transaction> const&, realm::BindingContext*, realm::_impl::NotifierPackage&) + 3831 (__hidden#20_:3831)
5 Xxxxxx 0x1019d7058 realm::_impl::RealmCoordinator::advance_to_latest(realm::Realm&) + 3826 (__hidden#20_:3826)
6 Xxxxxx 0x101a19cd8 realm::Realm::do_refresh() + 819 (__hidden#4118_:819)
7 Xxxxxx 0x101ad7b88 _hidden#11049_ + 759 (__hidden#11192_:759)
8 Xxxxxx 0x101b11b54 Realm.refresh() + 782 (__hidden#3095_:782)
9 Xxxxxx 0x101351560 specialized RealmDatabaseManager.object<A>(_:iid:) + 119 (RealmDatabaseManager.swift:119)
10 Xxxxxx 0x101351b24 RealmDatabaseManager.object<A>(id:) + 128 (RealmDatabaseManager.swift:128)
11 Xxxxxx 0x10135376c protocol witness for DatabaseManager.object<A>(id:) in conformance RealmDatabaseManager + 4337006444 (<compiler-generated>:4337006444)
12 Xxxxxx 0x1012c638c BaseFileSyncManager.getFromLocalStorages(trackId:forNotification:) + 380 (BaseFileSyncManager.swift:380)
13 Xxxxxx 0x1012c5de0 closure #1 in BaseFileSyncManager.handleStreamRequest(trackIds:) + 235 (BaseFileSyncManager.swift:235)
14 Xxxxxx 0x1012c2b30 BaseFileSyncManager.handleStreamRequest(trackIds:) + 4336413488 (<compiler-generated>:4336413488)
15 Xxxxxx 0x1012c296c closure #1 in BaseFileSyncManager.requestFile(_:) + 88 (BaseFileSyncManager.swift:88)
16 Xxxxxx 0x100eb2db0 thunk for @escaping @callee_guaranteed () -> () + 4332154288 (<compiler-generated>:4332154288)
17 libdispatch.dylib 0x18e175298 _dispatch_call_block_and_release + 24
18 libdispatch.dylib 0x18e176280 _dispatch_client_callout + 16
19 libdispatch.dylib 0x18e1524fc _dispatch_lane_serial_drain$VARIANT$armv81 + 568
20 libdispatch.dylib 0x18e15301c _dispatch_lane_invoke$VARIANT$armv81 + 456
21 libdispatch.dylib 0x18e15c808 _dispatch_workloop_worker_thread + 692
22 libsystem_pthread.dylib 0x1d3d905a4 _pthread_wqthread + 272
23 libsystem_pthread.dylib 0x1d3d93874 start_wqthread + 8
igrechuhin
on 10 Dec 2020
We can not reproduce it, but it happens VERY frequently at our users.
More than 6k crashes per day.
Is there any logging I can add to the app to help investigate and fix this issue?
igrechuhin
on 10 Dec 2020
@igrechuhin can you get hold of a couple of realm files from platforms where the crash happened... we may be able to find something interesting in them?
finnschiermer
on 14 Dec 2020
@finnschiermer Sure, where should I send it?
igrechuhin
on 16 Dec 2020
@igrechuhin Please send it to [email protected]
finnschiermer
on 16 Dec 2020
@finnschiermer I've sent files to you. Please tell if I can assist in any way.
igrechuhin
on 16 Dec 2020
@igrechuhin Thx for the realm files. They check out fine. Which at least shows us that the errors can happen without any underlying file corruption.
finnschiermer
on 17 Dec 2020
I can't help notice that on this bug report we have two reports of the problems going away by changing the app. Is there anything in common to these 2 descriptions:
first by @trr-amsiq :
Reordered this to the initial realm call. Now the crash is completely gone
// Get our Realm file's parent directory let folderPath = configuration.fileURL!.deletingLastPathComponent().path // Disable file protection for this directory try! FileManager.default.setAttributes([FileAttributeKey(rawValue: FileAttributeKey.protectionKey.rawValue): FileProtectionType.none], ofItemAtPath: folderPath) // This is the part that used to crash let realm = try Realm(configuration: configuration)Before I had the same order as in the docs. Seems more safe to disable protection before opening the realm.
second by @sailor002 :
I have changed the way I access the realm object and the problem seems to be solved right now. Previously, I was creating a realm object in a function from a background thread and using it inside that function scope. And this background function was triggered repeatedly to perform multiple tasks. This approach did not cause any errors on my side, and neither did the 95% percent of users had any issues. However, around 5% of the users were getting this error. Then I changed the structure and created a single realm object on the UI thread. I now access this realm object from a DispatchQueue.main.async block from the background thread and the problem seems to be disappeared right now. So the difference is that instead of initializing the realm objects locally from the background thread, I now have a single realm object on the UI thread. Hope this approach helps anyone facing the same problem.
^ does this tell you anthing @leemaguire @tgoyne ?
finnschiermer
on 17 Dec 2020
@finnschiermer thank you for reply.
We do use first advice. The only difference is that instead of
FileAttributeKey(rawValue: FileAttributeKey.protectionKey.rawValue): FileProtectionType.none
we use
[.protectionKey: FileProtectionType.completeUntilFirstUserAuthentication].
We think these are equivalent in our case because Realm is opened once the device in unlocked.
Tell me if I'm wrong.
As for the second. Am I right that we should make all writes on one explicit queue? Or should we use only main queue for writes?
Both cases are not that easy to implement, but "main queue" case will also make app unresponsive.
Or I've missed something and there is another workaround?
Can I assist in any way?
We have around 20 different stack traces with crashes in Realm with more than 1k events for each.
Two most critical make around 286k crashes per 70k users.
I can give an access to these reports if required.
igrechuhin
on 17 Dec 2020
@igrechuhin We need one of my friends with deep knowledge of the cocoa SDK to step in at this point.
finnschiermer
on 17 Dec 2020
Related issues
BackWorld
路
3Comments
carvalho-oak
路
3Comments
mowens
路
3Comments
duribreux
路
3Comments
ishidakei
路
3Comments
Most helpful comment
I started having this too after transition from 4.4.1 -> 5.0.2