Realm-java: Calling RealmQuery.or() twice in a row causes a native crash

Created on 18 Sep 2018  路  2Comments  路  Source: realm/realm-java

Hello, I am trying to debug an app that we outsourced. Unfortunately I know very little about the intentions behind the code and such.

I can see that the realm library is having some trouble and crashes the app. I don't know how to deal with this issue because I've never come across NDK type stuff before now. Is this a realm bug?

I am using io.realm:realm-gradle-plugin:5.5.0
But I tried every version I can and the crash happens every time.

I am using android studio 3.1.4 and I'm on a Samsung s8 with Android version 8.0.0

Unfortunately I really cant pinpoint what part of the app crashes because the debugger just takes me to a lot of internal Android files.

Error log:

09-17 16:28:50.802 11131-11131/? A/DEBUG: * *
Build fingerprint: 'samsung/dreamltexx/dreamlte:8.0.0/R16NW/G950FXXU3CRGH:user/release-keys'
Revision: '10'
ABI: 'arm64'
pid: 10588, tid: 10588, name: orlobet.testing >>> com.example.app.testing <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x78
Cause: null pointer dereference
x0 0000000000000070 x1 0000007ff81f9f88 x2 0000000000000000 x3 0000000000000008
x4 0000000000000000 x5 000000720327c2c4 x6 0000000070c01fe8 x7 0000000000000000
x8 b9cff98c1c9e7bbf x9 b9cff98c1c9e7bbf x10 0000000000000003 x11 000000721d00d5e8
09-17 16:28:50.807 11131-11131/? A/DEBUG: backtrace:
#00 pc 00000000001af4ac /data/app/com.example.app.testing-iPhr1XyBcWheyQgchPeqDw==/lib/arm64/librealm-jni.so
#01 pc 00000000001b097c /data/app/com.example.app.testing-iPhr1XyBcWheyQgchPeqDw==/lib/arm64/librealm-jni.so
#02 pc 00000000001b4628 /data/app/com.example.app.testing-iPhr1XyBcWheyQgchPeqDw==/lib/arm64/librealm-jni.so
#03 pc 0000000000088864 /data/app/com.example.app.testing-iPhr1XyBcWheyQgchPeqDw==/lib/arm64/librealm-jni.so (Java_io_realm_internal_TableQuery_nativeOr+180)
#04 pc 0000000000034cd4 /data/app/com.example.app.testing-iPhr1XyBcWheyQgchPeqDw==/oat/arm64/base.odex (offset 0x21000)

O-Community T-Bug

Most helpful comment

Yes, calling or().or() is not a valid query, but ideally, we would throw a much better exception message if it happened.

However, it seems we do crash in the native code. At least I'm getting the following exception:

09-16 10:01:40.817 11841-11857/? E/REALM: /home/jenkins/workspace/lm_realm-core_release_5.8.0-WNQBV7C77QKZDCVNM3JGU7TWI2TAI6NYMGETFCZRYCCOCOCMZT2A@9/src/realm/query.cpp:1727: [realm-core-5.8.0] Assertion failed: dynamic_cast<OrNode*>(current_group.m_root_node.get())
    !!! IMPORTANT: Please send this log and info about Realm SDK version and other relevant reproduction info to [email protected].
09-16 10:01:40.817 11841-11857/? A/libc: Fatal signal 6 (SIGABRT), code -6 in tid 11857 (roidJUnitRunner)
09-16 10:01:40.874 11861-11861/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
    Build fingerprint: 'Android/vbox86p/vbox86p:7.1.1/NMF26Q/genymo09291150:userdebug/test-keys'
    Revision: '0'
    ABI: 'x86'
    pid: 11841, tid: 11857, name: roidJUnitRunner  >>> io.realm.test <<<
09-16 10:01:40.875 11861-11861/? A/DEBUG: signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
        eax 00000000  ebx 00002e41  ecx 00002e51  edx 00000006
        esi d519c978  edi d519c920
        xcs 00000023  xds 0000002b  xes 0000002b  xfs 0000006b  xss 0000002b
        eip f2b63bb9  ebp d5194de8  esp d5194d8c  flags 00000296
09-16 10:01:40.877 11861-11861/? A/DEBUG: backtrace:
        #00 pc 00000bb9  [vdso:f2b63000] (__kernel_vsyscall+9)
        #01 pc 0007a30c  /system/lib/libc.so (tgkill+28)
        #02 pc 00075b55  /system/lib/libc.so (pthread_kill+85)
        #03 pc 0002786a  /system/lib/libc.so (raise+42)
        #04 pc 0001ee46  /system/lib/libc.so (abort+86)
        #05 pc 00682bf6  /data/app/io.realm.test-2/lib/x86/librealm-jni.so (please_report_this_error_to_help_at_realm_dot_io+23)
        #06 pc 00682d32  /data/app/io.realm.test-2/lib/x86/librealm-jni.so (_ZN5realm4utilL18terminate_internalERSt18basic_stringstreamIcSt11char_traitsIcESaIcEE+260)
        #07 pc 00682e13  /data/app/io.realm.test-2/lib/x86/librealm-jni.so (_ZN5realm4util9terminateEPKcS2_lOSt16initializer_listINS0_9PrintableEE+224)
        #08 pc 0059a824  /data/app/io.realm.test-2/lib/x86/librealm-jni.so (_ZN5realm5Query8add_nodeESt10unique_ptrINS_10ParentNodeESt14default_deleteIS2_EE+400)
        #09 pc 005992e6  /data/app/io.realm.test-2/lib/x86/librealm-jni.so (_ZN5realm5Query2OrEv+136)
        #10 pc 0011f4e1  /data/app/io.realm.test-2/lib/x86/librealm-jni.so (Java_io_realm_internal_TableQuery_nativeOr+268)
        #11 pc 00b22e64  /data/app/io.realm.test-2/oat/x86/base.odex (offset 0xa97000)

This is a bug that should be fixed

All 2 comments

Wow. Ok I just had a breakthrough.
After I meditated a bit and did another round of thorough debugging, I found this code:
RealmResults<AnswerImageData> answerImgDataList = realm .where(AnswerImageData.class) .equalTo("id", questionData.getFalse1_id()) .or() .or().equalTo("id", questionData.getFalse2_id()) .or().equalTo("id", questionData.getFalse3_id()) .or().equalTo("id", questionData.getCorrect_id()).findAll();

It seemed weird to me that there should be 2 .or()'s after one another. So i removed one and now the app finally works :)

I'd like to get a confirmation. Is two .or()'s in a row cause of bugging in realm? I don't want to remove that only to realize that i removed legitimate code.

If it's a bug, how can I better detect such errors in the future? :)

Yes, calling or().or() is not a valid query, but ideally, we would throw a much better exception message if it happened.

However, it seems we do crash in the native code. At least I'm getting the following exception:

09-16 10:01:40.817 11841-11857/? E/REALM: /home/jenkins/workspace/lm_realm-core_release_5.8.0-WNQBV7C77QKZDCVNM3JGU7TWI2TAI6NYMGETFCZRYCCOCOCMZT2A@9/src/realm/query.cpp:1727: [realm-core-5.8.0] Assertion failed: dynamic_cast<OrNode*>(current_group.m_root_node.get())
    !!! IMPORTANT: Please send this log and info about Realm SDK version and other relevant reproduction info to [email protected].
09-16 10:01:40.817 11841-11857/? A/libc: Fatal signal 6 (SIGABRT), code -6 in tid 11857 (roidJUnitRunner)
09-16 10:01:40.874 11861-11861/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
    Build fingerprint: 'Android/vbox86p/vbox86p:7.1.1/NMF26Q/genymo09291150:userdebug/test-keys'
    Revision: '0'
    ABI: 'x86'
    pid: 11841, tid: 11857, name: roidJUnitRunner  >>> io.realm.test <<<
09-16 10:01:40.875 11861-11861/? A/DEBUG: signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
        eax 00000000  ebx 00002e41  ecx 00002e51  edx 00000006
        esi d519c978  edi d519c920
        xcs 00000023  xds 0000002b  xes 0000002b  xfs 0000006b  xss 0000002b
        eip f2b63bb9  ebp d5194de8  esp d5194d8c  flags 00000296
09-16 10:01:40.877 11861-11861/? A/DEBUG: backtrace:
        #00 pc 00000bb9  [vdso:f2b63000] (__kernel_vsyscall+9)
        #01 pc 0007a30c  /system/lib/libc.so (tgkill+28)
        #02 pc 00075b55  /system/lib/libc.so (pthread_kill+85)
        #03 pc 0002786a  /system/lib/libc.so (raise+42)
        #04 pc 0001ee46  /system/lib/libc.so (abort+86)
        #05 pc 00682bf6  /data/app/io.realm.test-2/lib/x86/librealm-jni.so (please_report_this_error_to_help_at_realm_dot_io+23)
        #06 pc 00682d32  /data/app/io.realm.test-2/lib/x86/librealm-jni.so (_ZN5realm4utilL18terminate_internalERSt18basic_stringstreamIcSt11char_traitsIcESaIcEE+260)
        #07 pc 00682e13  /data/app/io.realm.test-2/lib/x86/librealm-jni.so (_ZN5realm4util9terminateEPKcS2_lOSt16initializer_listINS0_9PrintableEE+224)
        #08 pc 0059a824  /data/app/io.realm.test-2/lib/x86/librealm-jni.so (_ZN5realm5Query8add_nodeESt10unique_ptrINS_10ParentNodeESt14default_deleteIS2_EE+400)
        #09 pc 005992e6  /data/app/io.realm.test-2/lib/x86/librealm-jni.so (_ZN5realm5Query2OrEv+136)
        #10 pc 0011f4e1  /data/app/io.realm.test-2/lib/x86/librealm-jni.so (Java_io_realm_internal_TableQuery_nativeOr+268)
        #11 pc 00b22e64  /data/app/io.realm.test-2/oat/x86/base.odex (offset 0xa97000)

This is a bug that should be fixed

Was this page helpful?
0 / 5 - 0 ratings