Realm-java: Fatal signal 11 (SIGSEGV) from Java_io_realm_internal_UncheckedRow_nativeGetString

[bfichter]

Goal

No crashes

Expected Results

No crashes

Actual Results

Crashing consistently for one affected user w/a seemingly corrupted DB state

A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
    Build fingerprint: 'samsung/dreamqltesq/dreamqltesq:8.0.0/R16NW/G950USQU5CRG3:user/release-keys'
    Revision: '12'
    ABI: 'arm64'
A/DEBUG: pid: 27327, tid: 27372, name: RxComputationTh  >>> com.preveil.preveil <<<
    signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x78713fe000
        x0   00000078704e4380  x1   00000078704e437f  x2   0000007871254317  x3   00000078704e43d8
        x4   00000078704e4380  x5   000000786f5a9d7d  x6   0000000000000000  x7   0000000000000000
        x8   0000000000000000  x9   0000000000000000  x10  0000000000000001  x11  0000000000000000
        x12  000000786fc05210  x13  0000000001000000  x14  0000000000000000  x15  0000000000000000
        x16  000000787380e570  x17  000000788e181970  x18  0000000000000020  x19  00000078704e4380
        x20  000000787376a000  x21  00000078704e4540  x22  00000078713fe000  x23  00000078704e4380
        x24  00000078704e437f  x25  0000000000000001  x26  00000078704e4568  x27  00000078704e45d0
        x28  00000078704e4570  x29  00000078704e42f0  x30  00000078735424e0
        sp   00000078704e42f0  pc   00000078735424cc  pstate 0000000020000000
09-04 11:23:56.963 27385-27385/? A/DEBUG: backtrace:
        #00 pc 000000000003b4cc  /data/app/com.preveil.preveil-FG01oMB2aWtfSFb4Aipq1w==/lib/arm64/librealm-jni.so
        #01 pc 00000000000be5d8  /data/app/com.preveil.preveil-FG01oMB2aWtfSFb4Aipq1w==/lib/arm64/librealm-jni.so
        #02 pc 00000000000b6f28  /data/app/com.preveil.preveil-FG01oMB2aWtfSFb4Aipq1w==/lib/arm64/librealm-jni.so (Java_io_realm_internal_UncheckedRow_nativeGetString+92)
        #03 pc 0000000000510d00  /system/lib64/libart.so (art_quick_generic_jni_trampoline+144)
        #04 pc 000000000000f8bc  /dev/ashmem/dalvik-jit-code-cache_27327_27327 (deleted)

Steps & Code to Reproduce

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 RealmObjects (all of the same ChildObject 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 a DynamicRealm, 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.

open class ParentObject : RealmObject() {
    @PrimaryKey
    var identifier = UUID.randomUUID().toString()
    var children = RealmList<ChildObject>()
    // other properties
}

open class ChildObject : RealmObject() {
    @PrimaryKey
    var identifier = UUID.randomUUID().toString()
    // other properties
}

// Elsewhere, on app launch
val parents = Realm.getDefaultInstance().where(ParentObject::class.java).findAll()
parents.forEach { parentObject ->
    parentObject.children.forEach { childObject ->
        // For hundreds of ChildObjects, this is totally fine
        // But for 3 seemingly corrupted objects, this seg faults
        val property = childObject.property
    }
}

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

[Zey-Uzh]

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.

``` --------- beginning of crash
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](https://github.com/realm/realm-java/files/2375802/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

[vladimirfx]

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

[mussa-ibragimov]

This is happening on Samsung Galaxy S7 edge (hero2lte), Android 8.0

[ggajews]

Any updates on this? We have many reports on 5.7.1 with encryption enabled, but can't reproduce it locally.

[vladimirfx]

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.

[vladimirfx]

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 :(

[bmunkholm]

@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.

[bmunkholm]

@Zey-Uzh While it's very useful to get the database that appears corrupt, we need the encryption key to actually open it :-)

[ggajews]

@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

[vladimirfx]

@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...

[cmelchior]

@vladimirfx You can send it to [email protected]

But having a DB that throws this error would be a massive help (and a pointer to which object actually throws the error).

[vladimirfx]

Corrupted DB emailed to [email protected]

[cmelchior]

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)

[vladimirfx]

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.

[vladimirfx]

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.

[cmelchior]

That would be great. Thank you 👏

[cmelchior]

@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.

[vladimirfx]

I was sent another corrupted db from Android 9 device. It's crashes on database opening.
crush_log.txt

[ggajews]

@cmelchior any progress in debugging this issue?

[sirivanleo]

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

[jbkielis]

We are running into the same issue. Any updates or ideas from the Realm team? Thanks.

[mariusmorabosch]

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

[vladimirfx]

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...

[EdwardvanRaak]

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?

[Zhuinden]

Realm schema file format upgrades are not backwards compatible.

[bmunkholm]

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.

[vladimirfx]

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.

[bmunkholm]

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?

[vladimirfx]

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.

[bmunkholm]

@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?

[ggajews]

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

[xMickeymikex]

@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

[EdwardvanRaak]

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.

[Zhuinden]

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).

[xMickeymikex]

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.

[waqas-ansari]

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)

[theverybest]

Dear developers, when this bug will be fixed? Or any comment what to do?

[yohanan]

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.

[EdwardvanRaak]

@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:

[Zhuinden]

I wonder though, if this really is something that only surfaces when encryption is used.

Of course, encryption should just work.

[yohanan]

@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.

[yohanan]

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.

[sirivanleo]

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.

[yohanan]

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.

[yohanan]

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?

[EdwardvanRaak]

@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.

[xMickeymikex]

@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?

[EdwardvanRaak]

@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.

[theverybest]

@EdwardvanRaak
Yes, we use Realm with encryption enabled - that was one of the reasons for choosing Realm database.

[bmunkholm]

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!

[EdwardvanRaak]

We will start logging every realm transaction to Firebase NDK Crashlytics so we can see exactly what steps lead to these crashes. I hope other people will do the same so we can discover patterns.

[Waboodoo]

I have no real data on this, but in our case the corruption of the Realm file appears to mainly happen when commiting a Realm transaction from a background service, in our case via Firebase Cloud Messaging. I could imagine that maybe the Android OS is interrupting the process if the writing to the file system keeps the service running for too long. I was not able to verify this suspicion though so far.

[yohanan]

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.

thanks for the reply @bmunkholm. a few things i have asked in the past...

(1) have you reached out to any of the folks here that have been experiencing the issue? i'm sure some of us can lend a hand in reproducing the issue, beyond simply reporting crashes into the silent void. we could, for example, make adjustments to our app in our non-production environments to test different approaches.

(2) do you suspect there is a particular Realm release where this issue might have been introduced? there is some point where this issue started showing up, no?

[bmunkholm]

Hi @yohanan
(1) Yes we have been getting realm files shared in private via support. We have however not been in touch with anyone who is able to easily replicate this issue in a non-production environment. If anyone is able to replicate this issue, we would be very thrilled and happy to work with you to troubleshoot this. Apart from what we have done with adding more asserts, it's not clear what else we can actually do.
We are currently working hard on getting Core6 out, and although we have no concrete reasons to believe it should change anything, a lot has changed so there might be a vague hope it's for the better in this case as well.

(2) Unfortunately, this issue has been coming and going over a very long period, so there is no particular recent version this was introduced.

[vladimirfx]

1) I've been writen early this year (here + in private support ticket) that we can reprocude bug in out test env. Moreover I've requested 'special' distribution version of Realm. Still wayting for such build in private ticket 3321.

Also we checked (requested by Robert Oberhofer) version 5.15.1 - bug reproduced.

[EdwardvanRaak]

@vladimirfx If you you can reproduce it from a clean state why don't you run the test 100 times with every realm step logged, or is it really that random to reproduce? Surely there must be some pattern you can discover yourself in that case?

Or try to disable deletions, background syncs, certain queries, etc. Until the problem does not occur anymore.

[bmunkholm]

Hi @vladimirfx
1) As Robert asked in the private support ticket (https://realm.freshdesk.com/a/tickets/3321 for internal reference), are you also able to reproduce with 5.15.2?
2) How reliable are you able to do that?
3) What does the repro do?
4) Does it use Sync?
5) Once you can repro it with some confidence, can you try to disable encryption?

Thanks!
(As we so far have little clues where to look, the only meaningful special version we could make would be one with debug assertions turned on. I'll get that done.)

[vladimirfx]

1. Reproduced on 5.15.2. Tryed to load data from our server - 3 crashes of 3 attempts.
2. 100%, 5 devices from different vendors - Honor, Xiaomi, Lenovo.
3. Crash happend when our application receive data from server. Is a custom sync mechanism that writes data in portions (~50 rows per transaction). In parallel different data is requested by views by mean of RxJava subscriptions. First crash happend on read thread. But database is corrupted when writen. If disable read subscription and wait sync copmlete - any read from big table will reproduce crash. Table contains about 25 colums and ~1200 rows (on moment of crash about 350). Realm 5.3.1 works with crash probability of 10%. After 5.9.1 there is no chance to sync our tipical data set (100% crash).
4. No, Realm Sync not used.
5. No, this issues is not reproducable with disabled encryption. But is not option for us. Actualy Realm is choosen for embedded encryption, so no encryption - no Realm.

[cmelchior]

@vladimirfx Thank you very much for the information. I'll try to produce a special release of Realm with all our assertions enabled you can try out. Hopefully, that can reveal something.

[bmunkholm]

That's awesome @vladimirfx!

1. Is there any way we can get your application so we can troubleshoot ourself (we likely will need a lot of iterations with new debug versions)?
2. Alternatively, can you try reducing your application down to something that we can replicate?
   I.e. mock your external sync. Just generate static data instead?
3. Can you replicate with an emulator instead of real device?
   Basically we need to remove some of the variables and reduce the problem to something we can replicate.

[cmelchior]

@vladimirfx I created a special release with more assertions enabled. It is called 6.0.0-DEBUG-ASSERTS-SNAPSHOT

You will need to add the following to your list of maven repos:

        maven {
            url 'http://oss.jfrog.org/artifactory/oss-snapshot-local'
        }

As described here: https://github.com/realm/realm-java#using-snapshots

[bmunkholm]

Don't be surprised that this will run very slowly... :-)

[Zhuinden]

(but does 6.0 introduce file format changes?)

[cmelchior]

No, 6.0 only breaks some Sync API's: https://github.com/realm/realm-java/blob/master/CHANGELOG.md#6002019-10-01

7.0 will contain the Core 6 upgrade which will change the file format.

[cmelchior]

@vladimirfx Did you have a chance to test out the SNAPSHOT?

[vladimirfx]

Logcat output attached. Do you need something else?

crush_report_realm_honor.log
crush_report_realm_xiaomi.log

[bmunkholm]

@vladimirfx Could you reply to my questions above - thanks!

[finnschiermer]

@vladimirfx With regards to the "crush_report_realm_honor.log" attached above: Are there other threads in action on the device when the crash occurs?

If there is, could you provide backtraces for all those other threads?

While we only see this when encryption is enabled, it is also the case that encryption slows down reading and especially writing to the database. Such changes in timing can sometimes expose other bugs, which are not really bugs in the encryption layer, but timing dependent in such a way, that they don't surface without encryption.

[vladimirfx]

That's awesome @vladimirfx!

1. Is there any way we can get your application so we can troubleshoot ourself (we likely will need a lot of iterations with new debug versions)?

Unfortunately no - it is secured proprietary software with a lot of sensitive data.

2. Alternatively, can you try reducing your application down to something that we can replicate?
   I.e. mock your external sync. Just generate static data instead?

May be. It's a lot of work: iteratively cut down app to where bug is reproducible but app code is minimal enough. I should approve such activity with our customer.

3. Can you replicate with an emulator instead of real device?

It's very rarely reproducible on emulator.

   Basically we need to remove some of the variables and reduce the problem to something we can replicate.

[vladimirfx]

@fealebenpae it is native crash and thread dump not so easy to collect. But we all try...

[cmelchior]

@vladimirfx So, you are saying you do see the same error on emulators (although rarely)? That is the x86 emulator right?

[vladimirfx]

@cmelchior yes, x86

[cmelchior]

Hutlihut (sorry non-danes: https://www.youtube.com/watch?v=QdFK6VbuIC0)

I managed to reproduce in an isolated unit test on an x86 emulator:

    // Attempts to reproduce https://github.com/realm/realm-java/issues/6152
    @Test
    @RunTestInLooperThread
    public void encryption_stressTest() {
        final int WRITER_THREADS = 20;
        final int TEST_OBJECTS = 100_000;
        final int MAX_STRING_LENGTH = 1000;
        final AtomicInteger id = new AtomicInteger(0);
        final CountDownLatch writersDone = new CountDownLatch(WRITER_THREADS);
        final CountDownLatch mainReaderDone = new CountDownLatch(1);
        long seed = System.nanoTime();
        RealmLog.info("Starting test with seed: " + seed);
        Random random = new Random(seed);

        final RealmConfiguration config = new RealmConfiguration.Builder() //.configFactory.createConfigurationBuilder()
                .name("stress-test.realm")
                .encryptionKey(TestHelper.getRandomKey(seed))
                .build();
        Realm.getInstance(config).close();

        for (int i = 0; i < WRITER_THREADS; i++) {
            new Thread(new Runnable() {
                @Override
                public void run() {
                    Realm realm = Realm.getInstance(config);
                    realm.executeTransaction(r -> {
                        for (int j = 0; j < (TEST_OBJECTS / WRITER_THREADS); j++) {
                            AllJavaTypes obj = new AllJavaTypes(id.incrementAndGet());
                            obj.setFieldString(TestHelper.getRandomString(random.nextInt(MAX_STRING_LENGTH)));
                            r.insert(obj);
                        }
                    });
                    realm.close();
                    writersDone.countDown();
                }
            }).start();
        }

        Realm realm = Realm.getInstance(config);
        looperThread.closeAfterTest(realm);
        RealmResults<AllJavaTypes> results = realm.where(AllJavaTypes.class).findAllAsync();
        looperThread.keepStrongReference(results);
        results.addChangeListener(new OrderedRealmCollectionChangeListener<RealmResults<AllJavaTypes>>() {
            @Override
            public void onChange(RealmResults<AllJavaTypes> results, OrderedCollectionChangeSet changeSet) {
                for (AllJavaTypes obj : results) {
                    String s = obj.getFieldString();
                }

                if (results.size() == TEST_OBJECTS) {
                    realm.close();
                    mainReaderDone.countDown();
                }
            }
        });

        Thread t = new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    writersDone.await();
                    mainReaderDone.await();
                } catch (InterruptedException e) {
                    fail(e.toString());
                }
                looperThread.testComplete();
            }
        });
        looperThread.keepStrongReference(t);
        t.start();
    }

Stacktrace:

2019-10-08 19:16:57.717 14445-14474/io.realm.test A/libc: Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0xd4cc0000 in tid 14474 (RunTestInLooper), pid 14445 (io.realm.test)
2019-10-08 19:16:57.759 14522-14522/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
2019-10-08 19:16:57.759 14522-14522/? A/DEBUG: Build fingerprint: 'google/sdk_gphone_x86/generic_x86:9/PSR1.180720.093/5456446:userdebug/dev-keys'
2019-10-08 19:16:57.759 14522-14522/? A/DEBUG: Revision: '0'
2019-10-08 19:16:57.759 14522-14522/? A/DEBUG: ABI: 'x86'
2019-10-08 19:16:57.759 14522-14522/? A/DEBUG: pid: 14445, tid: 14474, name: RunTestInLooper  >>> io.realm.test <<<
2019-10-08 19:16:57.759 14522-14522/? A/DEBUG: signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0xd4cc0000
2019-10-08 19:16:57.759 14522-14522/? A/DEBUG:     eax d473902f  ebx d6d1dd64  ecx d653bc74  edx d6d12acc
2019-10-08 19:16:57.759 14522-14522/? A/DEBUG:     edi d653ba8c  esi d4cc0000
2019-10-08 19:16:57.759 14522-14522/? A/DEBUG:     ebp d653bb58  esp d653ba70  eip d66aa5f2
2019-10-08 19:16:57.876 14522-14522/? A/DEBUG: backtrace:
2019-10-08 19:16:57.876 14522-14522/? A/DEBUG:     #00 pc 0016a5f2  /data/app/io.realm.test-oAB4AdGBdcp3-4nV76wAjA==/lib/x86/librealm-jni.so (string_to_hex(std::string const&, realm::StringData&, char const*, char const*, unsigned short*, unsigned short*, unsigned int, unsigned int)+264)
2019-10-08 19:16:57.876 14522-14522/? A/DEBUG:     #01 pc 0016b16f  /data/app/io.realm.test-oAB4AdGBdcp3-4nV76wAjA==/lib/x86/librealm-jni.so (to_jstring(_JNIEnv*, realm::StringData)+1471)
2019-10-08 19:16:57.876 14522-14522/? A/DEBUG:     #02 pc 0015c0ae  /data/app/io.realm.test-oAB4AdGBdcp3-4nV76wAjA==/lib/x86/librealm-jni.so (Java_io_realm_internal_UncheckedRow_nativeGetString+574)
2019-10-08 19:16:57.876 14522-14522/? A/DEBUG:     #03 pc 000151a0  /dev/ashmem/dalvik-jit-code-cache (deleted) (io.realm.internal.UncheckedRow.nativeGetString+144)
2019-10-08 19:16:57.876 14522-14522/? A/DEBUG:     #04 pc 00012725  /dev/ashmem/dalvik-jit-code-cache (deleted) (io.realm.internal.UncheckedRow.getString+69)
2019-10-08 19:16:57.876 14522-14522/? A/DEBUG:     #05 pc 00012671  /dev/ashmem/dalvik-jit-code-cache (deleted) (io.realm.io_realm_entities_AllJavaTypesRealmProxy.realmGet$fieldString+161)
2019-10-08 19:16:57.876 14522-14522/? A/DEBUG:     #06 pc 00013c49  /dev/ashmem/dalvik-jit-code-cache (deleted) (io.realm.entities.AllJavaTypes.getFieldString+41)
2019-10-08 19:16:57.876 14522-14522/? A/DEBUG:     #07 pc 00013e46  /dev/ashmem/dalvik-jit-code-cache (deleted) (io.realm.RealmTests$67.onChange+182)

Also seeing this assertion failure:

/home/jenkins/workspace/realm_realm-core_release_5.23.5@2/src/realm/alloc_slab.cpp:1233: [realm-core-5.23.5] Assertion failed: matches_section_boundary(file_size)

This unit test does indeed create a large number of both writer and reader threads.

Further observations:

• Removing the changelistener from the main thread does not the crash, i.e. the reader threads work.
• Saving all data in one write transaction prevents the crash
• 100.000 objects with string length 1.000 crashes. 1.000.000 objects with string length 100 does not. 1.000 objects with string length 1.000 does not crash. 10.000.000 objects with string length 100 does not crash.
• Multiple write transactions on the same Realm instance on the same thread crashes with a slightly different error:

2019-10-08 23:25:07.538 20231-20231/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
2019-10-08 23:25:07.538 20231-20231/? A/DEBUG: Build fingerprint: 'google/sdk_gphone_x86/generic_x86:9/PSR1.180720.093/5456446:userdebug/dev-keys'
2019-10-08 23:25:07.538 20231-20231/? A/DEBUG: Revision: '0'
2019-10-08 23:25:07.538 20231-20231/? A/DEBUG: ABI: 'x86'
2019-10-08 23:25:07.538 20231-20231/? A/DEBUG: pid: 20192, tid: 20220, name: RunTestInLooper  >>> io.realm.test <<<
2019-10-08 23:25:07.538 20231-20231/? A/DEBUG: signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
2019-10-08 23:25:07.538 20231-20231/? A/DEBUG:     eax 00000000  ebx 00004ee0  ecx 00004efc  edx 00000006
2019-10-08 23:25:07.538 20231-20231/? A/DEBUG:     edi 00004ee0  esi f33b62a8
2019-10-08 23:25:07.538 20231-20231/? A/DEBUG:     ebp d653b6d8  esp d653b608  eip f7310b39
2019-10-08 23:25:07.636 20231-20231/? A/DEBUG: backtrace:
2019-10-08 23:25:07.636 20231-20231/? A/DEBUG:     #00 pc 00000b39  [vdso:f7310000] (__kernel_vsyscall+9)
2019-10-08 23:25:07.636 20231-20231/? A/DEBUG:     #01 pc 0001fdf8  /system/lib/libc.so (syscall+40)
2019-10-08 23:25:07.636 20231-20231/? A/DEBUG:     #02 pc 00022ed3  /system/lib/libc.so (abort+115)
2019-10-08 23:25:07.636 20231-20231/? A/DEBUG:     #03 pc 005de414  /data/app/io.realm.test-jOcLv55p07ug14CfJ3a4vw==/lib/x86/librealm-jni.so (__gnu_cxx::__verbose_terminate_handler()+452)
2019-10-08 23:25:07.636 20231-20231/? A/DEBUG:     #04 pc 005a6fa7  /data/app/io.realm.test-jOcLv55p07ug14CfJ3a4vw==/lib/x86/librealm-jni.so (__cxxabiv1::__terminate(void (*)())+23)
2019-10-08 23:25:07.636 20231-20231/? A/DEBUG:     #05 pc 005de085  /data/app/io.realm.test-jOcLv55p07ug14CfJ3a4vw==/lib/x86/librealm-jni.so (__cxa_call_terminate+69)
2019-10-08 23:25:07.636 20231-20231/? A/DEBUG:     #06 pc 005a6701  /data/app/io.realm.test-jOcLv55p07ug14CfJ3a4vw==/lib/x86/librealm-jni.so (__gxx_personality_v0+321)
2019-10-08 23:25:07.636 20231-20231/? A/DEBUG:     #07 pc 005f14d8  /data/app/io.realm.test-jOcLv55p07ug14CfJ3a4vw==/lib/x86/librealm-jni.so (_Unwind_RaiseException_Phase2+140)
2019-10-08 23:25:07.636 20231-20231/? A/DEBUG:     #08 pc 005f1926  /data/app/io.realm.test-jOcLv55p07ug14CfJ3a4vw==/lib/x86/librealm-jni.so (_Unwind_Resume+92)
2019-10-08 23:25:07.636 20231-20231/? A/DEBUG:     #09 pc 001e88ee  /data/app/io.realm.test-jOcLv55p07ug14CfJ3a4vw==/lib/x86/librealm-jni.so (realm::util::do_encryption_read_barrier(void const*, unsigned int, unsigned int (*)(char const*), realm::util::EncryptedFileMapping*)+110)
2019-10-08 23:25:07.636 20231-20231/? A/DEBUG:     #10 pc 001e8855  /data/app/io.realm.test-jOcLv55p07ug14CfJ3a4vw==/lib/x86/librealm-jni.so (realm::util::encryption_read_barrier(void const*, unsigned int, realm::util::EncryptedFileMapping*, unsigned int (*)(char const*))+44)
2019-10-08 23:25:07.636 20231-20231/? A/DEBUG:     #11 pc 001ec03a  /data/app/io.realm.test-jOcLv55p07ug14CfJ3a4vw==/lib/x86/librealm-jni.so (realm::SlabAlloc::do_translate(unsigned int) const+1020)
2019-10-08 23:25:07.636 20231-20231/? A/DEBUG:     #12 pc 000cf474  /data/app/io.realm.test-jOcLv55p07ug14CfJ3a4vw==/lib/x86/librealm-jni.so (realm::ArrayBigBlobs::get(char const*, unsigned int, realm::Allocator&)+136)
2019-10-08 23:25:07.636 20231-20231/? A/DEBUG:     #13 pc 0050e4b1  /data/app/io.realm.test-jOcLv55p07ug14CfJ3a4vw==/lib/x86/librealm-jni.so (realm::ArrayBigBlobs::get_string(char const*, unsigned int, realm::Allocator&, bool)+57)
2019-10-08 23:25:07.636 20231-20231/? A/DEBUG:     #14 pc 0050f498  /data/app/io.realm.test-jOcLv55p07ug14CfJ3a4vw==/lib/x86/librealm-jni.so (realm::StringColumn::get(unsigned int) const+632)
2019-10-08 23:25:07.636 20231-20231/? A/DEBUG:     #15 pc 0048d031  /data/app/io.realm.test-jOcLv55p07ug14CfJ3a4vw==/lib/x86/librealm-jni.so (realm::StringData realm::Table::get<realm::StringData>(unsigned int, unsigned int) const+421)
2019-10-08 23:25:07.636 20231-20231/? A/DEBUG:     #16 pc 0015c092  /data/app/io.realm.test-jOcLv55p07ug14CfJ3a4vw==/lib/x86/librealm-jni.so (Java_io_realm_internal_UncheckedRow_nativeGetString+546)
2019-10-08 23:25:07.636 20231-20231/? A/DEBUG:     #17 pc 00014d20  /dev/ashmem/dalvik-jit-code-cache (deleted) (io.realm.internal.UncheckedRow.nativeGetString+144)
2019-10-08 23:25:07.636 20231-20231/? A/DEBUG:     #18 pc 000123c5  /dev/ashmem/dalvik-jit-code-cache (deleted) (io.realm.internal.UncheckedRow.getString+69)
2019-10-08 23:25:07.636 20231-20231/? A/DEBUG:     #19 pc 00012321  /dev/ashmem/dalvik-jit-code-cache (deleted) (io.realm.io_realm_entities_AllJavaTypesRealmProxy.realmGet$fieldString+161)
2019-10-08 23:25:07.636 20231-20231/? A/DEBUG:     #20 pc 000134a9  /dev/ashmem/dalvik-jit-code-cache (deleted) (io.realm.entities.AllJavaTypes.getFieldString+41)
2019-10-08 23:25:07.636 20231-20231/? A/DEBUG:     #21 pc 00013881  /dev/ashmem/dalvik-jit-code-cache (deleted) (io.realm.RealmTests$66.onChange+193)

This matches the different kinds we seen so far.

[vladimirfx]

That's good. But our app make writes in one thread and open few subscriptions (changelistener) depending on active screen.
My observations:

1. Writes may complete successfully. Crash happens on any read on written data (even after restart). So there is no correlation with active changelistener actually (in our case).
   2 Crash is highly depends on "width" of one row - entity with 15+ String field (5-40 chars each) is enough to reproduce it.

[cmelchior]

New Stacktrace while trying to reproduce:

2019-10-09 07:32:50.314 31553-32273/? E/REALM: /Users/cm/Realm/realm-core/src/realm/alloc_slab.cpp:1233: [realm-core-5.23.5] Assertion failed: matches_section_boundary(file_size)
    <backtrace not supported on this platform>!!! IMPORTANT: Please send this log and info about Realm SDK version and other relevant reproduction info to [email protected].
2019-10-09 07:32:50.314 31553-32273/? A/libc: Fatal signal 6 (SIGABRT), code -6 (SI_TKILL) in tid 32273 (Thread-31), pid 31553 (io.realm.test)
2019-10-09 07:32:50.375 32278-32278/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
2019-10-09 07:32:50.375 32278-32278/? A/DEBUG: Build fingerprint: 'google/sdk_gphone_x86/generic_x86:9/PSR1.180720.093/5456446:userdebug/dev-keys'
2019-10-09 07:32:50.375 32278-32278/? A/DEBUG: Revision: '0'
2019-10-09 07:32:50.375 32278-32278/? A/DEBUG: ABI: 'x86'
2019-10-09 07:32:50.375 32278-32278/? A/DEBUG: pid: 31553, tid: 32273, name: Thread-31  >>> io.realm.test <<<
2019-10-09 07:32:50.375 32278-32278/? A/DEBUG: signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
2019-10-09 07:32:50.375 32278-32278/? A/DEBUG:     eax 00000000  ebx 00007b41  ecx 00007e11  edx 00000006
2019-10-09 07:32:50.375 32278-32278/? A/DEBUG:     edi 00007b41  esi d5c75d60
2019-10-09 07:32:50.375 32278-32278/? A/DEBUG:     ebp d6c5cd64  esp d1b6c618  eip f7310b39
2019-10-09 07:32:50.444 32278-32278/? A/DEBUG: backtrace:
2019-10-09 07:32:50.444 32278-32278/? A/DEBUG:     #00 pc 00000b39  [vdso:f7310000] (__kernel_vsyscall+9)
2019-10-09 07:32:50.444 32278-32278/? A/DEBUG:     #01 pc 0001fdf8  /system/lib/libc.so (syscall+40)
2019-10-09 07:32:50.444 32278-32278/? A/DEBUG:     #02 pc 00022ed3  /system/lib/libc.so (abort+115)
2019-10-09 07:32:50.444 32278-32278/? A/DEBUG:     #03 pc 004eab80  /data/app/io.realm.test-6UraDbkP-SslvrspPDlHog==/lib/x86/librealm-jni.so (please_report_this_error_to_help_at_realm_dot_io+23)
2019-10-09 07:32:50.444 32278-32278/? A/DEBUG:     #04 pc 004eacea  /data/app/io.realm.test-6UraDbkP-SslvrspPDlHog==/lib/x86/librealm-jni.so (realm::util::terminate_internal(std::basic_stringstream<char, std::char_traits<char>, std::allocator, <char>>&)+306)
2019-10-09 07:32:50.444 32278-32278/? A/DEBUG:     #05 pc 004eadcb  /data/app/io.realm.test-6UraDbkP-SslvrspPDlHog==/lib/x86/librealm-jni.so (realm::util::terminate(char const*, char const*, long, std::initializer_list<realm::util::Printable>&&)+224)
2019-10-09 07:32:50.444 32278-32278/? A/DEBUG:     #06 pc 001eef80  /data/app/io.realm.test-6UraDbkP-SslvrspPDlHog==/lib/x86/librealm-jni.so (realm::SlabAlloc::update_reader_view(unsigned int)+490)
2019-10-09 07:32:50.444 32278-32278/? A/DEBUG:     #07 pc 00393742  /data/app/io.realm.test-6UraDbkP-SslvrspPDlHog==/lib/x86/librealm-jni.so (realm::Group::remap_and_update_refs(unsigned int, unsigned int)+56)
2019-10-09 07:32:50.444 32278-32278/? A/DEBUG:     #08 pc 0039d90d  /data/app/io.realm.test-6UraDbkP-SslvrspPDlHog==/lib/x86/librealm-jni.so (realm::_impl::GroupFriend::remap_and_update_refs(realm::Group&, unsigned int, unsigned int)+43)
2019-10-09 07:32:50.444 32278-32278/? A/DEBUG:     #09 pc 003a3715  /data/app/io.realm.test-6UraDbkP-SslvrspPDlHog==/lib/x86/librealm-jni.so (realm::SharedGroup::commit_and_continue_as_read()+253)
2019-10-09 07:32:50.444 32278-32278/? A/DEBUG:     #10 pc 001cd194  /data/app/io.realm.test-6UraDbkP-SslvrspPDlHog==/lib/x86/librealm-jni.so (realm::_impl::transaction::commit(realm::SharedGroup&)+29)
2019-10-09 07:32:50.444 32278-32278/? A/DEBUG:     #11 pc 001c44e0  /data/app/io.realm.test-6UraDbkP-SslvrspPDlHog==/lib/x86/librealm-jni.so (realm::_impl::RealmCoordinator::commit_write(realm::Realm&)+200)
2019-10-09 07:32:50.444 32278-32278/? A/DEBUG:     #12 pc 0019f475  /data/app/io.realm.test-6UraDbkP-SslvrspPDlHog==/lib/x86/librealm-jni.so (realm::Realm::commit_transaction()+361)
2019-10-09 07:32:50.444 32278-32278/? A/DEBUG:     #13 pc 000f98be  /data/app/io.realm.test-6UraDbkP-SslvrspPDlHog==/lib/x86/librealm-jni.so (Java_io_realm_internal_OsSharedRealm_nativeCommitTransaction+251)
2019-10-09 07:32:50.444 32278-32278/? A/DEBUG:     #14 pc 005f6b97  /system/lib/libart.so (art_quick_generic_jni_trampoline+71)
2019-10-09 07:32:50.445 32278-32278/? A/DEBUG:     #15 pc 00071852  /dev/ashmem/dalvik-jit-code-cache (deleted) (io.realm.internal.OsSharedRealm.commitTransaction+50)
2019-10-09 07:32:50.445 32278-32278/? A/DEBUG:     #16 pc 00071fd4  /dev/ashmem/dalvik-jit-code-cache (deleted) (io.realm.BaseRealm.commitTransaction+68)
2019-10-09 07:32:50.445 32278-32278/? A/DEBUG:     #17 pc 000776b6  /dev/ashmem/dalvik-jit-code-cache (deleted) (io.realm.Realm.commitTransaction+38)

This was using the core branch fsa/sync-before-extending-write-window

[finnschiermer]

We believe we have identified the root cause: https://github.com/realm/realm-core/issues/3427

[finnschiermer]

Tentative fix in progress: https://github.com/realm/realm-core/pull/3429

[cmelchior]

Should be fixed in 6.0.1 (not released yet), but 6.0.1-SNAPSHOT should be available. See https://github.com/realm/realm-java/blob/master/README.md#using-snapshots

[vladimirfx]

6.1.0-SNAPSHOT - works!
Waiting release.

[SeaMyC]

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 :(

“signal 11 (SIGSEGV), code 1 (SEGV_ MAPERR)
librealm- jni.so ” Has this problem been solved？？