objectbox
When you open and close the store several times in a row, the app is crashing constantly
I have 2 flutter apps and I share a database between them using the IOS app groups container, my 2 flutter apps can run simultaneously on the same device and when I add an entity on app A and then go to app B, the newly added entity is displayed in app B. So, there are 2 apps and 2 stores that are open and contribute to the same database. When I add an entity in app A and then go to app B and try to add something there, it updates the entity which I added in app A instead of adding a new entity. I think this happens because 2 stores keep track of ids internally and they don't rely on database source, so, when I have the latest id of 7 and add a new entity with the id of 8, in the app where I added everything is alright since the store has the latest id, but when I go to another app there is still id of 7 and when I put new entity it puts it with the id of 8 and since id of 8 exists already, instead of creating a new entity with the id of 9, it updates the entity with the id of 8.
In order to fix this issue, I came up with a workaround. Every time a user switch between apps I close the old store and open a new store, this allows the new store to fetch the latest id from the database source. But I noticed when I do a lot of switches back and forth like 2 or 3, the emulator is crashing without an error and it's pretty much constant behavior, you just need to do enough of closing and opening in order to cause a crash of the app.
So, my questions are, is this a bug, and how to fix it, what workarounds do you have?
My primary goal is to share the database between 2 flutter apps in the runtime. Store.attach() won't help here since they are running in separate Dart VMs.
I'm using the latest version of objectbox (1.6.0) and flutter 3.0.5
And this can be somehow similar to this issue https://github.com/objectbox/objectbox-dart/issues/385, the only difference here is I don't have an error and I'm not trying to swap data.mdb, I just work with the same database from 2 flutter apps using a separate store in each of them.
I started to use self-assignable ids and this allows me to not close stores and have them open, so crash related to close-open is kind of resolved. But when 2 apps are in production, they crash on the first switch. When I go from App A to App B, App A is crashed. I don't close and reopen stores, I just switch from one app to another.
When I'm running the app on the real device in debug mode there is no crash, the same goes. for emulator. There is also some weird blinking at the start of the app open when I switch between them.
This is the crash report
Incident Identifier: BDBD02CD-D172-44F0-897C-900CD33EE18E
Hardware Model: iPhone12,5
Process: Runner [6635]
Path: /private/var/containers/Bundle/Application/DD120F5B-60AC-4630-B96E-02C0AFC0FA7A/Runner.app/Runner
Identifier: com.example.app
Version: 1.0.0 (1)
AppStoreTools: 13F100
AppVariant: 1:iPhone12,5:15
Beta: YES
Code Type: ARM-64 (Native)
Role: unknown
Parent Process: launchd [1]
Coalition: com.example.app [1269]
Date/Time: 2022-08-11 09:59:43.8971 -0700
Launch Time: 2022-08-11 09:59:40.9550 -0700
OS Version: iPhone OS 15.6 (19G71)
Release Type: User
Baseband Version: 3.04.01
Report Version: 104
Exception Type: EXC_CRASH (SIGKILL)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Termination Reason: RUNNINGBOARD 3735883980
Triggered by Thread: 0
Thread 0 name:
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x00000002002194a0 mach_msg_trap + 8
1 libsystem_kernel.dylib 0x0000000200219ae4 mach_msg + 76 (mach_msg.c:119)
2 CoreFoundation 0x00000001c86ead30 __CFRunLoopServiceMachPort + 372 (CFRunLoop.c:2646)
3 CoreFoundation 0x00000001c86ef1bc __CFRunLoopRun + 1180 (CFRunLoop.c:3000)
4 CoreFoundation 0x00000001c8702bc8 CFRunLoopRunSpecific + 600 (CFRunLoop.c:3268)
5 GraphicsServices 0x00000001e486d374 GSEventRunModal + 164 (GSEvent.c:2200)
6 UIKitCore 0x00000001cb076b58 -[UIApplication _run] + 1100 (UIApplication.m:3511)
7 UIKitCore 0x00000001cadf8090 UIApplicationMain + 364 (UIApplication.m:5064)
8 Runner 0x0000000100eab250 main + 64 (AppDelegate.swift:5)
9 dyld 0x0000000100f55da4 start + 520 (dyldMain.cpp:879)
Thread 1:
0 libsystem_pthread.dylib 0x0000000239938e54 start_wqthread + 0
Thread 2:
0 libsystem_pthread.dylib 0x0000000239938e54 start_wqthread + 0
Thread 3:
0 libsystem_pthread.dylib 0x0000000239938e54 start_wqthread + 0
Thread 4 name:
Thread 4:
0 libsystem_kernel.dylib 0x00000002002194a0 mach_msg_trap + 8
1 libsystem_kernel.dylib 0x0000000200219ae4 mach_msg + 76 (mach_msg.c:119)
2 CoreFoundation 0x00000001c86ead30 __CFRunLoopServiceMachPort + 372 (CFRunLoop.c:2646)
3 CoreFoundation 0x00000001c86ef1bc __CFRunLoopRun + 1180 (CFRunLoop.c:3000)
4 CoreFoundation 0x00000001c8702bc8 CFRunLoopRunSpecific + 600 (CFRunLoop.c:3268)
5 Foundation 0x00000001c9ef5444 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 236 (NSRunLoop.m:373)
6 Foundation 0x00000001c9f36e0c -[NSRunLoop(NSRunLoop) runUntilDate:] + 92 (NSRunLoop.m:420)
7 UIKitCore 0x00000001caff0cc4 -[UIEventFetcher threadMain] + 524 (UIEventFetcher.m:1167)
8 Foundation 0x00000001c9f4541c __NSThread__start__ + 808 (NSThread.m:972)
9 libsystem_pthread.dylib 0x00000002399399ac _pthread_start + 148 (pthread.c:891)
10 libsystem_pthread.dylib 0x0000000239938e68 thread_start + 8
Thread 5:
0 libsystem_pthread.dylib 0x0000000239938e54 start_wqthread + 0
Thread 6:
0 libsystem_pthread.dylib 0x0000000239938e54 start_wqthread + 0
Thread 7 name:
Thread 7:
0 libsystem_kernel.dylib 0x00000002002194a0 mach_msg_trap + 8
1 libsystem_kernel.dylib 0x0000000200219ae4 mach_msg + 76 (mach_msg.c:119)
2 CoreFoundation 0x00000001c86ead30 __CFRunLoopServiceMachPort + 372 (CFRunLoop.c:2646)
3 CoreFoundation 0x00000001c86ef1bc __CFRunLoopRun + 1180 (CFRunLoop.c:3000)
4 CoreFoundation 0x00000001c8702bc8 CFRunLoopRunSpecific + 600 (CFRunLoop.c:3268)
5 Flutter 0x000000010160ca18 0x101304000 + 3181080
6 Flutter 0x000000010160c3fc 0x101304000 + 3179516
7 libsystem_pthread.dylib 0x00000002399399ac _pthread_start + 148 (pthread.c:891)
8 libsystem_pthread.dylib 0x0000000239938e68 thread_start + 8
Thread 8 name:
Thread 8:
0 libsystem_kernel.dylib 0x00000002002194a0 mach_msg_trap + 8
1 libsystem_kernel.dylib 0x0000000200219ae4 mach_msg + 76 (mach_msg.c:119)
2 CoreFoundation 0x00000001c86ead30 __CFRunLoopServiceMachPort + 372 (CFRunLoop.c:2646)
3 CoreFoundation 0x00000001c86ef1bc __CFRunLoopRun + 1180 (CFRunLoop.c:3000)
4 CoreFoundation 0x00000001c8702bc8 CFRunLoopRunSpecific + 600 (CFRunLoop.c:3268)
5 Flutter 0x000000010160ca18 0x101304000 + 3181080
6 Flutter 0x000000010160c3fc 0x101304000 + 3179516
7 libsystem_pthread.dylib 0x00000002399399ac _pthread_start + 148 (pthread.c:891)
8 libsystem_pthread.dylib 0x0000000239938e68 thread_start + 8
Thread 9 name:
Thread 9:
0 libsystem_kernel.dylib 0x00000002002194a0 mach_msg_trap + 8
1 libsystem_kernel.dylib 0x0000000200219ae4 mach_msg + 76 (mach_msg.c:119)
2 CoreFoundation 0x00000001c86ead30 __CFRunLoopServiceMachPort + 372 (CFRunLoop.c:2646)
3 CoreFoundation 0x00000001c86ef1bc __CFRunLoopRun + 1180 (CFRunLoop.c:3000)
4 CoreFoundation 0x00000001c8702bc8 CFRunLoopRunSpecific + 600 (CFRunLoop.c:3268)
5 Flutter 0x000000010160ca18 0x101304000 + 3181080
6 Flutter 0x000000010160c3fc 0x101304000 + 3179516
7 libsystem_pthread.dylib 0x00000002399399ac _pthread_start + 148 (pthread.c:891)
8 libsystem_pthread.dylib 0x0000000239938e68 thread_start + 8
Thread 10 name:
Thread 10:
0 libsystem_kernel.dylib 0x0000000200219f24 __psynch_cvwait + 8
1 libsystem_pthread.dylib 0x0000000239940298 _pthread_cond_wait + 1236 (pthread_cond.c:636)
2 libc++.1.dylib 0x00000001e154c28c std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&) + 28 (__threading_support:380)
3 Flutter 0x00000001016071e4 0x101304000 + 3158500
4 libsystem_pthread.dylib 0x00000002399399ac _pthread_start + 148 (pthread.c:891)
5 libsystem_pthread.dylib 0x0000000239938e68 thread_start + 8
Thread 11 name:
Thread 11:
0 libsystem_kernel.dylib 0x0000000200219f24 __psynch_cvwait + 8
1 libsystem_pthread.dylib 0x0000000239940298 _pthread_cond_wait + 1236 (pthread_cond.c:636)
2 libc++.1.dylib 0x00000001e154c28c std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&) + 28 (__threading_support:380)
3 Flutter 0x00000001016071e4 0x101304000 + 3158500
4 libsystem_pthread.dylib 0x00000002399399ac _pthread_start + 148 (pthread.c:891)
5 libsystem_pthread.dylib 0x0000000239938e68 thread_start + 8
Thread 12 name:
Thread 12:
0 libsystem_kernel.dylib 0x0000000200219f24 __psynch_cvwait + 8
1 libsystem_pthread.dylib 0x0000000239940298 _pthread_cond_wait + 1236 (pthread_cond.c:636)
2 libc++.1.dylib 0x00000001e154c28c std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&) + 28 (__threading_support:380)
3 Flutter 0x00000001016071e4 0x101304000 + 3158500
4 libsystem_pthread.dylib 0x00000002399399ac _pthread_start + 148 (pthread.c:891)
5 libsystem_pthread.dylib 0x0000000239938e68 thread_start + 8
Thread 13 name:
Thread 13:
0 libsystem_kernel.dylib 0x0000000200219f24 __psynch_cvwait + 8
1 libsystem_pthread.dylib 0x0000000239940298 _pthread_cond_wait + 1236 (pthread_cond.c:636)
2 libc++.1.dylib 0x00000001e154c28c std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&) + 28 (__threading_support:380)
3 Flutter 0x00000001016071e4 0x101304000 + 3158500
4 libsystem_pthread.dylib 0x00000002399399ac _pthread_start + 148 (pthread.c:891)
5 libsystem_pthread.dylib 0x0000000239938e68 thread_start + 8
Thread 14 name:
Thread 14:
0 libsystem_kernel.dylib 0x0000000200219f24 __psynch_cvwait + 8
1 libsystem_pthread.dylib 0x0000000239940298 _pthread_cond_wait + 1236 (pthread_cond.c:636)
2 libc++.1.dylib 0x00000001e154c28c std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&) + 28 (__threading_support:380)
3 Flutter 0x00000001016071e4 0x101304000 + 3158500
4 libsystem_pthread.dylib 0x00000002399399ac _pthread_start + 148 (pthread.c:891)
5 libsystem_pthread.dylib 0x0000000239938e68 thread_start + 8
Thread 15 name:
Thread 15:
0 libsystem_kernel.dylib 0x0000000200219f24 __psynch_cvwait + 8
1 libsystem_pthread.dylib 0x0000000239940298 _pthread_cond_wait + 1236 (pthread_cond.c:636)
2 libc++.1.dylib 0x00000001e154c28c std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&) + 28 (__threading_support:380)
3 Flutter 0x00000001016071e4 0x101304000 + 3158500
4 libsystem_pthread.dylib 0x00000002399399ac _pthread_start + 148 (pthread.c:891)
5 libsystem_pthread.dylib 0x0000000239938e68 thread_start + 8
Thread 16 name:
Thread 16:
0 libsystem_kernel.dylib 0x000000020021ae18 kevent + 8
1 Flutter 0x00000001017f0bc4 0x101304000 + 5163972
2 Flutter 0x000000010181f4e0 0x101304000 + 5354720
3 libsystem_pthread.dylib 0x00000002399399ac _pthread_start + 148 (pthread.c:891)
4 libsystem_pthread.dylib 0x0000000239938e68 thread_start + 8
Thread 17 name:
Thread 17:
0 libsystem_kernel.dylib 0x0000000200219f24 __psynch_cvwait + 8
1 libsystem_pthread.dylib 0x00000002399402c4 _pthread_cond_wait + 1280 (pthread_cond.c:640)
2 Flutter 0x0000000101915bd8 0x101304000 + 6364120
3 Flutter 0x0000000101955f5c 0x101304000 + 6627164
4 Flutter 0x0000000101915500 0x101304000 + 6362368
5 libsystem_pthread.dylib 0x00000002399399ac _pthread_start + 148 (pthread.c:891)
6 libsystem_pthread.dylib 0x0000000239938e68 thread_start + 8
Thread 0 crashed with ARM Thread State (64-bit):
x0: 0x0000000010004005 x1: 0x0000000007000806 x2: 0x0000000000000000 x3: 0x0000000000000c00
x4: 0x0000000000002303 x5: 0x00000000ffffffff x6: 0x0000000000000000 x7: 0x000000028209c0d0
x8: 0x00000000fffffbbf x9: 0x0000000007000906 x10: 0xc6658452b28600da x11: 0x000000b2f4b67944
x12: 0x000000000015329f x13: 0x00000000016e3600 x14: 0x0000000000000000 x15: 0x0000000000000000
x16: 0xffffffffffffffe1 x17: 0x0000000000000002 x18: 0x0000000000000000 x19: 0x0000000000000000
x20: 0x00000000ffffffff x21: 0x0000000000002303 x22: 0x0000000000000c00 x23: 0x000000016ef5aae0
x24: 0x0000000007000806 x25: 0x0000000000000000 x26: 0x0000000007000806 x27: 0x0000000000002303
x28: 0x0000000000002303 fp: 0x000000016ef5a960 lr: 0x0000000200219ae4
sp: 0x000000016ef5a910 pc: 0x00000002002194a0 cpsr: 0x60000000
esr: 0x56000080 Address size fault
Binary Images:
0x100ea4000 - 0x100eabfff Runner arm64 <efe921d6ddd33a208f90afa8dbd37d01> /private/var/containers/Bundle/Application/DD120F5B-60AC-4630-B96E-02C0AFC0FA7A/Runner.app/Runner
0x100f3c000 - 0x100f93fff dyld arm64e <66e1fb2668f8379ba052eb8b8291b5e1> /usr/lib/dyld
0x101304000 - 0x101abffff Flutter arm64 <b5f419596300357c85f161f5e6e0920d> /private/var/containers/Bundle/Application/DD120F5B-60AC-4630-B96E-02C0AFC0FA7A/Runner.app/Frameworks/Flutter.framework/Flutter
0x1c86e4000 - 0x1c8b39fff CoreFoundation arm64e <6b22dd8135853be6bc77ba19810ec0f2> /System/Library/Frameworks/CoreFoundation.framework/CoreFoundation
0x1c9edc000 - 0x1ca1e6fff Foundation arm64e <ee1abaf23d7137fb906715aa79528619> /System/Library/Frameworks/Foundation.framework/Foundation
0x1cab62000 - 0x1cc3fffff UIKitCore arm64e <137a95aada6d332cbc01e13bb9b6e317> /System/Library/PrivateFrameworks/UIKitCore.framework/UIKitCore
0x1e153f000 - 0x1e15a5fff libc++.1.dylib arm64e <17cea4f6e3933beab8971bf33851a14b> /usr/lib/libc++.1.dylib
0x1e486c000 - 0x1e4874fff GraphicsServices arm64e <a094e7b51d4037c5902756d86988ec4b> /System/Library/PrivateFrameworks/GraphicsServices.framework/GraphicsServices
0x200218000 - 0x20024dfff libsystem_kernel.dylib arm64e <9ab02ad0348c30cb99f40979c2d47515> /usr/lib/system/libsystem_kernel.dylib
0x239938000 - 0x239943fff libsystem_pthread.dylib arm64e <a8989ffb141439dca1a81534f21923fe> /usr/lib/system/libsystem_pthread.dylib
EOF
ObjectBox does not support accessing the same database file in read/write mode from two different processes, like in this case two separate apps. It would be possible to open one database in write mode and one or more others in read-only mode. However, read-only mode is only supported in our Java library at the moment.
Technically, it should be possible to close a store in one process and then open it in another one (assuming the model is the same). But that requires careful synchronization/locking to avoid concurrent access from different processes.
My recommendation is to not use shared files at all. Instead let each app have its own database in it's isolated app directory. Then provide some API for inter-process communication (on device, or via a third-party like a web server) to share anything that needs to be shared.
Edit: I don't see anything related to ObjectBox in the crash dump you submitted.
