Native Crash (SIGSEGV) in libLiteCore.so after upgrading to Android SDK 4.0.0

Mobile
1

Hi Couchbase Team,

We recently upgraded our Android application to Couchbase Lite 4.0.0, and since the release, we are seeing a significant spike in native crashes in production.

The crash occurs in libLiteCore.so and appears to be fatal (SIGSEGV and SIGILL). It is currently affecting a large number of users (~3,000 events tracked so far) across various Android versions and devices.

Environment:

  • Couchbase Lite Version: Android SDK 4.0.0

  • Architecture: arm64-v8a

  • OS Versions: Widespread. We see it heavily on Android 16 Beta, but also significantly on Android 14 (SDK 34) and Android 13 (SDK 33).

  • Devices: Seemingly device agnostic, though high volume on Samsung devices (Samsung S23 series, etc.).

The Stack Trace: The crash seems to originate from com.couchbase.lite.internal.core.j2.run. Here is the backtrace from a SIGSEGV:

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

backtrace:
  #00  pc 0x001f02209132c210 
  #01  pc 0x000000000028fa3c  /data/app/~~OFZzdFQzQ38VaLMW8iINAg==/com.app.sample--oBq7WMe6Fw0PW1MZYmmrQ==/lib/arm64/libLiteCore.so (BuildId: 73f1690fe090c59ee522e88861406cc52871f8a2)
  #02  pc 0x000000000028b5bc  /data/app/~~OFZzdFQzQ38VaLMW8iINAg==/com.app.sample--oBq7WMe6Fw0PW1MZYmmrQ==/lib/arm64/libLiteCore.so (BuildId: 73f1690fe090c59ee522e88861406cc52871f8a2)
  #03  pc 0x00000000001f888c  /data/app/~~OFZzdFQzQ38VaLMW8iINAg==/com.app.sample--oBq7WMe6Fw0PW1MZYmmrQ==/lib/arm64/libLiteCore.so (BuildId: 73f1690fe090c59ee522e88861406cc52871f8a2)
  #04  pc 0x00000000001a67e8  /data/app/~~OFZzdFQzQ38VaLMW8iINAg==/com.app.sample--oBq7WMe6Fw0PW1MZYmmrQ==/lib/arm64/libLiteCore.so (BuildId: 73f1690fe090c59ee522e88861406cc52871f8a2)
  #05  pc 0x00000000001a6824  /data/app/~~OFZzdFQzQ38VaLMW8iINAg==/com.app.sample--oBq7WMe6Fw0PW1MZYmmrQ==/lib/arm64/libLiteCore.so (BuildId: 73f1690fe090c59ee522e88861406cc52871f8a2)
  #06  pc 0x0000000001025dc0  /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (art_jni_trampoline+112)
  #07  pc 0x000000000084baa4  /data/app/~~OFZzdFQzQ38VaLMW8iINAg==/com.app.sample--oBq7WMe6Fw0PW1MZYmmrQ==/oat/arm64/base.odex (com.couchbase.lite.internal.core.j2.run+244)
  #08  pc 0x0000000000521cfc  /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (java.util.concurrent.ThreadPoolExecutor.runWorker+748)
  #09  pc 0x0000000000526140  /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (java.util.concurrent.ThreadPoolExecutor$Worker.run+64)
  #10  pc 0x000000000039ded8  /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (java.lang.Thread.run+72)
  #11  pc 0x0000000000317194  /apex/com.android.art/lib64/libart.so (art_quick_invoke_stub+612)
  #12  pc 0x0000000000302838  /apex/com.android.art/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+216)
  #13  pc 0x00000000004c8298  /apex/com.android.art/lib64/libart.so (art::Thread::CreateCallback(void*)+932)
  #14  pc 0x00000000000f1118  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+208)
  #15  pc 0x000000000008dd54  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64)

This is a significant issue given the volume of crashes shown in your screenshots (over 3,000 events). To get the best help from the Couchbase team, your post needs to be structured, technical, and provide the context that libLiteCore.so crashes are often hard to debug without symbolication.

Here is a draft you can copy, paste, and fill in the bracketed details.

Draft for Couchbase Forums / Github Issues

Title: Native Crash (SIGSEGV) in libLiteCore.so after upgrading to Android SDK 4.0.0

Body:

Hi Couchbase Team,

We recently upgraded our Android application to Couchbase Lite 4.0.0, and since the release, we are seeing a significant spike in native crashes in production.

The crash occurs in libLiteCore.so and appears to be fatal (SIGSEGV and SIGILL). It is currently affecting a large number of users (~3,000 events tracked so far) across various Android versions and devices.

Environment:

  • Couchbase Lite Version: Android SDK 4.0.0

  • Architecture: arm64-v8a

  • OS Versions: Widespread. We see it heavily on Android 16 Beta, but also significantly on Android 14 (SDK 34) and Android 13 (SDK 33).

  • Devices: Seemingly device agnostic, though high volume on Samsung devices (Samsung S23 series, etc.).

The Stack Trace: The crash seems to originate from com.couchbase.lite.internal.core.j2.run. Here is the backtrace from a SIGSEGV:

backtrace:
  #00  pc 0x0009011f91008108 
  #01  pc 0x000000000028fa3c  /data/app/.../lib/arm64/libLiteCore.so (BuildId: 73f1690fe090c59ee522e88861406cc52871f8a2)
  #02  pc 0x000000000028b5bc  /data/app/.../lib/arm64/libLiteCore.so
  #03  pc 0x00000000001f888c  /data/app/.../lib/arm64/libLiteCore.so
  #04  pc 0x00000000001a67e8  /data/app/.../lib/arm64/libLiteCore.so
  #05  pc 0x00000000001a6824  /data/app/.../lib/arm64/libLiteCore.so
  #06  pc 0x0000000000d6d00c  /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (art_jni_trampoline+108)
  #07  pc 0x00000000007df4ec  /data/app/.../oat/arm64/base.odex (com.couchbase.lite.internal.core.j2.run+188)
  #08  pc 0x000000000048cbe4  ... (java.util.concurrent.ThreadPoolExecutor.runWorker+676)
  ...

Additional Context from Logs: Looking at our crash reporting (Google Play Console/Crashlytics), we see related signatures grouping under libLiteCore.so. specifically:

  1. [libLiteCore.so] SIGSEGV (Most frequent)

  2. [libLiteCore.so] FLEncoder_WriteKey (SIGSEGV)

  3. [libLiteCore.so] SIGILL

Questions:

  1. Are there known issues with libLiteCore in 4.0.0 regarding thread safety or Fleece encoding (FLEncoder_WriteKey)?

  2. The stack frames #01-#05 in libLiteCore.so are not symbolicated in our production logs. Is there a way we can map this Build ID (73f1690fe090c59ee522e88861406cc52871f8a2) to specific functions on your end, or is there a debug symbol file available for 4.0.0 we can use to symbolicate?

  3. Since the crash stems from com.couchbase.lite.internal.core.j2.run, can you clarify what specific background operation this internal runnable usually handles (e.g., Replication, Live Query, or Database Close)?

Any assistance in identifying the cause or a workaround would be appreciated as this is impacting production.

Thanks!

2

With regards to why you have no symbols, the Android toolchain is needlessly aggressive when it comes to stripping libraries and so there are no symbols left. The shipped libraries should have all the symbols inside of it if you can pick it out of the maven distro.

I’m unfamiliar with com.couchbase.lite.internal.core.j2.run and I can’t seem to find any reference to that particular function in our codebase.

I am able to symbolicate the stack trace to this however:

fleece::Retained<fleece::impl::Doc const, (fleece::Nullability)1>::~Retained()
/home/couchbase/jenkins/workspace/couchbase-lite-core-android-pipeline/couchbase-lite-core/vendor/fleece/API/fleece/RefCounted.hh:134
fleece::impl::release(fleece::impl::Value const*)
/home/couchbase/jenkins/workspace/couchbase-lite-core-android-pipeline/couchbase-lite-core/vendor/fleece/Fleece/Core/Value.cc:436
fleece::RetainedValue::~RetainedValue()
/home/couchbase/jenkins/workspace/couchbase-lite-core-android-pipeline/couchbase-lite-core/vendor/fleece/API/fleece/Mutable.hh:258
litecore::VectorDocument::~VectorDocument()
/home/couchbase/jenkins/workspace/couchbase-lite-core-android-pipeline/couchbase-lite-core/LiteCore/Database/VectorDocument.cc:57

so I’ll check and see if someone knows something about this trace.

1 Like
3

@sinan Do you any specific scenario, or even better, logs, that you may share? Does it happen, for example, when you open an old database, or what something else?