Multiple sync agents attempted to join the same session
molind opened this issue · comments
How frequently does the bug occur?
Sometimes
Description
Recently we've migrated from realm-java to realm-kotlin 1.16.0 and I see new kind of crashes.
Google reports it like this:
terminating with uncaught exception of type realm::MultipleSyncAgents: Multiple sync agents attempted to join the same session
I've found link to unstripped symbols, uploaded them to our sentry and now we have symbolicated version. See below. As I understand error is thrown during operation processing, but due to rethrow code we can't see exact line where original exception was thrown.
MultipleSyncAgents error means that second session tries to open database that is already sync_agent_present = true. https://github.com/realm/realm-core/blob/970c4fd89f3c9b18ffd26f075534992e2fd8fa51/src/realm/db.cpp#L2865
Could you suggest how is that could be triggered from realm-kotlin?
Stacktrace & log output
Stacktrace from google:
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 0, tid: 7805 >>> com.bodunov.galileo <<<
backtrace:
#00 pc 0x0000000000059b38 /apex/com.android.runtime/lib64/bionic/libc.so (abort+164)
#01 pc 0x0000000000aef678 /data/app/~~K5jmEVKJv42XkpX30VJ_TA==/com.bodunov.galileo-VYzAnIAl9IYd_ZIr0Yjw7g==/split_config.arm64_v8a.apk!librealmc.so (BuildId: 078c57fb26200dce4219f8a2d6c74f27511a0462)
#02 pc 0x0000000000aef864 /data/app/~~K5jmEVKJv42XkpX30VJ_TA==/com.bodunov.galileo-VYzAnIAl9IYd_ZIr0Yjw7g==/split_config.arm64_v8a.apk!librealmc.so (BuildId: 078c57fb26200dce4219f8a2d6c74f27511a0462)
#03 pc 0x0000000000aef714 /data/app/~~K5jmEVKJv42XkpX30VJ_TA==/com.bodunov.galileo-VYzAnIAl9IYd_ZIr0Yjw7g==/split_config.arm64_v8a.apk!librealmc.so (BuildId: 078c57fb26200dce4219f8a2d6c74f27511a0462)
#04 pc 0x0000000000aef028 /data/app/~~K5jmEVKJv42XkpX30VJ_TA==/com.bodunov.galileo-VYzAnIAl9IYd_ZIr0Yjw7g==/split_config.arm64_v8a.apk!librealmc.so (BuildId: 078c57fb26200dce4219f8a2d6c74f27511a0462)
#05 pc 0x00000000005fe350 /data/app/~~K5jmEVKJv42XkpX30VJ_TA==/com.bodunov.galileo-VYzAnIAl9IYd_ZIr0Yjw7g==/split_config.arm64_v8a.apk!librealmc.so (BuildId: 078c57fb26200dce4219f8a2d6c74f27511a0462)
#06 pc 0x000000000060a58c /data/app/~~K5jmEVKJv42XkpX30VJ_TA==/com.bodunov.galileo-VYzAnIAl9IYd_ZIr0Yjw7g==/split_config.arm64_v8a.apk!librealmc.so (BuildId: 078c57fb26200dce4219f8a2d6c74f27511a0462)
#07 pc 0x00000000005fd4c0 /data/app/~~K5jmEVKJv42XkpX30VJ_TA==/com.bodunov.galileo-VYzAnIAl9IYd_ZIr0Yjw7g==/split_config.arm64_v8a.apk!librealmc.so (BuildId: 078c57fb26200dce4219f8a2d6c74f27511a0462)
#08 pc 0x00000000005fed50 /data/app/~~K5jmEVKJv42XkpX30VJ_TA==/com.bodunov.galileo-VYzAnIAl9IYd_ZIr0Yjw7g==/split_config.arm64_v8a.apk!librealmc.so (BuildId: 078c57fb26200dce4219f8a2d6c74f27511a0462)
#09 pc 0x00000000000be888 /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+208)
#10 pc 0x000000000005b370 /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64)stacktrace from sentry:
OS Version: Android 12 (GM1900_11_H.41)
Report Version: 104
Exception Type: Unknown (SIGABRT)
Application Specific Information:
Abort
Thread 0 Crashed:
0 libc.so 0x7d414b99c8 abort
1 split_config.arm64_v8a.apk 0x7c20b17678 abort_message (abort_message.cpp:76)
2 split_config.arm64_v8a.apk 0x7c20b17864 demangling_terminate_handler (cxa_default_handlers.cpp:62)
3 split_config.arm64_v8a.apk 0x7c20b17714 std::__terminate (cxa_handlers.cpp:59)
4 split_config.arm64_v8a.apk 0x7c20b17028 __cxa_rethrow (cxa_exception.cpp:616)
5 split_config.arm64_v8a.apk 0x7c20626350 realm::sync::network::Service::PostOper<T>::recycle_and_execute (network.hpp:2025)
6 split_config.arm64_v8a.apk 0x7c2063258c [inlined] realm::sync::network::Service::Impl::execute (network.cpp:1646)
7 split_config.arm64_v8a.apk 0x7c2063258c realm::sync::network::Service::Impl::run_impl (network.cpp:1574)
8 split_config.arm64_v8a.apk 0x7c206254c0 realm::sync::websocket::DefaultSocketProvider::event_loop (default_socket.cpp:615)
9 split_config.arm64_v8a.apk 0x7c20626d50 [inlined] std::__ndk1::__invoke<T> (type_traits:3815)
10 split_config.arm64_v8a.apk 0x7c20626d50 [inlined] std::__ndk1::__thread_execute<T> (thread:273)
11 split_config.arm64_v8a.apk 0x7c20626d50 std::__ndk1::__thread_proxy<T> (thread:284)
12 libc.so 0x7d4151eb44 <unknown> + 537966799684
13 libc.so 0x7d414bb2fc <unknown> + 537966392060
EOF
### Can you reproduce the bug?
-- select --
### Reproduction Steps
Unfortunately I have to reproduction steps. I need your assistance with that.
### Version
1.16.0
### What Atlas App Services are you using?
Atlas Device Sync
### Are you using encryption?
No
### Platform OS and version(s)
Android 10 - Android 14
### Build environment
Android Studio version: Jellyfish | 2023.3.1
Android Build Tools version: 34.0.0
Gradle version: 8.6
➤ PM Bot commented:
Jira ticket: RKOTLIN-1103
Hi @molind, unfortunately, that stack trace is not enough to debug the issue.
Is this PBS or QBS?
Do you have a single Realm instance or multiple?
How many Realms does the app have?
Is there any particularity to it? Multiprocessing?
Hello @clementetb. We have only one synchronised realm. And one realm instance on server side. Now I have steps that I've seen. We've opened synced realm, closed it as soon as it opened successfully. And opened another one with the same configuration. In 1% there will be a race issue and this crash happened.
I've fixed it by changing logic of our app. Earlier in realm-java we cached configuration and created new realms for background tasks. And same approach was used in realm-kotlin. Possibly it's caused this bug.
Now we're open realm only once and use it for all tasks. Since this change the crash never happened again.
Is this a flexible query based sync realm?
No.
@nielsenko does this look like the similar issue you were looking at in dart? I'm guessing this is not hot reload related, but might still have the same cause.
Yes this smells like realm/realm-dart#1708 and realm/realm-core#7190
@molind As a workaround you can use a single Realm instance. Realm instances, in Realm-Kotlin, are thread-safe.
@clementetb we do already. This crash never happened since we changed that.
Just to confirm, using a single Realm instance works?
Instantiating a single Realm instance is the preferred method as Realm instances are resource instensive.
@clementetb yes. We open one realm and use it for all tasks UI and background. It works great.