wrap_iter crash

[abbottkilroy]

SDK and version

SDK : Swift
Version: 10.33.0

Observations

One of our top 10 crashes in Crashlytics

Crash log / stacktrace

Crashed: com.abbott.libre3.OtherEntity
0 libsystem_kernel.dylib 0x7198 __pthread_kill + 8
1 libsystem_pthread.dylib 0xd5f8 pthread_kill + 208
2 libsystem_c.dylib 0x1c4b8 abort + 124
3 libsystem_malloc.dylib 0x1d0b8 malloc_vreport + 904
4 libsystem_malloc.dylib 0x1d330 malloc_zone_error + 100
5 libsystem_malloc.dylib 0x1126c nanov2_guard_corruption_detected + 40
6 libsystem_malloc.dylib 0x107b0 nanov2_allocate_outlined + 344
7 libc++abi.dylib 0x159e0 operator new(unsigned long) + 28
8 Libre3 0x8daff4 std::__1::__tree_iterator<std::__1::__value_type<unsigned long, unsigned long>, std::__1::__tree_node<std::__1::__value_type<unsigned long, unsigned long>, void*>*, long> std::__1::__tree<std::__1::__value_type<unsigned long, unsigned long>, std::__1::__map_value_compare<unsigned long, std::__1::__value_type<unsigned long, unsigned long>, std::__1::less, true>, std::__1::allocator<std::__1::__value_type<unsigned long, unsigned long> > >::__emplace_multi<unsigned long&, unsigned long>(unsigned long&, unsigned long&&) + 235 (new:235)
9 Libre3 0x8d95f8 realm::GroupWriter::FreeList::move_free_in_file_to_size_map(std::__1::multimap<unsigned long, unsigned long, std::__1::less, std::__1::allocator<std::__1::pair<unsigned long const, unsigned long> > >&) + 171 (wrap_iter.h:171)
10 Libre3 0x8d8984 realm::GroupWriter::read_in_freelist() + 485 (vector:485)
11 Libre3 0x8d7db8 realm::GroupWriter::write_group() + 329 (group_writer.cpp:329)
12 Libre3 0x8c3688 realm::DB::low_level_commit(unsigned long long, realm::Transaction&, bool) + 2269 (db.cpp:2269)
13 Libre3 0x8c34d0 realm::DB::do_commit(realm::Transaction&, bool) + 448 (replication.hpp:448)
14 Libre3 0xae5124 realm::Transaction::commit_and_continue_as_read(bool) + 209 (transaction.cpp:209)
15 Libre3 0x9534d8 realm::impl::RealmCoordinator::commit_write(realm::Realm&, bool) + 730 (realm_coordinator.cpp:730)
16 Libre3 0x9b5b84 realm::Realm::commit_transaction() + 997 (shared_realm.cpp:997)
17 Libre3 0x85941c -[RLMRealm commitWriteTransactionWithoutNotifying:error:] + 750 (RLMRealm.mm:750)
18 Libre3 0xe35f84 Realm.write(withoutNotifying::) + 322 (Realm.swift:322)
19 Libre3 0x309234 closure #1 in Realm.safeWrite(type::) + 4341961268
20 Libre3 0x3091a0 closure #3 in Realm.safeWrite(type::) + 4341961120
21 Libre3 0x511ce8 closure #3 in Realm.safeWrite(type:_:)partial apply + 4344093928
22 libswiftDispatch.dylib 0x1a8c partial apply for thunk for @callee_guaranteed () -> (@out A, @error @owned Error) + 20
23 libswiftDispatch.dylib 0x1aa4 thunk for @callee_guaranteed () -> (@out A, @error @owned Error)partial apply + 12
24 libswiftDispatch.dylib 0x29d0 closure #1 in closure #1 in OS_dispatch_queue._syncHelper(fn:execute:rescue:) + 120
25 libswiftDispatch.dylib 0x2a98 partial apply for thunk for @callee_guaranteed () -> () + 20
26 libswiftDispatch.dylib 0x26c0 thunk for @escaping @callee_guaranteed () -> () + 20
27 libdispatch.dylib 0x64780 dispatch_client_callout + 16
28 libdispatch.dylib 0x46a50 dispatch_lane_barrier_sync_invoke_and_complete + 52
29 libswiftDispatch.dylib 0x2084 implicit closure #2 in implicit closure #1 in OS_dispatch_queue.sync(execute:) + 152
30 libswiftDispatch.dylib 0x1460 partial apply for implicit closure #2 in implicit closure #1 in OS_dispatch_queue.sync(execute:) + 40
31 libswiftDispatch.dylib 0x1dfc OS_dispatch_queue.syncHelper(fn:execute:rescue:) + 252
32 libswiftDispatch.dylib 0x14f0 OS_dispatch_queue.sync(execute:) + 136
33 Libre3 0x510a98 specialized SensorEntityManager.update(currentLifeCount:historicLifeCount:) + 295 (RealmDatabase.swift:295)
34 Libre3 0xae998 closure #2 in DatabaseListener.subscribeForCGMRecord() + 45 (WorkFlowManager.swift:45)
35 Libre3 0x100f38 thunk for @escaping @callee_guaranteed (@guaranteed NSObject) -> ()partial apply + 4339830584
36 Combine 0x8490 Subscribers.Sink.receive(:) + 88
37 Combine 0x80a0 protocol witness for Subscriber.receive(:) in conformance Subscribers.Sink<A, B> + 20
38 Combine 0xd490 closure #1 in Publishers.ReceiveOn.Inner.receive(:) + 192
39 libswiftDispatch.dylib 0x1380 thunk for @escaping @callee_guaranteed () -> () + 28
40 libdispatch.dylib 0x637a8 _dispatch_call_block_and_release + 24
41 libdispatch.dylib 0x64780 _dispatch_client_callout + 16
42 libdispatch.dylib 0x3f6fc _dispatch_lane_serial_drain$VARIANT$armv81 + 600
43 libdispatch.dylib 0x401b0 _dispatch_lane_invoke$VARIANT$armv81 + 380
44 libdispatch.dylib 0x49f14 _dispatch_workloop_worker_thread + 608
45 libsystem_pthread.dylib 0x1bd0 _pthread_wqthread + 284
46 libsystem_pthread.dylib 0x1720 start_wqthread + 8

Steps & Code to Reproduce

This is our Libre3 app. The method in question is:

func update(currentLifeCount: Int32, historicLifeCount: Int32) -> Bool {
    guard let sensor = getActiveSensor() else { return false }
    
    do {
        try RealmDatabase.shared.realm.safeWrite(type: .otherEntity) {
            sensor.currentLifeCount = currentLifeCount
            sensor.lastHistoricReading = historicLifeCount
        }
        return true
    } catch {
        return false
    }
}

[kiburtse]

Hi! As with your other reported issue #7188, the best way forward is to upgrade realm swift sdk for your app to the latest version. Most likely it would go away.

This stacktrace we haven't yet seen, but it is similar to other reported issues fixed by #6962.

Although, this one crashes in a std::multimap itself on freelist manupulation. This is weird. @finnschiermer @jedelbo could it be still the same issue?

[finnschiermer]

@kiburtse In operator new in multimap? It doesn't look like anything we've seen before. Ever.

[kiburtse]

@finnschiermer i suspect that "nanov2_guard_corruption_detected" simply suggests internal malloc's heap corruption. It's hard to imagine that there is a bug, but who knows, of course. The question i had in mind, if our double free in freelist issue was possible responsible for memory corruption, since in the stacktrace the failure happens a bit earlier in GroupWriter::write_group than any assertion we have seen so far.

Anyway, i don't think we can meaningfully investigate this without some reproducer. @abbottkilroy please, try to update your app with recent realm swift sdk and check if the problem will go away. Otherwise, we would need a reproducer for this.

[github-actions]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.