State condition failed in table:60

[asegurpe]

Describe the bug When querying a collection you get the error: State condition failed in table:60 The problem occurs when the paging limit is greater than 1. When the paging limit is 1 it has no problem.

Basic info (please complete the following information):

• ObjectBox version: 2.9.1
• Reproducibility: always on a single computer (database), on other computers (databases) it does not happen
• Device: Computer
• OS: Windows 10

To Reproduce I don't know how reproduce it

Expected behavior Find results

Code

private List<GenericBox> getPagination(Query<GenericBox> b, ParamsDao params) {
               if (params.getLimit() > 0) {
                              return b.find(params.getIndex(), params.getLimit());
               }
               return b.find();
}

Logs, stack traces

Caused by: java.lang.IllegalStateException: State condition failed in table:60: object
               at io.objectbox.query.Query.nativeFind(Native Method)
               at io.objectbox.query.Query.lambda$find$3(Query.java:230)
               at io.objectbox.BoxStore.callInReadTx(BoxStore.java:897)
               at io.objectbox.BoxStore.callInReadTxWithRetry(BoxStore.java:843)
               at io.objectbox.query.Query.callInReadTx(Query.java:292)
               at io.objectbox.query.Query.find(Query.java:229)

Additional context We have had to rebuild the entire database to fix the problem, but we are concerned about it happening again.

[ivahnenkoAnna]

Thanks for the report. We're looking into this and will reply as soon as possible.

[asegurpe]

I await with curiosity the resolution of the bug. Thank you very much Anna 😀

[greenrobot-team]

Thanks for the code snippet. We have not found the specific cause, yet, but are tracking this internally and will update this issue once we have more info.

[greenrobot]

Reproducibility: always on a single computer (database), on other computers (databases) it does not happen

Are any things special for this computer?

Also, the code seems to be triggered in 32-bit only code. Thus, this PC seems to be running the 32-bit version of the lib. Does that match the actual CPU?

[asegurpe]

No, this computer is not special and the process runs on the 32-bit platform because of other 32-bit dll dependencies.

So far it has only happened on this computer but we can't be sure that it can't happen on others in the future.

Thanks.

[greenrobot]

Thanks. Still trying to reproduce this... So far no luck...

1. Can you give an example on the numbers when this happens? I.e. total query result count, offset, and limit?
2. Is there also a sort order in the query defined? If so, does it also happen without it?
3. Do you have conditions on the query? If so, is at least one of the conditions based on an indexed property?

[asegurpe]

Thanks again for your help.

As I said, it has only happened to us once on a production computer but we cannot share the database due to confidentiality.

What we have seen is:

• Is related to sorted queries (by any field and ascending and descending order).
• If we put a limit, it occurs between 2800 and 3200 records, out of a total of 5000. If the limit is 1, there is no problem.
• apparently, the stored data are correct and valid and do not have any special characters.

[greenrobot-team]

@asegurpe Thanks for these details! The new 3.1.3 release adds additional information to error messages that might help us diagnose this issue.

[asegurpe]

Hi,

We have upgraded to 3.1.3 as you say and the stacktrace shows a different message:

Caused by: java.lang.IllegalStateException: State condition failed in visitMatchesOrdered:221: id != lastId
    at io.objectbox.query.Query.nativeFind(Native Method)
    at io.objectbox.query.Query.lambda$find$3(Query.java:235)
    at io.objectbox.BoxStore.callInReadTx(BoxStore.java:936)
    at io.objectbox.BoxStore.callInReadTxWithRetry(BoxStore.java:882)
    at io.objectbox.query.Query.callInReadTx(Query.java:297)
    at io.objectbox.query.Query.find(Query.java:234)

Thanks.

[greenrobot]

Thanks; interestingly it now fails a different location. Which is not exactly expected... Can you confirm that from your side, nothing changed?

[asegurpe]

Yes, it is the same code and the same database.

Thanks.