Uploaded image for project: 'Realm .NET SDK'
  1. Realm .NET SDK
  2. RNET-209

Realm crash on different configurations write-transactions on same thread

XMLWordPrintableJSON

      <!--- Questions: If you have questions about how to use Realm, please ask on -->
      <!--- StackOverflow: http://stackoverflow.com/questions/ask?tags=realm -->
      <!--- We monitor the realm tag. -->

      <!--- Feature Request: Just fill in the first two sections below. -->

      <!--- Bugs: To help you as fast as possible with an issue please describe your issue -->
      <!--- and the steps you have taken to reproduce it in as much detail as possible. -->

      <Unable to render embedded object: File (--- Thanks for helping us help you) not found. -->

      Goals

      Don't crash.

      Expected Results

      Don't crash.

      Actual Results

      I have fast-executing write-transactions on two different realm configurations on a single thread.
      The batch of all write-transactions (~100) on the first realm is executed successfully. After these transactions the second realm configuration is opened and write-transactions are executed. The app immediately crashes with realm::incorrectThreadException. All objects and realm access is definitely done on the same thread. There is no async/await inside.

      terminate called after throwing an instance of 'realm::IncorrectThreadException'
  what():  Realm accessed from incorrect thread.
03-28 23:47:47.196 F/libc    ( 6876): Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 6949 (Thread Pool Wor), pid 6876 (a_express_debug)
03-28 23:47:47.001 I/chatty  ( 6876): uid=10103(net.someapp_debug) RenderThread identical 3 lines
03-28 23:47:47.017 D/EGL_emulation( 6876): eglMakeCurrent: 0x7a3e0ec956a0: ver 2 0 (tinfo 0x7a3df4522660)
03-28 23:47:47.270 I/crash_dump64( 7083): obtaining output fd from tombstoned, type: kDebuggerdTombstone
terminate called recursively
03-28 23:47:47.271 I//system/bin/tombstoned( 1682): received crash request for pid 6949
03-28 23:47:47.271 I/crash_dump64( 7083): performing dump of process 6876 (target tid = 6949)
03-28 23:47:47.277 W/monodroid-assembly( 6876): typemap: unable to find mapping to a managed type from Java type 'android/app/SharedPreferencesImpl'
03-28 23:47:47.279 W/monodroid-assembly( 6876): typemap: unable to find mapping to a managed type from Java type 'android/app/SharedPreferencesImpl$EditorImpl'
03-28 23:47:47.280 F/DEBUG   ( 7083): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
03-28 23:47:47.280 F/DEBUG   ( 7083): Build fingerprint: 'Android/sdk_phone_x86_64/generic_x86_64:10/QPP6.190730.005.B1/5775370:userdebug/test-keys'
03-28 23:47:47.280 F/DEBUG   ( 7083): Revision: '0'
03-28 23:47:47.280 F/DEBUG   ( 7083): ABI: 'x86_64'
03-28 23:47:47.281 F/DEBUG   ( 7083): Timestamp: 2020-03-28 23:47:47+0100
03-28 23:47:47.281 F/DEBUG   ( 7083): pid: 6876, tid: 6949, name: Thread Pool Wor  >>> net.someapp_debug <<<
03-28 23:47:47.281 F/DEBUG   ( 7083): uid: 10103
03-28 23:47:47.281 F/DEBUG   ( 7083): signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
03-28 23:47:47.281 F/DEBUG   ( 7083):     rax 0000000000000000  rbx 0000000000001adc  rcx 00007a3ee6c283f8  rdx 0000000000000006
03-28 23:47:47.281 F/DEBUG   ( 7083):     r8  00007a3de86b1f58  r9  0000000000000000  r10 00007a3deb2a9f70  r11 0000000000000246
03-28 23:47:47.281 F/DEBUG   ( 7083):     r12 00007a3ee6c9d470  r13 00007a3de9dcbd20  r14 00007a3deb2a9ff8  r15 0000000000001b25
03-28 23:47:47.281 F/DEBUG   ( 7083):     rdi 0000000000001adc  rsi 0000000000001b25
03-28 23:47:47.281 F/DEBUG   ( 7083):     rbp 00007a3deb2aa070  rsp 00007a3deb2a9f68  rip 00007a3ee6c283f8
03-28 23:47:47.344 F/DEBUG   ( 7083): 
03-28 23:47:47.344 F/DEBUG   ( 7083): backtrace:
03-28 23:47:47.345 F/DEBUG   ( 7083):       #00 pc 00000000000943f8  /apex/com.android.runtime/lib64/bionic/libc.so (syscall+24) (BuildId: a08a19770d6696739c847e29c3f5f650)
03-28 23:47:47.345 F/DEBUG   ( 7083):       #01 pc 0000000000097146  /apex/com.android.runtime/lib64/bionic/libc.so (abort+182) (BuildId: a08a19770d6696739c847e29c3f5f650)
03-28 23:47:47.345 F/DEBUG   ( 7083):       #02 pc 0000000000484cc4  /data/app/net.someapp_debug-7plwvyQdicPL5JxUiQ9J5w==/lib/x86_64/librealm-wrappers.so (__gnu_cxx::__verbose_terminate_handler()+372) (BuildId: 76a54fa10704520ceeba3b8301c724f9bab1594e)
03-28 23:47:47.345 F/DEBUG   ( 7083):       #03 pc 0000000000450538  /data/app/net.someapp_debug-7plwvyQdicPL5JxUiQ9J5w==/lib/x86_64/librealm-wrappers.so (__cxxabiv1::__terminate(void (*)())+8) (BuildId: 76a54fa10704520ceeba3b8301c724f9bab1594e)
03-28 23:47:47.345 F/DEBUG   ( 7083):       #04 pc 00000000004505b0  /data/app/net.someapp_debug-7plwvyQdicPL5JxUiQ9J5w==/lib/x86_64/librealm-wrappers.so (std::terminate()+16) (BuildId: 76a54fa10704520ceeba3b8301c724f9bab1594e)
03-28 23:47:47.345 F/DEBUG   ( 7083):       #05 pc 00000000004506e1  /data/app/net.someapp_debug-7plwvyQdicPL5JxUiQ9J5w==/lib/x86_64/librealm-wrappers.so (__cxa_throw+113) (BuildId: 76a54fa10704520ceeba3b8301c724f9bab1594e)
03-28 23:47:47.345 F/DEBUG   ( 7083):       #06 pc 0000000000117964  /data/app/net.someapp_debug-7plwvyQdicPL5JxUiQ9J5w==/lib/x86_64/librealm-wrappers.so (realm::Realm::verify_thread() const+100) (BuildId: 76a54fa10704520ceeba3b8301c724f9bab1594e)
03-28 23:47:47.345 F/DEBUG   ( 7083):       #07 pc 000000000011ea45  /data/app/net.someapp_debug-7plwvyQdicPL5JxUiQ9J5w==/lib/x86_64/librealm-wrappers.so (realm::Realm::notify()+53) (BuildId: 76a54fa10704520ceeba3b8301c724f9bab1594e)
03-28 23:47:47.345 F/DEBUG   ( 7083):       #08 pc 00000000001542c8  /data/app/net.someapp_debug-7plwvyQdicPL5JxUiQ9J5w==/lib/x86_64/librealm-wrappers.so (realm::_impl::WeakRealmNotifier::Callback::operator()() const+72) (BuildId: 76a54fa10704520ceeba3b8301c724f9bab1594e)
03-28 23:47:47.345 F/DEBUG   ( 7083):       #09 pc 00000000000baffd  /data/app/net.someapp_debug-7plwvyQdicPL5JxUiQ9J5w==/lib/x86_64/librealm-wrappers.so (SynchronizationContextEventLoop::handle(void*)+13) (BuildId: 76a54fa10704520ceeba3b8301c724f9bab1594e)
03-28 23:47:47.345 F/DEBUG   ( 7083):       #10 pc 00000000000b93e4  <anonymous:63c95000>

      So far there are two methods to fix this behavior:
      1.) Running the second write-transaction batch on a new thread รก la Task.Run(ExecuteSecondBatch);
      2.) Delaying the second batch using await Task.Delay(TimeSpan.FromMilliseconds(500));

      It also seems to appear only on devices and emulators with slow disc I/O. Could it be that there is some race-condition in realm which occurs when an opened realm is not fully synced and a realm tries to save the transaction?

      Opening different configured realms for read-transactions on same thread did not seem to crash, only write is affected.

      Steps to Reproduce

      • Create a project with two different realm-configurations
      • Execute a batch of at least 100 write-transactions on realm 1
      • Execute a batch of write-transactions on realm 2

      The app should crash immediately on devices with slow disc I/O.

      I created a small project to explain the issue, but it is not crashing anyway. Please have a look at https://github.com/RonnyBansemer/RealmWriteCrash

      Version of Realm and Tooling

      • Realm Nuget 4.3
      • Mono.Android 10.0

            Assignee:
            yavor.georgiev@mongodb.com Yavor Georgiev
            Reporter:
            unitosyncbot Unito Sync Bot
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: