Getting a a Fatal Signal 11 (SIGSEGV), code 1 using Realm

Question

It seems this error is caused by bugs in native code, and that this is due to the Realm library -- based on seeing the phrase librealm-jni.so in the "Build Fingerprint" beneath the error. I have the latest version of Realm installed -- 1.2.0.

Here's the error code:

Fatal signal 11 (SIGSEGV), code 1, fault addr 0x14c in tid 7837 (ator.app)

Here's the "Build Fingerprint:"

    Build fingerprint: 'generic/vbox86p/vbox86p:5.0/LRX21M/buildbot11172321:userdebug/test-keys'
26643-26643/? I/DEBUG: Revision: '0'
26643-26643/? I/DEBUG: ABI: 'x86'
26643-26643/? I/DEBUG: pid: 7837, tid: 7837, name: ator.app  >>> com.lockedout.app <<<
26643-26643/? I/DEBUG: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x14c
26643-26643/? I/DEBUG:     eax 00000148  ebx ffffffff  ecx 7470d340  edx 00000002
26643-26643/? I/DEBUG:     esi 00000000  edi 00000002
26643-26643/? I/DEBUG:     xcs 00000023  xds 0000002b  xes 0000002b  xfs 00000007  xss 0000002b
26643-26643/? I/DEBUG:     eip e2f6d025  ebp ffd3cd58  esp ffd3cd50  flags 00210246
26643-26643/? I/DEBUG: backtrace:
26643-26643/? I/DEBUG:     #00 pc 0002a025  /data/app/com.lockedout.app-1/lib/x86/librealm-jni.so
26643-26643/? I/DEBUG:     #01 pc 0009c141  /data/app/com.lockedout.app-1/lib/x86/librealm-jni.so
26643-26643/? I/DEBUG:     #02 pc 0009c299  /data/app/com.lockedout.app-1/lib/x86/librealm-jni.so
26643-26643/? I/DEBUG:     #03 pc 004002d3  /data/dalvik-cache/x86/data@[email protected]@[email protected]
26643-26643/? I/DEBUG:     #04 pc 00000002  <unknown>
26643-26643/? I/DEBUG: Tombstone written to: /data/tombstones/tombstone_06

Update:

I narrowed down the problem to happening after I call notifyDataSetChanged on my RecyclerView.Adapter, but my code doesn't do anything else after that executes. So I narrowed down the problem area even further to line 135 in android's Looper class:

Message msg = queue.next(); // might block

I'm not sure what this means, but I imagine someone who knows the internals of Realm may be able to shed some insight on why the error is being caused in Looper.

Some more information about the changes that occured in Realm before the error: notifyDataSetChanged is triggered inside of a RealmChangeListener set on a RealmObject aka "User". The transaction that caused the change deleted a custom RealmObject aka "Item" from User's RealmList<Item>. I know for a fact that that is the only transaction and operation that occurs because of my code. Here is the code that deletes the Item:

RealmSingleton.getUserInstance().executeTransaction(new Realm.Transaction() {
    @Override
    public void execute(Realm realm) {
        UserSingleton.getUser().deleteItem(mItem.getClassId());
    }
});

Update:

The exact line of Realm code that causes the error is line 149 in SharedGroup:

148    void commitAndContinueAsRead() {
149            nativeCommitAndContinueAsRead(nativePtr);
150    }

Answer 1

(I am still not an official Realm person)

Note: In order to actually answer this question, I'd have to see the full code. After all, Realm handles most possible crashes on the native side and throw it as an exception to Java, so you're probably doing something very wrong. :P

Guesses:

1.) you're using asynchronous queries combined with synchronous write on the UI thread, thus creating detached row accessors that you then try to delete based on ID despite it not being its latest version.

(Asynchronous queries aren't immediately executed, you need to listen to its completion using RealmChangeListener, but if you mix them with synchronous writes on the UI thread, you force the query to become synchronous.)

2.) You modified something on a background thread which has not yet updated the RealmResults on the UI thread (running the event handling with the looper), and the element you're trying to use in the transaction is not up to date, so its deletion crashes.

Possible solutions:

a.) Use executeTransactionAsync() instead of executeTransaction() when you're on the UI thread.

b.) In your method

UserSingleton.getUser().deleteItem(mItem.getClassId());

Not sure what UserSingleton is, but before you delete an element, you should consider requerying it based on ID inside the transaction to obtain the latest version of the element (which is potentially not updated yet in this particular case, synchronous transaction on the UI thread, after all)

Possible course of action:

If you want to help out Realm, if this crash is reproducible, consider sending the project over to help[at]realm.io so that they can look at it and fix it up. After all, you should get Java exceptions, not native crashes.