My app is crashing when using Collection.setDocumentExpiration() in Couchbase Lite 3.1
private fun Collection.setDocumentExpirationCommon(id: String) {
this.setDocumentExpiration(
id,
Date(System.currentTimeMillis() - 100000)
)
}
this function is called over a loop for multiple ids synchronously.
Collection.delete(Doc) is working fine but is taking a significant amount of time, need help with this issue.
Which SDK?
Which version?
What do you mean by crashing? Is there a core dump? If there is an exception please post it.
collection.remove(doc) should be instant unless you have non-default durability settings in your ClusterEnvironment. Can you post the code where you create the ClusterEnvironment and get the connection?
Can you post the code that calls setExpiration and the code that calls remove?
Thanks.
2 Likes
Hi @bhanuk19! If you provide us with more context about the issue, as mentioned above, so we can start digging. Thanks!
Hi @iveta.dulova please look into this, and ask if you need anything else
SDK: Couchbase Lite Android SDK
Version: 3.1.1
Crash:
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0000000000000048
Cause: null pointer dereference
x0 0000000000000048 x1 b4000078d0db2214 x2 0000000000000007 x3 000000783824af40
.
.
.
backtrace:
#00 pc 00000000000b7278 /apex/com.android.runtime/lib64/bionic/libc.so (pthread_mutex_lock+12) (BuildId: 01331f74b0bb2cb958bdc15282b8ec7b)
#01 pc 00000000003b8110 /data/app/~~-u5YGmCbg2DZFznEEQ4R_g==/com.aidash.ivms_pro.debug-8djvamO03VTmrSVMTJ0bVQ==/base.apk!libLiteCore.so (std::__ndk1::recursive_mutex::lock()+12) (BuildId: ee0c202701aa67ffcdc739dea1e8911592e589ba)
Snippet for expiration ( crashing app in 3.1.1)
private fun Database.setDocumentExpirationCommonForIVMSApp(id: String) {
this.setDocumentExpiration(
id,
Date(System.currentTimeMillis() - 100000)
)
}
Snippet used for deletion:
fun Collection.deleteDoc(id: String){
getDocument(id)?.let{
delete(it)
}
}
SDK: Couchbase Lite Android
Version: 3.1.1
Android SDK: 33
Crash:
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0000000000000048
Cause: null pointer dereference
.
.
.
#00 pc 00000000000b7278 /apex/com.android.runtime/lib64/bionic/libc.so (pthread_mutex_lock+12) (BuildId: 01331f74b0bb2cb958bdc15282b8ec7b)
#01 libLiteCore.so (std::__ndk1::recursive_mutex::lock()+12) (BuildId: ee0c202701aa67ffcdc739dea1e8911592e589ba)
(litecore::Housekeeper::_doExpiration()+52)
private fun Collection.setDocumentExpiration(id: String) {
this.setDocumentExpiration(
id,
Date(System.currentTimeMillis() - 100000)
)
}
What’s the value of id?
It’s a random uuid generated by java UUID class.
that is the document ID
the same expiration function is working fine in Couchbase lite 3.0.0, but crashing in 3.1.1
Couch version 3.0.0
private fun Database.setDocumentExpiration(id: String) {
this.setDocumentExpiration(
id,
Date(System.currentTimeMillis() - 100000)
)
}
@bhanuk19 I’m trying to understand the code and scenario that is causing the crash.
Do you have a loop to set document expiration on multiple documents to (current time - 1000) so that the documents will be expired and get purged right away?
If that is the case, how may documents you have tried to set the expiration at once? I’m asking this so we have the exact info to reproduce the issue.
Alternatively, you can also purge (using purge function) the documents in the background to get the same behavior. To avoid blocking the other operations on the UI thread, you can create a new instance of the database to use for that purpose.
@pasin yes i have a loop set over setDocumentExpiration and currTime - 1000 so that the document is expired right away before fetching the next set of records i doing it synchronously to avoid fetching the same records again
steps:
step:1 - first fetching 500 records
step:2 - performing some operations
step:3 - setting expiration for those 500 records
step 4: repeat until collection is empty
these are the operations that iam performing
By any chance, do you also close the database at the end of those steps?
no not closing the database.
@bhanuk19
We have, essentially, nothing to work with, here. You’ve elided the backtrace so that it is nearly useless, provided no logs, and given us no way to reproduce the issue.
If we can’t see the problem, we can’t fix it. If you can help us to see it, we will be a lot more effective in helping you address the problem.
crashReportCB.txt.zip (1.8 KB)
@blake.meike please find the attached logs, and please ask if you need anything else
Hey @bhanuk19 : that is a start! Thank you!
That is just a backtrace, though; not logs. Logs from a bit before and after the event would help a lot.
I have opened Loading... to track this issue. It will remain a very low priority, however, until we have enough information to work on it.
@blake.meike there is no additional that i found related to this crash only thing is this backtrace.
Please ask if you need any additional info or the steps to reproduce this.