objectbox-java: CRASH: SIGSEGV: libobjectbox-jni.so

Bug Description:

Unexpected ANDROID native app crash

Basic info

ObjectBox version: 3.1.3 (crash happened on previous version as well, we just tried to update ObjectBox as an attempt to fix it)
Reproducibility: our team are not able to reproduce it on our end, we only see lots of crash reports on Firebase in production.
Device: different devices Samsung - Galaxy S20+ 5G, Galaxy Note20 Ultra 5G, Galaxy S21 Ultra 5G LGE - Stylo 6 Xiaomi - Redmi K20 HUAWEI - HUAWEI P30 lite
OS: Android 10, Android 11, Android 9, Android 12

To Reproduce Looks like crash happens occasionally without any specific steps, especially when users open app by push with the following trace:

Logs, stack traces Crashed: Thread : SIGSEGV 0x000000000000012d #00 pc 0x52c78 libobjectbox-jni.so #01 pc 0x52c6c libobjectbox-jni.so #02 pc 0x768639787c #03 pc 0x7688c8126a #04 pc 0x7688cfee8e
#05 pc 0x7688cfee8e #06 pc 0x592bdc libart.so #07 pc 0x768895430a

Additional context

What we have already tried to do:

We fully recreated objectbox schema
We removed and created objectbox db file

But the crash still occurs with similar trace. Do you have any ideas for farther investigation since it’s really hard to figure out what has happend on user’s devices with such stack trace, so any advice will be really helpful.

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 16 (7 by maintainers)

Most upvoted comments

If you saw these IllegalStateException(“Internal error: query is already closed”) pop up in your Crashlytics, a stacktrace would be very helpful!

It was no single exception like that in crashlytics so far. However we got little bit more detailed exception for old crash:

 #00  pc 0000000000052c78  /lib/arm64/libobjectbox-jni.so (Java_io_objectbox_query_Query_nativeFind+116)
 #00  pc 00000000001a010c  /oat/arm64/base.odex (art_jni_trampoline+124)
 #00  pc 00000000003f6d78  /oat/arm64/base.odex (io.objectbox.query.Query.lambda$find$2+88)
 #00  pc 00000000003f7ea0  /oat/arm64/base.odex (io.objectbox.query.y.call+96)
 #00  pc 00000000003edc70  /oat/arm64/base.odex (io.objectbox.BoxStore.callInReadTx+256)
 #00  pc 00000000003ee0f4  /oat/arm64/base.odex (io.objectbox.BoxStore.callInReadTxWithRetry+84)
 #00  pc 00000000003f6f44  /oat/arm64/base.odex (io.objectbox.query.Query.callInReadTx+84)
 #00  pc 00000000003f7198  /oat/arm64/base.odex (io.objectbox.query.Query.find+104)
 #00  pc 0000000000471138  /oat/arm64/base.odex (io.objectbox.query.QueryPublisher.run+424)
 #00  pc 00000000002368a8  /apex/com.android.art/javalib/arm64/boot.oat (java.util.concurrent.Executors$RunnableAdapter.call+72)
 #00  pc 00000000002f5b3c  /apex/com.android.art/javalib/arm64/boot.oat (java.util.concurrent.FutureTask.run+204)
 #00  pc 000000000037b4ec  /apex/com.android.art/javalib/arm64/boot.oat (java.util.concurrent.ThreadPoolExecutor.runWorker+988)
 #00  pc 0000000000374d14  /apex/com.android.art/javalib/arm64/boot.oat (java.util.concurrent.ThreadPoolExecutor$Worker.run+68)
 #00  pc 00000000001bf19c  /apex/com.android.art/javalib/arm64/boot.oat (java.lang.Thread.run+76)
 #00  pc 00000000002ca764  /apex/com.android.art/lib64/libart.so (art_quick_invoke_stub+548)
 #00  pc 000000000030e980  /apex/com.android.art/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+156)
 #00  pc 00000000003c1db4  /apex/com.android.art/lib64/libart.so (art::JValue art::InvokeVirtualOrInterfaceWithJValues<art::ArtMethod*>(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, art::ArtMethod*, jvalue const*)+380)
 #00  pc 00000000004578ec  /apex/com.android.art/lib64/libart.so (art::Thread::CreateCallback(void*)+992)
 #00  pc 00000000000ed138  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+264)
 #00  pc 000000000008b2a0  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64)

So defenetely it was not about plain finds but about DataSubscribers. We are right now looking to such case:

Query launched from subsicrption is executed in one thread and already have reached nativeFind.
Query is closed from another thread - nativeDestroy is called.

you did not add any additional close() statements? So the only significant change is the removal of the close() call from finalize()?

We addded 3 more close() in our own code where it was missed. Also in upcoming release we will add additional closing for DataSubscriber. But overall yes - main change is removing close() from finalize.

Release 3.2.0 is out which now throws an exception if the Query is closed instead of crashing the virtual machine. This should also help in above case using observers which looks to be a race during garbage collection.

We will check it with next release and will come back with updates. Thank you!

vdmitrovich on Jun 21, 2022

I did a little of gradle dependencies dark magic and was able to replace io.objectbox.objectbox-java with one builded from sources from this github + our little changes. What we did:

Removed close() from Query.finalise()
Added exception on any query operations after close()
doublechecked everywhere in our code that we have proper closing of queries(except DataSubscriber - we left it for future releases if we will see some leaks or issues here) What we found out:
Crash rate returned back to what we had before spike (we still have few of such crashes - but we had them even before spike - so with this version we have back to normal)
We actually never called close() before any find operations - our new exception is never raised.

I’m still not fully understand what happened - we reviewd all our changes couple times after which we had crashes spike - and have not find any significant changes in objectbox usage(it was few - but after we reverted them nothing changes) So for us it’s still a peace of dark magic. We will prepare pull-request with changes which we made to objectbox-java to avoid crashes - and you can review and consider what to do with this.

vdmitrovich on Jun 16, 2022