Realm-cocoa: EXC_BAD_ACCESS KERN_INVALID_ADDRESS realm::util::EncryptedFileMapping::read_barrier crash!!!
!!! MANDATORY TO FILL OUT !!!
Goals
no source code and configuration change.
After update realm 5.0.2, crash occurs many times. Please help!
Expected Results
Actual Results
Crashed: com.apple.root.default-qos
0 Realm 0x10414eef8 realm::util::EncryptedFileMapping::read_barrier(void const, unsigned long, unsigned long ()(char const)) + 32
1 Realm 0x103e4eb78 realm::util::do_encryption_read_barrier(void const, unsigned long, unsigned long ()(char const), realm::util::EncryptedFileMapping*) + 8932
2 Realm 0x1040f0490 long long realm::ConstObj::_get
3 App 0x102ed7e80 syncError #1 (c:o:done:) in CloudManager.handleError(_:) + 74 (CloudManager.swift:74)
4 App 0x102ed919c doHandleError #1 () in CloudManager.handleError(_:) + 150 (CloudManager.swift:150)
5 App 0x102fce850 thunk for @callee_guaranteed () -> (@error @owned Error) + 4301809744 (
6 App 0x102ee4820 partial apply for thunk for @callee_guaranteed () -> (@error @owned Error) + 4300851232 (
7 App 0x102ee6514 thunk for @callee_guaranteed () -> (@error @owned Error)partial apply + 4300858644
8 libswiftObjectiveC.dylib 0x1f35f7bbc autoreleasepool(invoking:) + 56
9 App 0x102ee4f3c partial apply for closure #1 in CloudManager.handleError(_:) + 4300853052 (
10 App 0x1031573ec thunk for @escaping @callee_guaranteed () -> () + 4303418348 (
11 libdispatch.dylib 0x1bcbc69a8 _dispatch_call_block_and_release + 24
12 libdispatch.dylib 0x1bcbc7524 _dispatch_client_callout + 16
13 libdispatch.dylib 0x1bcb6fc60 _dispatch_queue_override_invoke + 952
14 libdispatch.dylib 0x1bcb7c438 _dispatch_root_queue_drain + 376
15 libdispatch.dylib 0x1bcb7cbf8 _dispatch_worker_thread2 + 124
16 libsystem_pthread.dylib 0x1bcc18b38 _pthread_wqthread + 212
17 libsystem_pthread.dylib 0x1bcc1b740 start_wqthread + 8
Steps to Reproduce
crash occurs randomly in only 5.0.x version.
Code Sample
func syncError(c: CloudError, o: Object?, done: (() -> Void)?) {
var name: String = ""
var pred: NSPredicate?
var params = String:Any?
var update: Date?
var check: Bool = true
if c.dataType == 0 { ///===> CRASH!!!!!!!!!
name = "Entry"
if let entry = o as? Entry {
pred = NSPredicate(format: "sid == %@", entry.sid)
params = entry.toCloudParams()
update = entry.update
}
} else if c.dataType == 1 {
name = "Day"
if let day = o as? Day {
pred = NSPredicate(format: "sid == %@", day.sid)
params = day.toCloudParams()
update = day.update
}
} else if c.dataType == 2 {
name = "ColorLabel"
if let colorLabel = o as? ColorLabel {
pred = NSPredicate(format: "sid == %@", colorLabel.sid)
params = colorLabel.toCloudParams()
update = colorLabel.update
}
check = false
}
let dataKey = c.dataKey
if let _pred = pred {
CloudQuery.fetch(self.cloud.privateDB, recordType: name, predicate: _pred, forCheck: check, done: { (ret, err) in
if err != nil {
completeError(err, dataKey: dataKey)
done?()
} else {
if let _ret = ret as? [CKRecord], !_ret.isEmpty, let first = _ret.first {
if let left = update, let right = first["update"] as? Date, left > right {
CloudQuery.update(self.cloud.privateDB, record: first, keyedValues: params, done: { (ret, err) in
completeError(err, dataKey: dataKey)
done?()
})
} else {
completeError(nil, dataKey: dataKey)
done?()
}
} else {
CloudQuery.insert(self.cloud.privateDB, recordType: name, keyedValues: params, done: { (ret, err) in
completeError(err, dataKey: dataKey)
done?()
})
}
}
})
} else {
completeError(nil, dataKey: dataKey)
done?()
}
}
func doHandleError() {
var deletes = Set<String>()
if let ces = Fetch.cloudError([:]), !ces.isEmpty {
for c in ces {
if c.syncOp == 100 || c.tryCount >= self.maxCloudTryCount {
deletes.insert(c.dataKey)
} else {
var o: Object?
if c.dataType == 0 { //entry
o = Fetch.entry(["sid":c.dataKey], all: true)?.first
} else if c.dataType == 1 { //day
o = Fetch.day(["sid":c.dataKey], all: true)?.first
}
todos.append((c, o))
}
}
}
for t in todos {
let group = DispatchGroup()
group.enter()
syncError(c: t.0, o: t.1) {
group.leave()
}
group.wait()
}
for d in deletes {
if let c = Fetch.cloudError(["dataKey":d])?.first {
Delete.cloudError(c)
}
}
}
let group = DispatchGroup()
let queue = DispatchQueue.global()
queue.async(group: group) {
autoreleasepool {
doHandleError()
}
}
group.notify(queue: queue) {
done?()
}
Version of Realm and Tooling
5.0.2
Realm framework version: ?
5.0.2
Realm Object Server version: ?
Xcode version: ?
11.5
iOS/OSX version: ?
13.4
Dependency manager + version: ?
jeongmin-more
All 18 comments
Same for me
Krysbe
on 9 Jun 2020
Same here, after the update from 4.4.1 to 5.0.2 Realm will crash randomly sometime when retrieving an object at
#1 0x0000000112b72dc0 in realm::util::do_encryption_read_barrier(void const*, unsigned long, unsigned long (*)(char const*), realm::util::EncryptedFileMapping*) at /ProjectDir/Pods/Realm/include/core/realm/util/file_mapper.hpp:133
with
Thread 11: EXC_BAD_ACCESS (code=1, address=0x372)
This crash happened on a concurrent queue, if it can help.
iDevid
on 11 Jun 2020
crash occurs in for loop.
I think, realm 5.0.x version has critical bugs about threads.
I'm modifying the code like below. That's really annoying.
But below code is fine, no crashes.
jeongmin-more
on 11 Jun 2020
Same for me
zapsleep
on 11 Jun 2020
@tgoyne can you give a look?
iDevid
on 11 Jun 2020
Looks like same here - https://github.com/realm/realm-cocoa/issues/6571
In our project we had this crash appear randomly on app launch.
When I had a look at our helpers, I saw that we were not using notifications as we should - we got Results from background thread, then passed them wrapped in ThreadSafeReference to main thread to subscribe there, so we will receive notifications on main thread.
But notifications themselves offered Results in notification block.
Moreover, as I started refactoring, I noticed new queue-confined notifications. I looked up the code for subscribing and noticed, that original Realm from Results was saved there and also passed to the queue along with reference to Results.
So I thought - maybe that caused the crash. I did not pass original Realm to main thread, maybe after some time it got into the autorelease pool and the Results I was passing got corrupted somehow. So when I was dereferencing them they were not backed by anything and I got the crash accessing wrong address.
It was only a theory, so I decided to refactor helpers to use results passed along with changes.
Refactoring helped with this crash, but introduced a new one - https://github.com/realm/realm-cocoa/issues/6559.
Then after some digging and more refactoring I think I got rid of that one too (see comments in the issue).
Maybe this info will help fixing these issues.
OneSman7
on 11 Jun 2020
Running into the same issue after updating to 5.0.3 from 4.x
pkrmf
on 11 Jun 2020
We have experienced a similar issue after upgrading from 5.0.2 to 5.0.3. ~I'm still investigating, but I have confirmed that rolling back to 5.0.2 appears to have resolved our reported issues.~ EDIT: It appears that the issue happens sporadically, and a revert to 4.4.1 is necessary.
SticklyMan
on 14 Jun 2020
Experiencing the same on 5.0.3 from 4.x on iOS 13.5.1
thiagohmcruz
on 15 Jun 2020
Same issue after an update from 4.3.0 to 5.0.2 on all of our devices running iOS 13.5 and below
SynnyGR
on 15 Jun 2020
@SticklyMan Have you been able to revert to 4.4.1? 5.0.x updates a db to v10 and 4.4.1 is v9. Downgrading will lead to crash.
@bmunkholm could you please give us any update on the status for this issue? I have almost 100 crashes a day in production and don't know what to do about it.
zapsleep
on 16 Jun 2020
@zapsleep I took the "quick" approach and wiped the existing Realm files and folders (<x>.realm, <x>.realm.lock, and <x>.realm.management/) in the event that the Realm could not be opened (try/catch on Realm init).
This worked well in our case because:
- 99% of the data in our user's Realms can be re-downloaded. The only chance for data loss is if they've been offline and haven't synced up to our servers.
- We rolled out a staging version to a beta group who caught the issue before we fully released it.
- This is temporary code that we can quickly remove once we've confirmed that our beta users have properly updated.
- We do not use Realm Sync (may or may not be a factor that adds complexity, I'm not sure)
SticklyMan
on 16 Jun 2020
@tgoyne @jedelbo Any clues?
bmunkholm
on 16 Jun 2020
It seems to fit this issue in Core: https://github.com/realm/realm-core/issues/3766
finnschiermer
on 16 Jun 2020
@SticklyMan Thanks for the tip! I guess I'll have to rely on this too until guys from Realm fix the issue with 5.x
zapsleep
on 16 Jun 2020
Probably fixed by https://github.com/realm/realm-core/pull/3828.
tgoyne
on 21 Jul 2020
still happening on latest realm 5.3.3....
Crashed: NSOperationQueue 0x137035a80 (QOS: USER_INITIATED)
0 Realm 0x102431f2c realm::util::EncryptedFileMapping::read_barrier(void const*, unsigned long, unsigned long (*)(char const*)) + 32
1 Realm 0x1021228e8 realm::util::do_encryption_read_barrier(void const*, unsigned long, unsigned long (*)(char const*), realm::util::EncryptedFileMapping*) + 8068
2 Realm 0x1023d18e4 realm::StringData realm::ConstObj::_get<realm::StringData>(realm::ColKey::Idx) const + 408
3 Realm 0x102169720 invocation function for block in objc_object* (anonymous namespace)::makeBoxedGetter<realm::StringData>(unsigned long) + 5292
4 MeSeems 0x100d9c428 specialized RealmQuestionRepository.findQuestions(_:) + 36 (QuestionRealmMapper.swift:36)
5 MeSeems 0x100d9b280 closure #1 in RealmQuestionRepository.findQuestions(_:) + 4376900224 (<compiler-generated>:4376900224)
6 RxSwift 0x102872acc AnonymousObservableSink.run(_:) + 60 (Create.swift:60)
7 RxSwift 0x102872cf0 AnonymousObservable.run<A>(_:cancel:) + 76 (Create.swift:76)
8 RxSwift 0x10289f990 closure #1 in Producer.subscribe<A>(_:) + 26 (Producer.swift:26)
9 RxSwift 0x102873164 specialized CurrentThreadScheduler.schedule<A>(_:action:) + 4404998500 (<compiler-generated>:4404998500)
10 RxSwift 0x10289f578 Producer.subscribe<A>(_:) + 24 (Producer.swift:24)
11 RxSwift 0x1028964d4 protocol witness for ObservableType.subscribe<A>(_:) in conformance Observable<A> + 4405142740 (<compiler-generated>:4405142740)
12 RxSwift 0x1028bcd54 closure #1 in SubscribeOnSink.run() + 59 (SubscribeOn.swift:59)
13 RxSwift 0x1028c16d4 thunk for @escaping @callee_guaranteed () -> (@out Disposable) + 4405319380 (<compiler-generated>:4405319380)
14 RxSwift 0x10289a06c closure #1 in OperationQueueScheduler.schedule<A>(_:action:) + 46 (OperationQueueScheduler.swift:46)
15 RxSwift 0x102872510 thunk for @escaping @callee_guaranteed () -> () + 4404995344 (<compiler-generated>:4404995344)
16 Foundation 0x1b98d43f0 __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 16
17 Foundation 0x1b97df710 -[NSBlockOperation main] + 84
18 Foundation 0x1b98d664c __NSOPERATION_IS_INVOKING_MAIN__ + 20
19 Foundation 0x1b97df414 -[NSOperation start] + 740
20 Foundation 0x1b98d7044 __NSOPERATIONQUEUE_IS_STARTING_AN_OPERATION__ + 20
21 Foundation 0x1b98d6b10 __NSOQSchedule_f + 180
22 libdispatch.dylib 0x1b91d29a8 _dispatch_call_block_and_release + 24
23 libdispatch.dylib 0x1b91d3524 _dispatch_client_callout + 16
24 libdispatch.dylib 0x1b917be98 _dispatch_continuation_pop$VARIANT$mp + 412
25 libdispatch.dylib 0x1b917b5ec _dispatch_async_redirect_invoke + 656
26 libdispatch.dylib 0x1b9188438 _dispatch_root_queue_drain + 376
27 libdispatch.dylib 0x1b9188bf8 _dispatch_worker_thread2 + 124
28 libsystem_pthread.dylib 0x1b9224b38 _pthread_wqthread + 212
29 libsystem_pthread.dylib 0x1b9227740 start_wqthread + 8
marcosmko
on 14 Aug 2020
i encountered crash when there is a high traffic at receive data messages (chat application) by multiple user.
Is it the same issue for this?
BACKGROUND THREAD 15 - CRASHED
Realm
realm::util::EncryptedFileMapping::read_barrier(void const*, unsigned long, unsigned long (*)(char const*))
Realm
realm::util::do_encryption_read_barrier(void const*, unsigned long, unsigned long (*)(char const*), realm::util::EncryptedFileMapping*)
Realm
realm::ArrayIntNull::init_from_ref(unsigned long)
Realm
realm::ArrayTimestamp::init_from_mem(realm::MemRef)
Realm
realm::Timestamp realm::ConstObj::_get<realm::Timestamp>(realm::ColKey::Idx) const
Realm
realm::ConstObj::get_any(realm::ColKey) const
Realm
realm::BaseDescriptor::Sorter::cache_first_column(realm::BaseDescriptor::IndexPairs&)
Realm
realm::ObjList::do_sort(realm::DescriptorOrdering const&)
Realm
realm::ConstTableView::do_sync()
Realm
realm::_impl::ResultsNotifier::run() results_notifier.cpp:159
Realm
realm::_impl::RealmCoordinator::run_async_notifiers()
Realm
realm::_impl::RealmCoordinator::on_change()
Realm
realm::_impl::ExternalCommitHelper::listen()
Realm
std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >(void*, void*)
libsystem_pthread.dylib
_pthread_start
libsystem_pthread.dylib
thread_start
And how to solve this?
calvinsug
on 25 Aug 2020
Related issues
mowens
路
3Comments
jpsim
路
3Comments
jpsim
路
3Comments
carvalho-oak
路
3Comments
matteodanelli
路
3Comments