Realm shouldn't crash when filtering results
Realm shouldn't crash when filtering results
Realm crashes for some users
Crashed: Realm notification listener
0 App 0x101534478 realm::StringNode
1 App 0x10153283c realm::StringNodeEqualBase::find_first_local(unsigned long, unsigned long) + 386140
2 App 0x101532658 realm::ParentNode::aggregate_local(realm::QueryStateBase, unsigned long, unsigned long, unsigned long, realm::ArrayPayload) + 385656
3 App 0x1014e0470 realm::Query::aggregate_internal(realm::ParentNode, realm::QueryStateBase, unsigned long, unsigned long, realm::ArrayPayload) const + 49296
4 App 0x1014e4c18 realm::util::FunctionRef
5 App 0x1014e0c20 realm::Query::find_all(realm::ConstTableView&, unsigned long, unsigned long, unsigned long) const + 51264
6 App 0x10155e04c realm::ConstTableView::do_sync() + 40800
7 App 0x1012fd390 realm::_impl::ResultsNotifier::run() + 4313207696
8 App 0x1012f742c realm::_impl::RealmCoordinator::run_async_notifiers() + 4313183276
9 App 0x1012f6da8 realm::_impl::RealmCoordinator::on_change() + 4313181608
10 App 0x1012e4224 realm::_impl::ExternalCommitHelper::listen() + 4313104932
11 App 0x1012e4d60 void std::__1::__thread_proxy
12 libsystem_pthread.dylib 0x1aa8a3914 _pthread_start + 168
13 libsystem_pthread.dylib 0x1aa8ab9d4 thread_start + 8
An example filtering predicates that caused a crash for a user:
(type ==[c] "todo" AND meta == "") AND (tags CONTAINS[c] "tag_111_fe0000")
All the properties involved are indexed properties:
override public class func indexedProperties() -> [String] {
return ["date", "meta", "type", "tags", "repeatRule"]
}
Realm framework version: Realm 5.4.7 but using core 6.1.4 because it fixed some issues related to case insensitive search
Realm Object Server version: NA
Xcode version: 12.0.1
iOS/OSX version: 13.7 & 14.0+
Dependency manager + version: SPM
cc @jedelbo as https://github.com/realm/realm-core/pull/3962 fixed other indexed property's case insensitive search crashes
ping @jedelbo @tgoyne any insights in this? It's causing lots of crashes for affected users, although the percentage of affected users is low
This looks like using a null pointer, but I have not been able to figure out how that could be possible given the location where it happens. Tried to make a test case using the query string like the one given above, but I have not been able to make it crash.
@jedelbo The crash happens because get_key(0) is trying to get the first element of m_index_matches which is an empty array in query_engine.hpp.

Thank you for this information. I will have another look, now that we know in more detail what the problem is. The screenshot suggests that you are able to reproduce the issue using a debugger. Is this the case?
Yes, I was able to reproduce this issue using a debugger. I think the issue can be fixed by checking the boundary of m_index_matches before calling get_key(ndx).
Found the bug.
@happylance yes, there is definitely a check missing.
Thanks @happylance for helping identifying the bug and @jedelbo for fixing it - please let me know when the fix is released!
Most helpful comment
@happylance yes, there is definitely a check missing.