Android app with cblite2.8.1 crash on first initialization . Native crash null pointer dereference in couchbase library

Mobile Couchbase Lite
1

Hi,
We meet a crash on an android app on the first initialization of the app.
The cblite library version is 2.8.1.
We don’t have a scenario to reproduct it simply but the main idea is:

  • The app embed a prebuilt database
  • On the first launch of the application, after being connected to internet, the app closes unexpectedly a few moment after the initial synchro has started.
  • Then the app becomes stable

We could see in the logs that a native crash occurred in the couchbase library :

Build fingerprint: 'archos/SPAC101SOXAZ_EEA/ac101soxaz:9/PPR1.180610.011/20190605:user/release-keys'
Revision: '0'
ABI: 'arm64'
pid: 4816, tid: 5896, name: DefaultDispatch  >>> com.tikeasy.core <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
Cause: null pointer dereference
    x0  0000007222c675e8  x1  000000720acb0a80  x2  000000720a200000  x3  0000000000000015
    x4  0000000000000184  x5  000000720a092e88  x6  000000720adda6c0  x7  000000720acb0de0
    x8  000000720eb7d710  x9  000000000000000b  x10 0000000000000004  x11 0000000000000000
    x12 0000000000000000  x13 0000000000000003  x14 00000071ffa86020  x15 00003247d84e2a76
    x16 00000072102eede0  x17 000000720ff19624  x18 0000000000000008  x19 000000720c2b9b80
    x20 000000720c2b9b90  x21 000000720eb7e588  x22 000000001e6d56d8  x23 00000000132538e0
    x24 000000001e6dc860  x25 0000000013786590  x26 000000001da05750  x27 000000001e6cd690
    x28 0000000000000000  x29 000000720eb7d750
    sp  000000720eb7d710  lr  000000720ff18ee0  pc  000000720ff1966c

backtrace:
    #00 pc 000000000019066c  /data/app/com.tikeasy.core-qUZK-qPHVVDVQPuY2xs77A==/lib/arm64/libLiteCoreJNI.so (std::__ndk1::__hash_table<litecore::Query*, std::__ndk1::hash<litecore::Query*>, std::__ndk1::equal_to<litecore::Query*>, std::__ndk1::allocator<litecore::Query*>>::remove(std::__ndk1::__hash_const_iterator<std::__ndk1::__hash_node<litecore::Query*, void*>*>)+72)
    #01 pc 000000000018fedc  /data/app/com.tikeasy.core-qUZK-qPHVVDVQPuY2xs77A==/lib/arm64/libLiteCoreJNI.so (litecore::Query::~Query()+308)
    #02 pc 00000000001b6f10  /data/app/com.tikeasy.core-qUZK-qPHVVDVQPuY2xs77A==/lib/arm64/libLiteCoreJNI.so (litecore::SQLiteQuery::~SQLiteQuery()+16)
    #03 pc 0000000000176bac  /data/app/com.tikeasy.core-qUZK-qPHVVDVQPuY2xs77A==/lib/arm64/libLiteCoreJNI.so (c4Internal::C4QueryEnumeratorImpl::~C4QueryEnumeratorImpl()+44)
    #04 pc 0000000000069cd8  /data/app/com.tikeasy.core-qUZK-qPHVVDVQPuY2xs77A==/oat/arm64/base.odex (offset 0x68000) (com.couchbase.lite.internal.core.C4BlobKey.free [DEDUPED]+152)
    #05 pc 000000000006bb88  /dev/ashmem/dalvik-jit-code-cache (deleted)

Could you suggest how to investigate this bug ?
Regards

2

It looks like it might be an attempt to free the same blob key, twice. That shouldn’t happen.

There’s really not enough information in this snippet of the crash dump, to go on. If I can get the full logcat from around the time of the crash, I might be able to figure something out.

3

@blake.meike We’re using Couchbase Lite 2.8.6 EE for our Android apps and observed that there are times when the application crashes because of a native crash like the above (we don’t have the stack trace yet).

My question is: If at all that is the situation, is there a way we can detect such a crash and prevent the process/VM from crashing?