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)
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
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:
This is a bug that should be fixed