search

realm / realm-java

Realm is a mobile database: a replacement for SQLite & ORMs
http://realm.io
Apache License 2.0
11.47k stars 1.75k forks source link

Fatal signal 11 (SIGSEGV) from Java_io_realm_internal_UncheckedRow_nativeGetString #6152

Closed bfichter closed 5 years ago

bfichter commented 6 years ago

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

EdwardvanRaak commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago
  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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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

Zhuinden commented 5 years ago

(but does 6.0 introduce file format changes?)

cmelchior commented 5 years ago

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 commented 5 years ago

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

vladimirfx commented 5 years ago

Logcat output attached. Do you need something else?

crush_report_realm_honor.log crush_report_realm_xiaomi.log

bmunkholm commented 5 years ago

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

finnschiermer commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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

cmelchior commented 5 years ago

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

vladimirfx commented 5 years ago

@cmelchior yes, x86

cmelchior commented 5 years ago

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:

vladimirfx commented 5 years ago

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 commented 5 years ago

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 help@realm.io.
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 commented 5 years ago

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

finnschiermer commented 5 years ago

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

cmelchior commented 5 years ago

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 commented 5 years ago

6.1.0-SNAPSHOT - works! Waiting release.

SeaMyC commented 4 years ago

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.

Crashes_screen crash report :(

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