Closed bfichter closed 4 years ago
I have an absolutely similar problem. The error rate increased when I changed the Realm version from 5.3.1 to 5.4.2 During the last day I received 661 crash reports from Google.
09-12 17:35:47.396 20978-20963/? A/google-breakpad: Microdump skipped (uninteresting)
09-12 17:35:47.424 20776-20963/? W/google-breakpad: ### ### ### ### ### ### ### ### ### ### ### ### ###
Chrome build fingerprint:
69.0.3497.91
349709152
### ### ### ### ### ### ### ### ### ### ### ### ###
09-12 17:35:47.428 20776-20963/? A/libc: Fatal signal 11 (SIGSEGV), code 2, fault addr 0x7f4fafb000 in tid 20963 (RxAndroidHandle)
09-12 17:35:47.525 20979-20979/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'Xiaomi/rosy_ru/rosy:7.1.2/N2G47H/V9.6.3.0.NDARUFD:user/release-keys'
09-12 17:35:47.526 20979-20979/? A/DEBUG: Revision: '0'
ABI: 'arm64'
pid: 20776, tid: 20963, name: RxAndroidHandle >>> ru.fcb.mobilefieldcollection <<<
signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x7f4fafb000
x0 0000007f4fbfa1c0 x1 0000007f4fbfa1bf x2 0000007f4f0817d7 x3 0000007f4fbfa218
x4 0000007f4ce798bd x5 0000007f811fd940 x6 0000007f4ce798bd x7 0000007f811fd804
x8 0000000000000000 x9 0000000000000001 x10 0000000000000001 x11 0000000000000000
x12 0000000000000001 x13 00000000ffffffff x14 000000000011e580 x15 0000000000001fe3
x16 0000007f56e08570 x17 0000007f81198b48 x18 00000000ac2a017b x19 0000007f4fbfa1c0
x20 0000007f56d63000 x21 0000007f4fbfa380 x22 0000007f4fafb000 x23 0000007f4fbfa1c0
x24 0000007f4fbfa1bf x25 0000000000000001 x26 0000007f4fbfa3a8 x27 0000007f4fbfa410
09-12 17:35:47.527 20979-20979/? A/DEBUG: x28 0000007f4fbfa3b0 x29 0000007f4fbfa130 x30 0000007f56b3cdf0
sp 0000007f4fbfa130 pc 0000007f56b3cddc pstate 0000000020000000
09-12 17:35:47.540 20979-20979/? A/DEBUG: backtrace:
#00 pc 000000000003bddc /data/app/ru.fcb.mobilefieldcollection-2/lib/arm64/librealm-jni.so
#01 pc 00000000000bcc68 /data/app/ru.fcb.mobilefieldcollection-2/lib/arm64/librealm-jni.so
#02 pc 00000000000b65b8 /data/app/ru.fcb.mobilefieldcollection-2/lib/arm64/librealm-jni.so (Java_io_realm_internal_UncheckedRow_nativeGetString+92)
#03 pc 000000000072a9c0 /data/app/ru.fcb.mobilefieldcollection-2/oat/arm64/base.odex (offset 0x6b8000)
I was able to get a corrupted database: realm_crash_1.zip
My configuration:
new RealmConfiguration
.Builder()
.name(realmName)
.schemaVersion(Constants.DB_VERSION)
.directory(dbDir)
.encryptionKey(key)
.migration(MIGRATION)
.initialData(INIT_REALM_TX)
.build();
Version of Realm and tooling
Realm version(s): 5.4.2 w/encryption enabled
Realm sync feature enabled: no
Android Studio version: 3.1.4
Which Android version and device: Xiaomi Redmi 5
Sometimes stack is slightly different: android_crush_code-6(SI_TKILL).log
Realm version: 5.5.0 w/encryption enabled Realm sync feature enabled: no
Android Studio version: 3.1.4
Which Android version and device: Emulator x86 API 28
This is happening on Samsung Galaxy S7 edge (hero2lte), Android 8.0
Any updates on this? We have many reports on 5.7.1 with encryption enabled, but can't reproduce it locally.
Realm version: 5.9.1 with encryption enabled Realm sync feature enabled: no
Android Studio version: 3.3.2
Which Android version and device: Xiaomi Redmi 5 (Android 7.1.2), Honor 10 (Android 9)
First crash:
03-13 14:25:36.592 8582-8894/ru.fcb.mobilefieldcollection A/libc: Fatal signal 6 (SIGABRT), code -6 in tid 8894 (RxAndroidHandle)
Subsequent run:
03-13 14:32:23.447 12602-12645/ru.fcb.mobilefieldcollection A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x7f5db44000 in tid 12645 (RxAndroidHandle)
Or:
03-13 14:37:47.875 13034-13085/ru.fcb.mobilefieldcollection A/libc: Fatal signal 11 (SIGSEGV), code 2, fault addr 0x7f5cc44000 in tid 13085 (RxAndroidHandle)
Reproducible locally. It seems that some data blocks are corrupted, because crash is happening on the items list screen. When I've change filtering crash not happened. Same entries show on other view (map with markers) and there is no crash too but that view access only 3 numeric fields (id, lon, lat) from entity. Hope this helps. I can try with some debug/experimental realm build.
While experimenting with different Realm versions I've noticed that 5.3.1 has minimum crash cases. We use 5.3.1 in in production hower even with 5.3.1 Realm crashes are top 7 and >90% of all crashes. Please assist.
crash report :(
@mussa-ibragimov @ggajews It would be useful to provide more information - e.g. a stacktrace so we can see if it's really the same issue. As it seems related to getting a string out of the database, any realm that has this issue, together with the models you use and information about the character sets that could be stored would be helpful.
@Zey-Uzh While it's very useful to get the database that appears corrupt, we need the encryption key to actually open it :-)
@bmunkholm I would love to provide more info, but all I have is the play store reports
#00 pc 000000000003d03c /data/app/com.crashing.app-YaEGSwTeIOaFDQ6E-FZYQw==/lib/arm64/librealm-jni.so
#01 pc 00000000000bf300 /data/app/com.crashing.app-YaEGSwTeIOaFDQ6E-FZYQw==/lib/arm64/librealm-jni.so
#02 pc 00000000000b8298 /data/app/com.crashing.app-YaEGSwTeIOaFDQ6E-FZYQw==/lib/arm64/librealm-jni.so (Java_io_realm_internal_UncheckedRow_nativeGetString+92)
#03 pc 00000000007b09ac /data/app/com.crashing.app-YaEGSwTeIOaFDQ6E-FZYQw==/oat/arm64/base.odex
We have trouble with reproducing it locally. We received 820 reports last week affecting 105 users Let me know if I can get you something more usable somehow
@bmunkholm Where to send corrupted DB with key? As I know there is no way to change on disk character encoding for realm-java. Actual characters in our DB mostly from Cyrillic Unicode code range: https://jrgraphix.net/r/Unicode/0400-04FF I've try to populate DB with ASCII only characters...
@vladimirfx You can send it to help@realm.io
But having a DB that throws this error would be a massive help (and a pointer to which object actually throws the error).
Corrupted DB emailed to help@realm.io
I assume this is the crash we should look for?
2018-09-13 13:56:25.398 22429-22429/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
2018-09-13 13:56:25.398 22429-22429/? A/DEBUG: Build fingerprint: 'google/sdk_gphone_x86/generic_x86:9/PSR1.180720.012/4923214:userdebug/dev-keys'
2018-09-13 13:56:25.398 22429-22429/? A/DEBUG: Revision: '0'
2018-09-13 13:56:25.398 22429-22429/? A/DEBUG: ABI: 'x86'
2018-09-13 13:56:25.398 22429-22429/? A/DEBUG: pid: 22074, tid: 22140, name: RxAndroidHandle >>> ru.fcb.mobilefieldcollection <<<
2018-09-13 13:56:25.398 22429-22429/? A/DEBUG: signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
2018-09-13 13:56:25.398 22429-22429/? A/DEBUG: eax 00000000 ebx 0000563a ecx 0000567c edx 00000006
2018-09-13 13:56:25.398 22429-22429/? A/DEBUG: edi 0000563a esi f50712a8
2018-09-13 13:56:25.398 22429-22429/? A/DEBUG: ebp d1efa638 esp d1efa568 eip f6259b59
2018-09-13 13:56:25.509 2850-2974/system_process I/GnssLocationProvider: WakeLock acquired by sendMessage(REPORT_SV_STATUS, 0, com.android.server.location.GnssLocationProvider$SvStatusInfo@b5788a9)
2018-09-13 13:56:25.510 2850-2870/system_process I/GnssLocationProvider: WakeLock released by handleMessage(REPORT_SV_STATUS, 0, com.android.server.location.GnssLocationProvider$SvStatusInfo@b5788a9)
2018-09-13 13:56:25.629 22429-22429/? A/DEBUG: backtrace:
2018-09-13 13:56:25.629 22429-22429/? A/DEBUG: #00 pc 00000b59 [vdso:f6259000] (__kernel_vsyscall+9)
2018-09-13 13:56:25.629 22429-22429/? A/DEBUG: #01 pc 0001fdf8 /system/lib/libc.so (syscall+40)
2018-09-13 13:56:25.629 22429-22429/? A/DEBUG: #02 pc 00022ed3 /system/lib/libc.so (abort+115)
2018-09-13 13:56:25.629 22429-22429/? A/DEBUG: #03 pc 00260254 /data/app/ru.fcb.mobilefieldcollection-tiBKHhQFE9EmReHKcG6ROw==/lib/x86/librealm-jni.so (__gnu_cxx::__verbose_terminate_handler()+452)
2018-09-13 13:56:25.629 22429-22429/? A/DEBUG: #04 pc 0022d967 /data/app/ru.fcb.mobilefieldcollection-tiBKHhQFE9EmReHKcG6ROw==/lib/x86/librealm-jni.so (__cxxabiv1::__terminate(void (*)())+23)
2018-09-13 13:56:25.629 22429-22429/? A/DEBUG: #05 pc 0025fe85 /data/app/ru.fcb.mobilefieldcollection-tiBKHhQFE9EmReHKcG6ROw==/lib/x86/librealm-jni.so
2018-09-13 13:56:25.629 22429-22429/? A/DEBUG: #06 pc 0022d0c1 /data/app/ru.fcb.mobilefieldcollection-tiBKHhQFE9EmReHKcG6ROw==/lib/x86/librealm-jni.so (__gxx_personality_v0+321)
2018-09-13 13:56:25.629 22429-22429/? A/DEBUG: #07 pc 002741b8 /data/app/ru.fcb.mobilefieldcollection-tiBKHhQFE9EmReHKcG6ROw==/lib/x86/librealm-jni.so
2018-09-13 13:56:25.629 22429-22429/? A/DEBUG: #08 pc 00274606 /data/app/ru.fcb.mobilefieldcollection-tiBKHhQFE9EmReHKcG6ROw==/lib/x86/librealm-jni.so (_Unwind_Resume+92)
2018-09-13 13:56:25.629 22429-22429/? A/DEBUG: #09 pc 001183e0 /data/app/ru.fcb.mobilefieldcollection-tiBKHhQFE9EmReHKcG6ROw==/lib/x86/librealm-jni.so
2018-09-13 13:56:25.629 22429-22429/? A/DEBUG: #10 pc 00118ac0 /data/app/ru.fcb.mobilefieldcollection-tiBKHhQFE9EmReHKcG6ROw==/lib/x86/librealm-jni.so
2018-09-13 13:56:25.629 22429-22429/? A/DEBUG: #11 pc 00117661 /data/app/ru.fcb.mobilefieldcollection-tiBKHhQFE9EmReHKcG6ROw==/lib/x86/librealm-jni.so
2018-09-13 13:56:25.629 22429-22429/? A/DEBUG: #12 pc 001ba3a8 /data/app/ru.fcb.mobilefieldcollection-tiBKHhQFE9EmReHKcG6ROw==/lib/x86/librealm-jni.so
2018-09-13 13:56:25.629 22429-22429/? A/DEBUG: #13 pc 00225cac /data/app/ru.fcb.mobilefieldcollection-tiBKHhQFE9EmReHKcG6ROw==/lib/x86/librealm-jni.so
2018-09-13 13:56:25.629 22429-22429/? A/DEBUG: #14 pc 0020735a /data/app/ru.fcb.mobilefieldcollection-tiBKHhQFE9EmReHKcG6ROw==/lib/x86/librealm-jni.so
2018-09-13 13:56:25.629 22429-22429/? A/DEBUG: #15 pc 000a31e9 /data/app/ru.fcb.mobilefieldcollection-tiBKHhQFE9EmReHKcG6ROw==/lib/x86/librealm-jni.so (Java_io_realm_internal_UncheckedRow_nativeGetString+89)
2018-09-13 13:56:25.629 22429-22429/? A/DEBUG: #16 pc 000f1110 /dev/ashmem/dalvik-jit-code-cache (deleted) (io.realm.internal.UncheckedRow.nativeGetString+144)
2018-09-13 13:56:25.629 22429-22429/? A/DEBUG: #17 pc 000b4185 /dev/ashmem/dalvik-jit-code-cache (deleted) (io.realm.internal.UncheckedRow.getString+69)
2018-09-13 13:56:25.629 22429-22429/? A/DEBUG: #18 pc 000dee34 /dev/ashmem/dalvik-jit-code-cache (deleted) (io.realm.ru_fcb_mobilefieldcollection_debt_DebtRealmProxy.realmGet$contragent+308)
2018-09-13 13:56:25.629 22429-22429/? A/DEBUG: #19 pc 0003a4d8 /dev/ashmem/dalvik-jit-code-cache (deleted) (ru.fcb.mobilefieldcollection.debt.Debt.getContragent+216)
2018-09-13 13:56:25.629 22429-22429/? A/DEBUG: #20 pc 000504d5 /dev/ashmem/dalvik-jit-code-cache (deleted) (ru.fcb.mobilefieldcollection.alldebts.AllDebtsPresenter.convertToUIDebt+725)
2018-09-13 13:56:25.629 22429-22429/? A/DEBUG: #21 pc 0005afb6 /dev/ashmem/dalvik-jit-code-cache (deleted) (ru.fcb.mobilefieldcollection.alldebts.AllDebtsPresenter.lambda$bindIntents$0+470)
2018-09-13 13:56:25.629 22429-22429/? A/DEBUG: #22 pc 005f0d52 /system/lib/libart.so (art_quick_invoke_static_stub+418)
2018-09-13 13:56:25.629 22429-22429/? A/DEBUG: #23 pc 000a30df /system/lib/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+239)
2018-09-13 13:56:25.629 22429-22429/? A/DEBUG: #24 pc 0029bca2 /system/lib/libart.so (art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread*, art::ArtMethod*, art::ShadowFrame*, unsigned short, art::JValue*)+338)
2018-09-13 13:56:25.629 22429-22429/? A/DEBUG: #25 pc 00293e48 /system/lib/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+1048)
Unrolled stacktrace:
********** Crash dump: **********
Build fingerprint: 'google/sdk_gphone_x86/generic_x86:9/PSR1.180720.012/4923214:userdebug/dev-keys'
pid: 22074, tid: 22140, name: RxAndroidHandle >>> ru.fcb.mobilefieldcollection <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Stack frame #00 pc 00000b59 [vdso:f6259000] (__kernel_vsyscall+9)
Stack frame #01 pc 0001fdf8 /system/lib/libc.so (syscall+40)
Stack frame #02 pc 00022ed3 /system/lib/libc.so (abort+115)
Stack frame #03 pc 00260254 /data/app/ru.fcb.mobilefieldcollection-tiBKHhQFE9EmReHKcG6ROw==/lib/x86/librealm-jni.so (__gnu_cxx::__verbose_terminate_handler()+452): Routine std::time_get<char, std::istreambuf_iterator<char, std::char_traits<char> > >::_M_extract_via_format(std::istreambuf_iterator<char, std::char_traits<char> >, std::istreambuf_iterator<char, std::char_traits<char> >, std::ios_base&, std::_Ios_Iostate&, tm*, char const*) const at /tmp/ndk-user/tmp/gnu-libstdc++/static-x86-4.9/include/bits/locale_facets_nonio.tcc:779
Stack frame #04 pc 0022d967 /data/app/ru.fcb.mobilefieldcollection-tiBKHhQFE9EmReHKcG6ROw==/lib/x86/librealm-jni.so (__cxxabiv1::__terminate(void (*)())+23): Routine long long realm::TableViewBase::aggregate<2, long long, long long, realm::Column<long long> >(long long (realm::Column<long long>::*)(unsigned int, unsigned int, unsigned int, unsigned int*) const, unsigned int, long long, unsigned int*) const [clone .isra.123] at table_view.cpp:?
Stack frame #05 pc 0025fe85 /data/app/ru.fcb.mobilefieldcollection-tiBKHhQFE9EmReHKcG6ROw==/lib/x86/librealm-jni.so: Routine std::time_get<char, std::istreambuf_iterator<char, std::char_traits<char> > >::_M_extract_via_format(std::istreambuf_iterator<char, std::char_traits<char> >, std::istreambuf_iterator<char, std::char_traits<char> >, std::ios_base&, std::_Ios_Iostate&, tm*, char const*) const at /tmp/ndk-user/tmp/gnu-libstdc++/static-x86-4.9/include/bits/locale_facets_nonio.tcc:627
Stack frame #06 pc 0022d0c1 /data/app/ru.fcb.mobilefieldcollection-tiBKHhQFE9EmReHKcG6ROw==/lib/x86/librealm-jni.so (__gxx_personality_v0+321): Routine realm::TableViewBase::apply_patch(realm::TableViewHandoverPatch&, realm::Group&) at unwind-dw2-fde-dip.c:?
Stack frame #07 pc 002741b8 /data/app/ru.fcb.mobilefieldcollection-tiBKHhQFE9EmReHKcG6ROw==/lib/x86/librealm-jni.so: Routine std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::_Rep::_M_dispose(std::allocator<wchar_t> const&) at /tmp/ndk-user/tmp/gnu-libstdc++/static-x86-4.9/include/bits/basic_string.h:249
Stack frame #08 pc 00274606 /data/app/ru.fcb.mobilefieldcollection-tiBKHhQFE9EmReHKcG6ROw==/lib/x86/librealm-jni.so (_Unwind_Resume+92): Routine std::moneypunct<wchar_t, true>::do_curr_symbol() const at /tmp/ndk-user/tmp/gnu-libstdc++/static-x86-4.9/include/bits/locale_facets_nonio.h:1208 (discriminator 1)
Stack frame #09 pc 001183e0 /data/app/ru.fcb.mobilefieldcollection-tiBKHhQFE9EmReHKcG6ROw==/lib/x86/librealm-jni.so: Routine realm::_impl::ResultsNotifier::ResultsNotifier(realm::Results&) at unwind-dw2-fde-dip.c:?
Stack frame #10 pc 00118ac0 /data/app/ru.fcb.mobilefieldcollection-tiBKHhQFE9EmReHKcG6ROw==/lib/x86/librealm-jni.so: Routine realm::_impl::ResultsNotifier::calculate_changes() at unwind-dw2-fde-dip.c:?
Stack frame #11 pc 00117661 /data/app/ru.fcb.mobilefieldcollection-tiBKHhQFE9EmReHKcG6ROw==/lib/x86/librealm-jni.so: Routine realm::_impl::ResultsNotifier::do_prepare_handover(realm::SharedGroup&) at unwind-dw2-fde-dip.c:?
Stack frame #12 pc 001ba3a8 /data/app/ru.fcb.mobilefieldcollection-tiBKHhQFE9EmReHKcG6ROw==/lib/x86/librealm-jni.so: Routine void std::vector<realm::Group::CascadeNotification::row, std::allocator<realm::Group::CascadeNotification::row> >::_M_insert_aux<realm::Group::CascadeNotification::row const&>(__gnu_cxx::__normal_iterator<realm::Group::CascadeNotification::row*, std::vector<realm::Group::CascadeNotification::row, std::allocator<realm::Group::CascadeNotification::row> > >, realm::Group::CascadeNotification::row const&) at unwind-dw2-fde-dip.c:?
Stack frame #13 pc 00225cac /data/app/ru.fcb.mobilefieldcollection-tiBKHhQFE9EmReHKcG6ROw==/lib/x86/librealm-jni.so: Routine .L4733 at table.cpp:?
Stack frame #14 pc 0020735a /data/app/ru.fcb.mobilefieldcollection-tiBKHhQFE9EmReHKcG6ROw==/lib/x86/librealm-jni.so: Routine bool realm::Array::find_optimized<realm::NotEqual, (realm::Action)7, 1u, std::_Bind<std::_Mem_fn<bool (realm::ColumnNodeBase::*)(long long)> (realm::IntegerNodeBase<realm::Column<realm::util::Optional<long long> > >*, std::_Placeholder<1>)> >(long long, unsigned int, unsigned int, unsigned int, realm::QueryState<long long>*, std::_Bind<std::_Mem_fn<bool (realm::ColumnNodeBase::*)(long long)> (realm::IntegerNodeBase<realm::Column<realm::util::Optional<long long> > >*, std::_Placeholder<1>)>, bool, bool) const at unwind-dw2-fde-dip.c:?
Stack frame #15 pc 000a31e9 /data/app/ru.fcb.mobilefieldcollection-tiBKHhQFE9EmReHKcG6ROw==/lib/x86/librealm-jni.so (Java_io_realm_internal_UncheckedRow_nativeGetString+89): Routine realm::Compare<realm::NotEqual, realm::BinaryData, realm::Subexpr, realm::Subexpr>::description(realm::util::serializer::SerialisationState&) const at unwind-dw2-fde-dip.c:?
Stack frame #16 pc 000f1110 /dev/ashmem/dalvik-jit-code-cache (deleted) (io.realm.internal.UncheckedRow.nativeGetString+144)
Stack frame #17 pc 000b4185 /dev/ashmem/dalvik-jit-code-cache (deleted) (io.realm.internal.UncheckedRow.getString+69)
Stack frame #18 pc 000dee34 /dev/ashmem/dalvik-jit-code-cache (deleted) (io.realm.ru_fcb_mobilefieldcollection_debt_DebtRealmProxy.realmGet$contragent+308)
Stack frame #19 pc 0003a4d8 /dev/ashmem/dalvik-jit-code-cache (deleted) (ru.fcb.mobilefieldcollection.debt.Debt.getContragent+216)
Stack frame #20 pc 000504d5 /dev/ashmem/dalvik-jit-code-cache (deleted) (ru.fcb.mobilefieldcollection.alldebts.AllDebtsPresenter.convertToUIDebt+725)
Stack frame #21 pc 0005afb6 /dev/ashmem/dalvik-jit-code-cache (deleted) (ru.fcb.mobilefieldcollection.alldebts.AllDebtsPresenter.lambda$bindIntents$0+470)
Stack frame #22 pc 005f0d52 /system/lib/libart.so (art_quick_invoke_static_stub+418)
Stack frame #23 pc 000a30df /system/lib/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+239)
Stack frame #24 pc 0029bca2 /system/lib/libart.so (art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread*, art::ArtMethod*, art::ShadowFrame*, unsigned short, art::JValue*)+338)
Stack frame #25 pc 00293e48 /system/lib/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+1048)
Yes, this is one of many similar stacktraces where one of text property of Debt or Debtor entity are accessed. It can happened on different threads.
I'll checked assuption that crash depends on string encoding: Actually it is not. Moreover, on ASCII only text crash happened sooner than with Cyrillic text. Can send one more corrupted DB.
That would be great. Thank you 👏
@vladimirfx Thank you for the file
I can reproduce a crash when looping over all Debt objects reading out all String fields. The first crash I encounter is here:
2019-03-13 00:35:47.282 8797-8813/? E/REALM_JAVA: Read: 'comment' on debtId: 44294208
2019-03-13 00:35:48.016 8797-8813/? A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0xd4a80000 in tid 8813 (roidJUnitRunner)
2019-03-13 00:35:48.073 8818-8818/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
2019-03-13 00:35:48.073 8818-8818/? A/DEBUG: Build fingerprint: 'Android/vbox86p/vbox86p:7.1.1/NMF26Q/genymo09291150:userdebug/test-keys'
2019-03-13 00:35:48.073 8818-8818/? A/DEBUG: Revision: '0'
2019-03-13 00:35:48.073 8818-8818/? A/DEBUG: ABI: 'x86'
2019-03-13 00:35:48.073 8818-8818/? A/DEBUG: pid: 8797, tid: 8813, name: roidJUnitRunner >>> io.realm.test <<<
2019-03-13 00:35:48.073 8818-8818/? A/DEBUG: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xd4a80000
2019-03-13 00:35:48.073 8818-8818/? A/DEBUG: eax d3cca4f7 ebx d5377dd0 ecx d5795244 edx d5370c4c
2019-03-13 00:35:48.073 8818-8818/? A/DEBUG: esi d4a80000 edi d579505c
2019-03-13 00:35:48.073 8818-8818/? A/DEBUG: xcs 00000023 xds 0000002b xes 0000002b xfs 0000006b xss 0000002b
2019-03-13 00:35:48.073 8818-8818/? A/DEBUG: eip d4e23c62 ebp d5795128 esp d5795040 flags 00010216
2019-03-13 00:35:48.074 8818-8818/? A/DEBUG: backtrace:
2019-03-13 00:35:48.074 8818-8818/? A/DEBUG: #00 pc 00129c62 /data/app/io.realm.test-1/lib/x86/librealm-jni.so (_ZL13string_to_hexRKSsRN5realm10StringDataEPKcS5_PtS6_jj+264)
2019-03-13 00:35:48.074 8818-8818/? A/DEBUG: #01 pc 0012a7df /data/app/io.realm.test-1/lib/x86/librealm-jni.so (_Z10to_jstringP7_JNIEnvN5realm10StringDataE+1471)
2019-03-13 00:35:48.074 8818-8818/? A/DEBUG: #02 pc 0011d8fe /data/app/io.realm.test-1/lib/x86/librealm-jni.so (Java_io_realm_internal_UncheckedRow_nativeGetString+574)
2019-03-13 00:35:48.074 8818-8818/? A/DEBUG: #03 pc 000970ef /data/app/io.realm.test-1/lib/x86/librealm-jni.so (Java_io_realm_internal_CheckedRow_nativeGetString+113)
2019-03-13 00:35:48.074 8818-8818/? A/DEBUG: #04 pc 00a89f74 /data/app/io.realm.test-1/oat/x86/base.odex (offset 0x9cc000)
At first glance, it appears to be a bug in Javas string_to_hex
method, but if I read the String in Realm Studio it looks empty (which probably mean that Javascript also fails to read the string but just fails silently). I'll debug futher.
I was sent another corrupted db from Android 9 device. It's crashes on database opening. crush_log.txt
@cmelchior any progress in debugging this issue?
another report this time user reports app just crashed repeatedly but I couldn't get more info besides native stack trace. We are using android realm 5.8.0 with encryption no cloud db.
pid: 0, tid: 0 >>> com.our.app <<<
backtrace:
#00 pc 000000000003e1c0 /data/app/com.our.app-6FDq9SxoM5L2Ul5CPNbniQ==/lib/arm64/librealm-jni.so
#01 pc 00000000000c93b8 /data/app/com.our.app-6FDq9SxoM5L2Ul5CPNbniQ==/lib/arm64/librealm-jni.so
#02 pc 00000000000be8e0 /data/app/com.our.app-6FDq9SxoM5L2Ul5CPNbniQ==/lib/arm64/librealm-jni.so (Java_io_realm_internal_UncheckedRow_nativeGetString+92)
#03 pc 0000000000a2df8c /data/app/com.our.app-6FDq9SxoM5L2Ul5CPNbniQ==/oat/arm64/base.odex
We are running into the same issue. Any updates or ideas from the Realm team? Thanks.
Same issue here, members of my team also contacted realm but no word update on that. There's a lot of similar issues open with native crashes but doesn't seem like the Realm team is giving any insights or feedback on them, only asking for samples, etc. Any update on this?
Practically all the bugs on the affected app are caused by these realm issues
Our team has active paid support. We provide 2 or 3 corrupted databases with encryption keys. Unfortunately, no update. And now we consider painful database switch, because of this and similar native crashes. That sad...
Has anyone tries reverting back to a version from (for example) last year as some kind of last resort measure?
I believe in most cases reverting back would not require a migration?
Realm schema file format upgrades are not backwards compatible.
Really sorry about the lacking update here! We had an internal issue tracking the detailed troubleshooting efforts and missed getting back on this one. The status is that although we can reproduce the crash with the seemingly corrupt files provided, we unfortunately still have no leads on how it could end up in that state. There is nothing more we would like than to be able to replicate the issue and track back the root cause. Doing that is an iterative troubleshooting exercise that requires us to be able to replicate getting from a good state to the bad state. In the past, we have experienced some of these "hard to track bugs" to be deep down in the OS. , and it's not entirely trivial to pinpoint that without being able to replicate the issue.
The only things that could help us with this would be to get very detailed stats about where this issue is occurring (Device and OS versions), to give us hints if this is really OS dependent. And of course better, to have a way to replicate the issue from a good state (not just replicate the crash happening from a bad state). But even getting more realm files to see a pattern would be potentially useful. We highly appreciate your understanding and help in resolving this.
OS versions for our app API 23 to 28. Vendors: Xiaomi, Samsunt, Lenovo, Huawai, Asus. Can you provide special debug build of Realm? We can try reproduce issues on it.
Sure we can provide a version with all assertions turned on and hope to catch this earlier. Are you able to reproduce this internally? Can it also be reproduced when not using encryption?
Sure we can provide a version with all assertions turned on and hope to catch this earlier.
Binaries coordinates ?
Are you able to reproduce this internally?
Yes, our team already sent 3 corrupted DBs.
Can it also be reproduced when not using encryption?
We use Realm in several projects. This distinct bug reproducible only in projects with enabled encryption.
@vladimirfx It's not something we have available by default, but something we will have to build. @cmelchior should be able to get that together for you. I'll let him comment on when that can be done.
It is interesting if this only happens for encrypted realms. Has anyone else seen this in non-encrypted realms?
Stats from us: Os version:
Android 8.1 | 605 | 34.5% |
---|---|---|
Android 8.0 | 446 | 25.4% |
Android 7.0 | 400 | 22.8% |
Android 6.0 | 289 | 16.5% |
Devices:
Galaxy XCover4 (xcover4lte) | 603 | 34.4% |
---|---|---|
LG K8 LTE (mm1vn) | 264 | 15.0% |
Galaxy J5 (j5y17lte) | 171 | 9.7% |
Galaxy S7 edge (hero2lte) | 120 | 6.8% |
Xperia L1 (G3311) | 91 | 5.2% |
Realm IS encrypted
@bmunkholm I Have also encountered this issue using encrypted realm. Although I cannot replicate it using non-encrypted realms. I described it here: https://github.com/realm/realm-java/issues/6562
I have no knowledge about the inner workings of Realm-Core but I want to understand why realm files cannot be validated internally to not contain corrupt or erroneous data and auto-recover in a clean slate. The fact that realm files can go "corrupt" and require a full uninstall/reinstall of the application is very bad for such a widely used database.
Also, has anyone tried to build their own encryption layer/interface and disable the encryption done by realm? We would have tried something like this if it wasn't for our encryption key rotating every so often.
The fact that realm files can go "corrupt" and require a full uninstall/reinstall of the application is very bad for such a widely used database.
Alternately you can catch the exception and delete the Realm file if it fails to open, but that's clearly not something you want to do for something that stores important data that you only have locally. Also problematic if for example it'd break inside a Realm file on the ROS.
Personally I would expect Realm to be able to detect that a transaction would cause corruption, instead of validating only on start-up after it is too late to do any recovery (as the transaction history is also in the Realm file).
Alternately you can catch the exception and delete the Realm file if it fails to open, but that's clearly not something you want to do for something that stores important data that you only have locally.
Well that's not any solution, except you get rid of the crashes. Not even saying that catching native crashes is problematic.
Personally I would expect Realm to be able to detect that a transaction would cause corruption, instead of validating only on start-up after it is too late to do any recovery (as the transaction history is also in the Realm file).
That could actually be very helpful and maybe a "quickest" solution to the problem, but I still don't understand why these transaction errors occur only on encrypted db's.
I have this crash too. But it's happening on totally correct db and rarely.
Device: OnePlus 3T Android Version: 9.0 Android Studio Version: 3.4.2 Realm Version: 5.10.0
Below is the only code which is causing this:
RealmManagerUtil realmManager = Injector.get().realmManager();
realmManager.runTransaction(new Realm.Transaction() {
@Override
public void execute(@NonNull Realm realm) {
RealmResults<TransactionHistory> results = realm
.where(TransactionHistory.class)
.beginGroup()
.equalTo(TransactionHistory.FIELD_FROM, contactId)
.or()
.equalTo(TransactionHistory.FIELD_TO, contactId)
.endGroup()
.greaterThanOrEqualTo(TransactionHistory.FIELD_SERIAL_NUMBER, Session.NEGATIVE_S_NO_THRESHOLD)
.findAll()
.sort(TransactionHistory.FIELD_SERIAL_NUMBER);
if (results != null && results.size() > 0) {
for (TransactionHistory history : results) {
Long sNo = Session.getAndUpdateSerialNumber();
Logger.showError("WOP-12136 - reassignSNoToLargerSNo - Txn No: " + history.getTransactionNumber() +
", Amount: " + history.getAmount() + ", Old S. No.: " + history.getSerialNumber() + ", New S. No.: " + sNo);
history.setSerialNumber(sNo);
}
}
}
}, new Realm.Transaction.OnSuccess() {
@Override
public void onSuccess() {
if(onSuccess != null) onSuccess.onSuccess();
}
}, new Realm.Transaction.OnError() {
@Override
public void onError(Throwable error) {
}
}, true);
Note: true in last line is indicating that transaction is async.
Below is the crash I am experiencing.
--------- beginning of crash
2019-08-09 10:26:12.014 15580-15881/? A/libc: Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x7b152af000 in tid 15881 (pool-5-thread-8), pid 15580 (o.foree.app.dev)
2019-08-09 10:26:12.148 15889-15889/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
2019-08-09 10:26:12.149 15889-15889/? A/DEBUG: Build fingerprint: 'OnePlus/OnePlus3/OnePlus3T:9/PKQ1.181203.001/1906252001:user/release-keys'
2019-08-09 10:26:12.149 15889-15889/? A/DEBUG: Revision: '0'
2019-08-09 10:26:12.149 15889-15889/? A/DEBUG: ABI: 'arm64'
2019-08-09 10:26:12.149 15889-15889/? A/DEBUG: pid: 15580, tid: 15881, name: pool-5-thread-8 >>> co.foree.app.dev <<<
2019-08-09 10:26:12.149 15889-15889/? A/DEBUG: signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x7b152af000
2019-08-09 10:26:12.149 15889-15889/? A/DEBUG: x0 0000007b152aeff0 x1 0000007b1451e780 x2 0000000000000e30 x3 0000000000000034
2019-08-09 10:26:12.149 15889-15889/? A/DEBUG: x4 0000000034643591 x5 00000000000000c3 x6 00000000000000b9 x7 0000007b19defadc
2019-08-09 10:26:12.149 15889-15889/? A/DEBUG: x8 00000000e600000d x9 0000000000000000 x10 0000007b1451ec80 x11 0000007b152ae6fc
2019-08-09 10:26:12.149 15889-15889/? A/DEBUG: x12 000000000000000a x13 fffffffffffffffa x14 0000000000000cb0 x15 0000000000000002
2019-08-09 10:26:12.149 15889-15889/? A/DEBUG: x16 0000007b1818f308 x17 0000007bb4d9f4b8 x18 00000000000000c2 x19 0000000000000e68
2019-08-09 10:26:12.149 15889-15889/? A/DEBUG: x20 0000007b152ae6f8 x21 000000000002a6f8 x22 000000000002a6f8 x23 0000007b150483a0
2019-08-09 10:26:12.149 15889-15889/? A/DEBUG: x24 0000007b15284000 x25 0000007b1451de48 x26 0000000041414141 x27 0000000000000002
2019-08-09 10:26:12.149 15889-15889/? A/DEBUG: x28 0000007b118f69d0 x29 0000007b118f6860
2019-08-09 10:26:12.149 15889-15889/? A/DEBUG: sp 0000007b118f6040 lr 0000007b180130ac pc 0000007bb4d9f6b8
2019-08-09 10:26:12.202 15889-15889/? A/DEBUG: backtrace:
2019-08-09 10:26:12.202 15889-15889/? A/DEBUG: #00 pc 000000000001f6b8 /system/lib64/libc.so (memcpy+512)
2019-08-09 10:26:12.202 15889-15889/? A/DEBUG: #01 pc 00000000001bd0a8 /data/app/co.foree.app.dev-_JgdodELP-UlOvPDtS2S9A==/lib/arm64/librealm-jni.so
2019-08-09 10:26:12.202 15889-15889/? A/DEBUG: #02 pc 0000000000140ba4 /data/app/co.foree.app.dev-_JgdodELP-UlOvPDtS2S9A==/lib/arm64/librealm-jni.so
2019-08-09 10:26:12.202 15889-15889/? A/DEBUG: #03 pc 0000000000143d70 /data/app/co.foree.app.dev-_JgdodELP-UlOvPDtS2S9A==/lib/arm64/librealm-jni.so
2019-08-09 10:26:12.202 15889-15889/? A/DEBUG: #04 pc 0000000000143d84 /data/app/co.foree.app.dev-_JgdodELP-UlOvPDtS2S9A==/lib/arm64/librealm-jni.so
2019-08-09 10:26:12.202 15889-15889/? A/DEBUG: #05 pc 0000000000143d84 /data/app/co.foree.app.dev-_JgdodELP-UlOvPDtS2S9A==/lib/arm64/librealm-jni.so
2019-08-09 10:26:12.202 15889-15889/? A/DEBUG: #06 pc 00000000001bda8c /data/app/co.foree.app.dev-_JgdodELP-UlOvPDtS2S9A==/lib/arm64/librealm-jni.so
2019-08-09 10:26:12.202 15889-15889/? A/DEBUG: #07 pc 00000000001b91f8 /data/app/co.foree.app.dev-_JgdodELP-UlOvPDtS2S9A==/lib/arm64/librealm-jni.so
2019-08-09 10:26:12.202 15889-15889/? A/DEBUG: #08 pc 00000000001b94a0 /data/app/co.foree.app.dev-_JgdodELP-UlOvPDtS2S9A==/lib/arm64/librealm-jni.so
2019-08-09 10:26:12.202 15889-15889/? A/DEBUG: #09 pc 00000000001bb314 /data/app/co.foree.app.dev-_JgdodELP-UlOvPDtS2S9A==/lib/arm64/librealm-jni.so
2019-08-09 10:26:12.202 15889-15889/? A/DEBUG: #10 pc 000000000011b698 /data/app/co.foree.app.dev-_JgdodELP-UlOvPDtS2S9A==/lib/arm64/librealm-jni.so
2019-08-09 10:26:12.202 15889-15889/? A/DEBUG: #11 pc 00000000001003d8 /data/app/co.foree.app.dev-_JgdodELP-UlOvPDtS2S9A==/lib/arm64/librealm-jni.so
2019-08-09 10:26:12.202 15889-15889/? A/DEBUG: #12 pc 000000000007cc60 /data/app/co.foree.app.dev-_JgdodELP-UlOvPDtS2S9A==/lib/arm64/librealm-jni.so (Java_io_realm_internal_OsSharedRealm_nativeCommitTransaction+48)
2019-08-09 10:26:12.202 15889-15889/? A/DEBUG: #13 pc 000000000056a1e0 /system/lib64/libart.so (art_quick_generic_jni_trampoline+144)
2019-08-09 10:26:12.202 15889-15889/? A/DEBUG: #14 pc 000000000056144c /system/lib64/libart.so (art_quick_invoke_static_stub+604)
2019-08-09 10:26:12.202 15889-15889/? A/DEBUG: #15 pc 00000000000cf6d8 /system/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+232)
2019-08-09 10:26:12.202 15889-15889/? A/DEBUG: #16 pc 0000000000282b00 /system/lib64/libart.so (art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread*, art::ArtMethod*, art::ShadowFrame*, unsigned short, art::JValue*)+344)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #17 pc 000000000027cbb0 /system/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+960)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #18 pc 00000000005317d8 /system/lib64/libart.so (MterpInvokeStatic+200)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #19 pc 0000000000553a14 /system/lib64/libart.so (ExecuteMterpImpl+14612)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #20 pc 000000000039c380 /dev/ashmem/dalvik-classes.dex extracted in memory from /data/app/co.foree.app.dev-_JgdodELP-UlOvPDtS2S9A==/base.apk (deleted) (io.realm.internal.OsSharedRealm.commitTransaction+4)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #21 pc 0000000000256d10 /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadERKNS_20CodeItemDataAccessorERNS_11ShadowFrameENS_6JValueEb.llvm.3399805955+488)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #22 pc 000000000025c8c0 /system/lib64/libart.so (art::interpreter::ArtInterpreterToInterpreterBridge(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*, art::JValue*)+216)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #23 pc 000000000027cb94 /system/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+932)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #24 pc 0000000000530310 /system/lib64/libart.so (MterpInvokeVirtual+576)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #25 pc 0000000000553894 /system/lib64/libart.so (ExecuteMterpImpl+14228)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #26 pc 00000000003842ca /dev/ashmem/dalvik-classes.dex extracted in memory from /data/app/co.foree.app.dev-_JgdodELP-UlOvPDtS2S9A==/base.apk (deleted) (io.realm.BaseRealm.commitTransaction+10)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #27 pc 0000000000256d10 /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadERKNS_20CodeItemDataAccessorERNS_11ShadowFrameENS_6JValueEb.llvm.3399805955+488)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #28 pc 000000000025c8c0 /system/lib64/libart.so (art::interpreter::ArtInterpreterToInterpreterBridge(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*, art::JValue*)+216)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #29 pc 000000000027cb94 /system/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+932)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #30 pc 0000000000530990 /system/lib64/libart.so (MterpInvokeSuper+1396)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #31 pc 0000000000553914 /system/lib64/libart.so (ExecuteMterpImpl+14356)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #32 pc 0000000000396320 /dev/ashmem/dalvik-classes.dex extracted in memory from /data/app/co.foree.app.dev-_JgdodELP-UlOvPDtS2S9A==/base.apk (deleted) (io.realm.Realm.commitTransaction)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #33 pc 0000000000256d10 /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadERKNS_20CodeItemDataAccessorERNS_11ShadowFrameENS_6JValueEb.llvm.3399805955+488)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #34 pc 000000000025c8c0 /system/lib64/libart.so (art::interpreter::ArtInterpreterToInterpreterBridge(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*, art::JValue*)+216)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #35 pc 000000000027cb94 /system/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+932)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #36 pc 0000000000530310 /system/lib64/libart.so (MterpInvokeVirtual+576)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #37 pc 0000000000553894 /system/lib64/libart.so (ExecuteMterpImpl+14228)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #38 pc 000000000038b618 /dev/ashmem/dalvik-classes.dex extracted in memory from /data/app/co.foree.app.dev-_JgdodELP-UlOvPDtS2S9A==/base.apk (deleted) (io.realm.Realm$1.run+116)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #39 pc 0000000000256d10 /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadERKNS_20CodeItemDataAccessorERNS_11ShadowFrameENS_6JValueEb.llvm.3399805955+488)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #40 pc 000000000025c8c0 /system/lib64/libart.so (art::interpreter::ArtInterpreterToInterpreterBridge(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*, art::JValue*)+216)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #41 pc 000000000027cb94 /system/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+932)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #42 pc 0000000000531264 /system/lib64/libart.so (MterpInvokeInterface+1376)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #43 pc 0000000000553a94 /system/lib64/libart.so (ExecuteMterpImpl+14740)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #44 pc 00000000003a16b2 /dev/ashmem/dalvik-classes.dex extracted in memory from /data/app/co.foree.app.dev-_JgdodELP-UlOvPDtS2S9A==/base.apk (deleted) (io.realm.internal.async.BgPriorityRunnable.run+14)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #45 pc 0000000000256d10 /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadERKNS_20CodeItemDataAccessorERNS_11ShadowFrameENS_6JValueEb.llvm.3399805955+488)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #46 pc 000000000025c8c0 /system/lib64/libart.so (art::interpreter::ArtInterpreterToInterpreterBridge(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*, art::JValue*)+216)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #47 pc 000000000027cb94 /system/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+932)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #48 pc 0000000000531264 /system/lib64/libart.so (MterpInvokeInterface+1376)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #49 pc 0000000000553a94 /system/lib64/libart.so (ExecuteMterpImpl+14740)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #50 pc 0000000000112f9c /system/framework/boot-core-oj.vdex (java.util.concurrent.Executors$RunnableAdapter.call+4)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #51 pc 0000000000256d10 /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadERKNS_20CodeItemDataAccessorERNS_11ShadowFrameENS_6JValueEb.llvm.3399805955+488)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #52 pc 000000000025c8c0 /system/lib64/libart.so (art::interpreter::ArtInterpreterToInterpreterBridge(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*, art::JValue*)+216)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #53 pc 000000000027cb94 /system/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+932)
2019-08-09 10:26:12.203 15889-15889/? A/DEBUG: #54 pc 0000000000531264 /system/lib64/libart.so (MterpInvokeInterface+1376)
2019-08-09 10:26:12.204 15889-15889/? A/DEBUG: #55 pc 0000000000553a94 /system/lib64/libart.so (ExecuteMterpImpl+14740)
2019-08-09 10:26:12.204 15889-15889/? A/DEBUG: #56 pc 00000000001137ca /system/framework/boot-core-oj.vdex (java.util.concurrent.FutureTask.run+62)
2019-08-09 10:26:12.204 15889-15889/? A/DEBUG: #57 pc 0000000000256d10 /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadERKNS_20CodeItemDataAccessorERNS_11ShadowFrameENS_6JValueEb.llvm.3399805955+488)
2019-08-09 10:26:12.204 15889-15889/? A/DEBUG: #58 pc 000000000025c8c0 /system/lib64/libart.so (art::interpreter::ArtInterpreterToInterpreterBridge(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*, art::JValue*)+216)
2019-08-09 10:26:12.204 15889-15889/? A/DEBUG: #59 pc 000000000027cb94 /system/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+932)
2019-08-09 10:26:12.204 15889-15889/? A/DEBUG: #60 pc 0000000000531264 /system/lib64/libart.so (MterpInvokeInterface+1376)
2019-08-09 10:26:12.204 15889-15889/? A/DEBUG: #61 pc 0000000000553a94 /system/lib64/libart.so (ExecuteMterpImpl+14740)
2019-08-09 10:26:12.204 15889-15889/? A/DEBUG: #62 pc 00000000001177b0 /system/framework/boot-core-oj.vdex (java.util.concurrent.ThreadPoolExecutor.runWorker+162)
2019-08-09 10:26:12.204 15889-15889/? A/DEBUG: #63 pc 0000000000256d10 /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadERKNS_20CodeItemDataAccessorERNS_11ShadowFrameENS_6JValueEb.llvm.3399805955+488)
2019-08-09 10:26:12.204 15889-15889/? A/DEBUG: #64 pc 000000000025c8c0 /system/lib64/libart.so (art::interpreter::ArtInterpreterToInterpreterBridge(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*, art::JValue*)+216)
2019-08-09 10:26:12.204 15889-15889/? A/DEBUG: #65 pc 000000000027cb94 /system/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+932)
2019-08-09 10:26:12.204 15889-15889/? A/DEBUG: #66 pc 0000000000530310 /system/lib64/libart.so (MterpInvokeVirtual+576)
2019-08-09 10:26:12.204 15889-15889/? A/DEBUG: #67 pc 0000000000553894 /system/lib64/libart.so (ExecuteMterpImpl+14228)
2019-08-09 10:26:12.204 15889-15889/? A/DEBUG: #68 pc 0000000000116ade /system/framework/boot-core-oj.vdex (java.util.concurrent.ThreadPoolExecutor$Worker.run+4)
2019-08-09 10:26:12.204 15889-15889/? A/DEBUG: #69 pc 0000000000256d10 /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadERKNS_20CodeItemDataAccessorERNS_11ShadowFrameENS_6JValueEb.llvm.3399805955+488)
2019-08-09 10:26:12.204 15889-15889/? A/DEBUG: #70 pc 000000000025c8c0 /system/lib64/libart.so (art::interpreter::ArtInterpreterToInterpreterBridge(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*, art::JValue*)+216)
2019-08-09 10:26:12.204 15889-15889/? A/DEBUG: #71 pc 000000000027cb94 /system/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+932)
2019-08-09 10:26:12.204 15889-15889/? A/DEBUG: #72 pc 0000000000531264 /system/lib64/libart.so (MterpInvokeInterface+1376)
2019-08-09 10:26:12.204 15889-15889/? A/DEBUG: #73 pc 0000000000553a94 /system/lib64/libart.so (ExecuteMterpImpl+14740)
2019-08-09 10:26:12.204 15889-15889/? A/DEBUG: #74 pc 00000000000cae46 /system/framework/boot-core-oj.vdex (java.lang.Thread.run+12)
2019-08-09 10:26:12.204 15889-15889/? A/DEBUG: #75 pc 0000000000256d10 /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadERKNS_20CodeItemDataAccessorERNS_11ShadowFrameENS_6JValueEb.llvm.3399805955+488)
2019-08-09 10:26:12.204 15889-15889/? A/DEBUG: #76 pc 0000000000520ad8 /system/lib64/libart.so (artQuickToInterpreterBridge+944)
2019-08-09 10:26:12.204 15889-15889/? A/DEBUG: #77 pc 000000000056a2fc /system/lib64/libart.so (art_quick_to_interpreter_bridge+92)
2019-08-09 10:26:12.204 15889-15889/? A/DEBUG: #78 pc 0000000000561188 /system/lib64/libart.so (art_quick_invoke_stub+584)
2019-08-09 10:26:12.204 15889-15889/? A/DEBUG: #79 pc 00000000000cf6b8 /system/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+200)
2019-08-09 10:26:12.204 15889-15889/? A/DEBUG: #80 pc 0000000000466690 /system/lib64/libart.so (art::(anonymous namespace)::InvokeWithArgArray(art::ScopedObjectAccessAlreadyRunnable const&, art::ArtMethod*, art::(anonymous namespace)::ArgArray*, art::JValue*, char const*)+104)
2019-08-09 10:26:12.204 15889-15889/? A/DEBUG: #81 pc 0000000000467794 /system/lib64/libart.so (art::InvokeVirtualOrInterfaceWithJValues(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jmethodID*, jvalue*)+424)
2019-08-09 10:26:12.204 15889-15889/? A/DEBUG: #82 pc 0000000000492dc8 /system/lib64/libart.so (art::Thread::CreateCallback(void*)+1116)
2019-08-09 10:26:12.204 15889-15889/? A/DEBUG: #83 pc 0000000000099508 /system/lib64/libc.so (__pthread_start(void*)+36)
2019-08-09 10:26:12.204 15889-15889/? A/DEBUG: #84 pc 0000000000023e18 /system/lib64/libc.so (__start_thread+68)
Dear developers, when this bug will be fixed? Or any comment what to do?
So...
The original incident was reported 1 year ago.
The last response from inside Realm was 3 months ago.
No workarounds have been provided.
Judging by the responses of others here, as well as our own experience, this issue does not seem limited to any specific makes, models, or operating system versions.
This issue continues to impact our users. Furthermore, a recent upgrade to realm-gradle-plugin (from 5.11.0 to 5.14.0) introduced different instabilities, forcing us to rollback.
I'm going to take the extraordinary and unfortunate step of completely removing Realm from our codebase. A separate project we recently spun up was planning to use Realm, but decided against it based on the instabilities we've experienced.
@yohanan What instabilities were you guys seeing after that upgrade? Because we also did the same recently and things got even worse here as well. Any crashes to share?
Anyways recently we saw a stacktrace of a native realm crash that occurred immediately after Fresco (our image library) did a com.facebook.imagepipeline.memory.NativeMemoryChunk.nativeFree
so we literally replaced Fresco with Glide just to rule out anything weird happening there.
That wasn't the root issue though since our console is filling up with native crashes again but it just shows how desperate we are :sweat_smile:
I wonder though, if this really is something that only surfaces when encryption is used.
Of course, encryption should just work.
@yohanan What instabilities were you guys seeing after that upgrade? Because we also did the same recently and things got even worse here as well. Any crashes to share?
Anyways recently we saw a stacktrace of a native realm crash that occurred immediately after Fresco (our image library) did a
com.facebook.imagepipeline.memory.NativeMemoryChunk.nativeFree
so we literally replaced Fresco with Glide just to rule out anything weird happening there.That wasn't the root issue though since our console is filling up with native crashes again but it just shows how desperate we are 😅
@EdwardvanRaak the latest instability was found via our functional testing. we run the same tests many times a day, and i happened to make only a change upgrading Realm from 5.11 to 5.14 and the functionals started crashing. going back to 5.11 corrected it.
it is a different issue, as far as i can tell. it is an "invalid mnemonic" error, like the following...
Caused by: io.realm.exceptions.RealmFileException: Unable to open a realm at path '<<redacted>>': Invalid mnemonic. top_ref[0]: 0, top_ref[1]: 11A78, mnemonic: 0 0 0 0, fmt[0]: 0, fmt[1]: 9, flags: 1 Path:. (Invalid mnemonic. top_ref[0]: 0, top_ref[1]: 11A78, mnemonic: 0 0 0 0, fmt[0]: 0, fmt[1]: 9, flags: 1 Path: /<<redacted>>/files/latch.realm) (/data/data/<<redacted>>/files/latch.realm) in /Users/jasonflax/Development/realm-java/realm/realm-library/src/main/cpp/io_realm_internal_OsSharedRealm.cpp line 101 Kind: ACCESS_ERROR. at io.realm.internal.OsSharedRealm.nativeGetSharedRealm(Native Method) at io.realm.internal.OsSharedRealm.<init>(OsSharedRealm.java:171) at io.realm.internal.OsSharedRealm.getInstance(OsSharedRealm.java:241) at io.realm.internal.OsSharedRealm.getInstance(OsSharedRealm.java:231) at io.realm.RealmCache.doCreateRealmOrGetFromCache(RealmCache.java:332) at io.realm.RealmCache.createRealmOrGetFromCache(RealmCache.java:285) at io.realm.Realm.getDefaultInstance(Realm.java:407)
we've been dealing with the db corruption issues for a very long time, and then this new issue reared its head, from a clean install.
I wonder though, if this really is something that only surfaces when encryption is used.
Of course, encryption should just work.
@Zhuinden i also am curious about this. we do enable encryption. in fact, this was one of the main reasons for using Realm. however, having encryption but corrupting your database and having to reinstall the app sort of defeats the purpose. so, yes, i am curious if this is only from encryption.
Yeah we gave up on fixing this issue, we just live with it now. We are planning to eventually move away from realm but it's a big burden. We basically turned realm into a cache layer(removed all sensitive data and put it elsewhere), anytime it corrupts or crashes we simply wipe and restart on the fly. I think this is the only known workaround.
Also I do believe this is a result of using encryption but I'm not completely sure, since we need encryption we accept that its just cache and its fine to delete and start over at any time. Honestly not a great answer, but we paid for support as well and got nowhere...so this is where we ended up.
we've been using Realm for about 2.5+ years. i don't recall this issue until about a year ago, so i wonder if there was some sort of bug introduced in a particular version. the original post cites v5.3.1. i cannot say what version we started seeing it -- it could actually be a combination of a particular Realm version coupled with how we use it changing over time. i do remember a long stretch at the beginning, though, where there were no real issues.
internally, we've been wondering if this has anything to do with Strings. i haven't looked at these crash logs in depth lately, but we seem to only see it as corruption when dealing with Strings. of course, a lot of what we store are Strings, so may be simple probability. was considering migrating all our String properties to byte-arrays, to see if it had any impact. this is cumbersome, sure.
has Realm reached out to anyone? some time ago one of our developers submitted crash logs, corrupted databases, as well as detailed information, but i don't believe we ever heard back from Realm.
Yeah we gave up on fixing this issue, we just live with it now. We are planning to eventually move away from realm but it's a big burden. We basically turned realm into a cache layer(removed all sensitive data and put it elsewhere), anytime it corrupts or crashes we simply wipe and restart on the fly. I think this is the only known workaround.
Also I do believe this is a result of using encryption but I'm not completely sure, since we need encryption we accept that its just cache and its fine to delete and start over at any time. Honestly not a great answer, but we paid for support as well and got nowhere...so this is where we ended up.
@sirivanleo (1) how do you catch these corruption exceptions? since most if not all are coming from the JNI, they are difficult to catch and respond.
(2) in the meantime, what is the mechanism you're using for sensitive info that you moved from Realm.
(3) when you move from Realm, what is your longterm approach for an encrypted db?
@theverybest @jbkielis @mariusmorabosch @waqas-ansari Do you guys also have encryption enabled?
Because I could let some of my users try an unencrypted realm file (and solve the security aspect differently) for a while to absolutely confirm that this is the issue.
@yohanan @sirivanleo Are you using external storage to hold your db files? As far as i know Android makes sure internal storage for each app has very restricted access - only available for an app. Unless the user roots the device or you enable "backup" for your app you can't really get access the data outside of a package. So there should not be a very need to have an encryption over DB. What do you think?
@yohanan
(1) how do you catch these corruption exceptions? since most if not all are coming from the JNI, they are difficult to catch and respond.
You pretty much can't.
We put a number of validating realm transactions and the realm init code around this wrapper:
@SuppressLint("ApplySharedPref")
fun <T> safeExecute(block: () -> T): T {
sharedPreferences.edit().putInt(REALM_VALIDATION, FLAG_START).commit()
val result = block()
sharedPreferences.edit().putInt(REALM_VALIDATION, FLAG_END).commit()
return result
}
Then on startup we delete the realm files if the FLAG_END
was not hit. It's not pretty but it works for native crashes triggered during startup. At least sometimes our users can continue rather than uninstall the app. But the corruption sometimes happens on a single field, or during background syncs and then your pretty much screwed (unless you use a timer approach).
Also, cmelchior mentioned that reading the corrupt string field on javascript does not cause a crash but silently fails, so I'm wondering how javascript is able to do that.
@EdwardvanRaak Yes, we use Realm with encryption enabled - that was one of the reasons for choosing Realm database.
I just want to assure everyone that this issue is definitely something we are very concerned about. It's increasingly annoying that we have been unsuccessful in reproducing the issue, and hence get a chance to fix it. The issue can be within Realm, which is totally likely, but it could also be in Android or specific implementations or devices. The interesting part is that we don't see the same issue in iOS and JS, which could indicate this is related to the Android SDK alone and not the Core database. But the Android SDK doesn't do things that should make it possible to corrupt the database in any way, which may hint of the issue being in the platform or specific implementations of it. We know this doesn't help in any way, but please continue reporting this issue as it can help us to see patterns. When reporting it, please include all details. Thanks for the patience and you help!
Goal
Expected Results
Actual Results
So far, only one known user has encountered this issue. This user will encounter the crash every time they launch the app. Fortunately, I have access to the user's device and have hooked it up to the debugger. There seems to be 3
RealmObject
s (all of the sameChildObject
type described below) out of hundreds which have somehow corrupted, and trying to access any of these 3 objects will seg fault. I've tried accessing these objects w/in aDynamicRealm
, but that seg faults as well.Although the stacktrace above happens on a
RxComputation
thread, when I run everything on the main thread, the crash persists.Code Sample
Unfortunately I can't share specific code or realm files, but I'll describe the relevant schema structure and access which is causing the crash.
Version of Realm and tooling
Realm version(s): 5.3.1 w/encryption enabled
Realm sync feature enabled: no
Android Studio version: 3.1.3
Which Android version and device: Samsung Galaxy S8 running Android 8