leemaguire
commented
4 years ago 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
Closed tristangrichard closed 3 years ago
leemaguire
commented
4 years ago 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
tristangrichard
commented
4 years ago 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
}
}
}
YuryRadchenko
commented
4 years ago Did you change something? I have the same crash in my app too :( Realm (5.0.1)
zapsleep
commented
4 years ago I started having this too after transition from 4.4.1 -> 5.0.2
pkrmf
commented
4 years ago 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
commented
4 years ago 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.
cashwalk-bzjoowan
commented
4 years ago any update in this crash? i have same issue, using with realm-cocoa "v.5.2.0"
nalexn
commented
4 years ago 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 + 8Crashed: 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)
gioramixin
commented
4 years ago 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
ejm01
commented
4 years ago @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.
Limoo
commented
4 years ago 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)
sailor002
commented
4 years ago Any updates? Having the same issue in production. All of them seem to be on iOS 13 currently.
M0rtyMerr
commented
4 years ago Can confirm that issue
ejm01
commented
4 years ago @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.
sailor002
commented
4 years ago 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.
finnschiermer
commented
4 years ago 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.
sailor002
commented
4 years ago 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.
finnschiermer
commented
4 years ago Interesting. Thx for the description @sailor002.
finnschiermer
commented
4 years ago 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
ejm01
commented
4 years ago 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.
shuhaodo
commented
4 years ago 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
leemaguire
commented
4 years ago @shuhaodo Would you be able to give us a sandbox app that reproduces this issue?
tristangrichard
commented
4 years ago 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?
jsflax
commented
4 years ago @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.
gioramixin
commented
4 years ago 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
still happens
tristangrichard
commented
3 years ago 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.
igrechuhin
commented
3 years ago 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 + 8We 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?
finnschiermer
commented
3 years ago @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?
igrechuhin
commented
3 years ago @finnschiermer Sure, where should I send it?
finnschiermer
commented
3 years ago @igrechuhin Please send it to realm-help@mongodb.com
igrechuhin
commented
3 years ago @finnschiermer I've sent files to you. Please tell if I can assist in any way.
finnschiermer
commented
3 years ago @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
commented
3 years ago 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 ?
igrechuhin
commented
3 years ago @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.
finnschiermer
commented
3 years ago @igrechuhin We need one of my friends with deep knowledge of the cocoa SDK to step in at this point.
jsflax
commented
3 years ago @igrechuhin it appears the issue you are seeing is different than the initial reported issue. If you are still encountering the issue, please open another ticket so that we can investigate further.
zero-tolerance0
commented
1 year ago facing exact same issue, tried on realm swift versions tags 10.39.1, 10.28.1,
no more resources load into realm database after ~2.7 GB loaded.
getting again and again, autorelasepool did not fix the issue, pls help
Fatal error: 'try!' expression unexpectedly raised an error: Error Domain=io.realm
Code=9 "mmap() failed: Cannot allocate memory size: 55541760 offset: 2617245696" UserInfo={NSLocalizedDescription=mmap() failed: Cannot allocate memory size: 55541760 offset: 2617245696, Error Code=9}
Terminating app due to uncaught exception 'RLMException', reason: 'Attempted to insert null into non-nullable column Exception backtrace:
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
Realm Object Server version: ?
Xcode version: 11.2
iOS/OSX version: iOS 11, 12, 13
Dependency manager + version: Carthage 0.34.0