io.objectbox.exception.DbException: Could not get from cursor (-30787) (error code -30787)

[andreesperanca]

Is there an existing issue?

• [x] I have searched existing issues

Build info

• ObjectBox version: 4.1.0
• OS: Android 9
• Device/ABI/architecture: Tablet Lilliput

Steps to reproduce

I haven't been able to replicate the problem, but it happens frequently on devices I don't have access to.

Expected behavior

Understanding the problem is key to solving it.

Actual behavior

The application is crashing when trying to call a simple query.

Code

Code

 override suspend fun getMessageCountFromDatabase(): Long {
        val box = equipmentMessageBoxStore.getBox(EquipmentMessageEnvelopeDTO::class.java)

        val count = box.query()
            .equal(EquipmentMessageEnvelopeDTO_.status, EquipmentMessageStatus.READY.value.toLong())
            .build()
            .use { it.count() }

        return count
    }

Init:

   @Provides
    @Singleton
    @EquipmentMessageStore
    fun provideBoxStoreMessages(
        @ApplicationContext context: Context
    ): BoxStore {
        var boxStore: BoxStore
        val storeBuilder = MyObjectBox.builder()
            .validateOnOpenKv()
            .androidContext(context)
            .name("equipment-messages")
        boxStore = storeBuilder.build()
        return boxStore
    }

• Is there anything special about your app? No.
• May transactions or multi-threading play a role? Yes.
• Did you find any workarounds to prevent the issue? No.

Logs, stack traces

Logs, stack traces

io.objectbox.exception.DbException: Could not get from cursor (-30787) (error code -30787)

Unfortunately, this couldn't be reproduced, so I only have a photo of the problem occurring on a device.

[greenrobot]

For this to be actionable for us, we'd need additional information. Basically, enough data so we can reproduce.

[greenrobot-team]

In the past I've attributed this to a low memory (RAM) issue on the device. Specs for Lilliput PC-7108 indicate only 2 GB of RAM. But we never got enough info to reproduce this.

Does the EquipmentMessageEnvelopeDTO box contain a lot of objects? Do you have a rough idea how large the database is?

And for our reference error -30787 is MDB_CURSOR_FULL and occurs when pushing a page to the cursor stack would exceed a built-in fixed size limit (32) for the stack.

For our reference, this is internal issue objectbox/objectbox-java#285

[andreesperanca]

@greenrobot-team

Yes, it’s true that these devices have very little RAM. As for your question: this database can grow quite large up to hundreds of thousands of records (100k, 500k). I’ve already handled this in my code when fetching results so I don’t run out of memory (retrieving data little by little as needed), but in the count function I just need to know the total number of records. Is there anything I can do to prevent a cursor stack overflow in this case?

[greenrobot]

How large is the DB, e.g. with 0.5M objects? (Should not be an issue, but maybe it still gives us a clue.)

Also, is the property you use in the query indexed? If it's not: this could make a big difference, but updating e.g. 0.5M objects with an index is also not a small change...

[andreesperanca]

@greenrobot

With approximately 0.5 million objects, the database size is approximately 400 MB.

Regarding the query: the property used in the query, EquipmentMessageEnvelopeDTO_.status is indexed.

No update query is performed; the code breaks at the count() query.

[greenrobot]

About the tablet, can you find out the exact model so we can know the CPU, e.g. some models use the Cortex-A53. Also, are they running in 64-bit mode? (Some arm64 CPUs run a 32-bit Android...)

[greenrobot]

~~We have an idea for a workaround - do you have a way to tell if a new version will fix it? E.g. ask a user/customer of yours?~~ Spoke too soon, sorry.

[andreesperanca]

The tablet model is Lilliput 7108. It runs 64-bit Android Architecture: arm64-v8a

[greenrobot]

FYI: the next version will include some additional information on "Could not get from cursor" errors. It will give us additional context, but likely won't be enough to fix it just yet. We still need to find a reproducible case.

Btw, your app does not need to crash. This is an exception that you can catch. I guess that's clear, but we did not write it explicitly yet.