Sectioned results crash - Invalid Address

[PhilippeWeidmann]

How frequently does the bug occur?

Sometimes

Description

I recently migrated our code to use sectioned results (https://github.com/Infomaniak/ios-kMail/pull/1037/files#diff-c43bb011c6baa01d7daa6630b1cb91c05ed05a927e7529ab3895b63896083ba3R47)

It worked fine while implementing and testing. However some users in our public beta encountered crashes that were discovered using Sentry.

The error is the following:

EXC_BAD_ACCESS
Exception 1, Code 1, Subcode 88 >
KERN_INVALID_ADDRESS at 0x58.

Stacktrace & log output

sectioned_results.cpp:124:

 for (size_t i = m_change.modifications.size(); i > 0; --i) {
            auto& indexes_old = m_change.modifications[i - 1];
            auto key = m_sectioned_results.m_previous_index_to_key[i - 1]; // <- Offending line
            auto it = m_sectioned_results.m_current_key_to_index.find(key); 
            if (it == m_sectioned_results.m_current_key_to_index.end()) {
                // Section was removed due to all of the rows being moved to
                // other sections. No need to report the individual rows as deleted.
                indexes_old.clear();

Can you reproduce the bug?

No

Reproduction Steps

I cannot reproduce it on a local device but the issue affected 3 different users.

Version

10.43

What Atlas Services are you using?

Local Database only

Are you using encryption?

No

Platform OS and version(s)

iOS 17.03

Build environment

No response

[fuermosi777]

Same here. Had to remove SectionedResults from the codebase as a temp workaround.

[sipersso]

I am getting the same results here.

# Crashlytics - Stack trace
# Application: my app
# Platform: apple
# Version: 8.3.8 (1111)
# Issue: 539a34c15fc00a062e2200d4046aac35
# Session: b13d5fad3bb24e49bd87e2a67d88fd6e_DNE_0_v2
# Date: Wed Jan 17 2024 10:24:11 GMT+0100 (centraleuropeisk normaltid)

Crashed: com.apple.main-thread
0  MyApp                       0x5845bc realm::SectionedResultsNotificationHandler::operator()(realm::CollectionChangeSet const&) + 124 (sectioned_results.cpp:124)
1  MyApp                       0x542830 realm::_impl::CollectionNotifier::after_advance() + 744 (shared_ptr.h:744)
2  MyApp                       0x54fc44 realm::_impl::RealmCoordinator::advance_to_ready(realm::Realm&) + 101 (wrap_iter.h:101)
3  MyApp                       0x590b80 realm::Realm::notify() + 843 (shared_ptr.h:843)
4  MyApp                       0x55ac94 realm::util::UniqueFunction<void ()>::SpecificImpl<realm::_impl::WeakRealmNotifier::notify()::$_0>::call() + 156 (shared_ptr.h:156)
5  MyApp                       0x5e419c realm::util::InvocationQueue::invoke_all() + 101 (wrap_iter.h:101)
6  CoreFoundation                 0x3712c __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
7  CoreFoundation                 0x363a8 __CFRunLoopDoSource0 + 176
8  CoreFoundation                 0x34b5c __CFRunLoopDoSources0 + 244
9  CoreFoundation                 0x33898 __CFRunLoopRun + 828
10 CoreFoundation                 0x33478 CFRunLoopRunSpecific + 608
11 GraphicsServices               0x34f8 GSEventRunModal + 164
12 UIKitCore                      0x22c62c -[UIApplication _run] + 888
13 UIKitCore                      0x22bc68 UIApplicationMain + 340
14 MyApp                       0x4158 main + 16 (main.swift:16)
15 ???                            0x1c9ac2dcc (Missing)

Realm notification listener
0  libsystem_kernel.dylib         0xef0c kevent + 8
1  MyApp                       0x539130 realm::_impl::ExternalCommitHelper::listen() + 220 (external_commit_helper.cpp:220)
2  MyApp                       0x5392b4 void* std::__1::__thread_proxy[abi:v160006]<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&, realm::RealmConfig const&)::$_0>>(void*) + 301 (thread:301)
3  libsystem_pthread.dylib        0x24d4 _pthread_start + 136
4  libsystem_pthread.dylib        0x1a10 thread_start + 8

Thread
0  libsystem_kernel.dylib         0x1b1c __psynch_cvwait + 8
1  libsystem_pthread.dylib        0xfd4 _pthread_cond_wait + 1228
2  libc++.1.dylib                 0x12ecc std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&) + 28
3  MyApp                       0x4b7d10 realm::DB::AsyncCommitHelper::main() + 2025 (db.cpp:2025)
4  MyApp                       0x4bbcf4 void* std::__1::__thread_proxy[abi:v160006]<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct>>, realm::DB::AsyncCommitHelper::start_thread()::'lambda'()>>(void*) + 263 (unique_ptr.h:263)
5  libsystem_pthread.dylib        0x24d4 _pthread_start + 136
6  libsystem_pthread.dylib        0x1a10 thread_start + 8

[sipersso]

Just as the others in this thread I removed sectionedresults due to crashes.

[nicola-cab]

@tgoyne any idea why this could be happening, it seems we have one BG thread that is asynchronously committing something and the main thread when is notified crashes

[sync-by-unito[bot]]

➤ jedelbo commented:

I am sorry, but investigating this cannot be prioritized at the moment.