-
Notifications
You must be signed in to change notification settings - Fork 307
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crash: Java_io_objectbox_query_Query_nativeFind #493
Comments
Could you repeat what you did using ObjectBox |
ObjectBox version: 1.5.0: Recently I did not notice any similar issue. I will try v2 and observe. Thanks =) |
The same error still occurred after using 2.0.0. Should I delete the existing database (built in 1.5.0) and try again ? |
Thanks, could you post the same log? (starting with *** *** *** ....) |
|
Possible to have any temp solution for this? It always crashes the app after the first crash. |
Investigated code that might be related, and did some minor improvements. Probably won't fix much. Could you reach out to me to arrange a solution: [my first name] ät objectbox dot io |
If you have time, could you share another crash log with |
I have emailed you for that. Thanks. So far I only encountered this issue once with 2.0.0-beta (not 2). I will use beta2 and continue to observe. |
The error happened again: (Version: 2.1 and 2.2) Please see the error log below:
|
Tried to reproduce this with the info sent via email, but no luck. @LeeKingHung Can you look at the code in my example below and maybe update it, so it works more like what you are doing? (Note: you can use File > Export to Zip File in Android Studio to export.) |
I tried to update your codes, and could not reproduce, too. However, the more I ran the app, the longer it took to run the db operation (about 30 seconds for 2000-object query). The crash did not always happen, I also could not reproduce it using the codes in my project (I uninstalled and reinstall the app, the crash did not happen then. I guess it might happen only when the database size is large and the app is used for many times) Maybe the issue comes from the number of properties for one entity instead of number of data for one entity? In my update codes (below link), I have more than 20 properties. |
Update: After I changed the query limit from 2000 to 2, it worked without crash. However, it was extremely slow ( more than 2 seconds ). Then I changed back to 2000 and tried, the speed was very slow too but the crashed did not happen (the output size is less than 1000). Other than that, it seemed that some other queries (other parts from my project) were very slow as well. |
@LeeKingHung I noticed you are setting An emulator may work, but only if you customize the default size. Also |
After reducing to put 10000 entities, but keeping maxSize 10G and maxReaders 5000 and running on a too small Android P emulator I get a crash when querying. Though the database size is just ~120MB.
|
OK, could narrow it down by removing code that does not affect the crash (pretty much all of it, including maxSize/maxReaders; just kept put and the query). The crash occurs if find limit is 5 or more, but not if 4 or less. With 6544 entities: the database size is around 80MB, so not the issue. And the limit can again be increased without crash. Also, inserting less data (not setting all properties) avoids the crash. So there is definitely a bug there, will continue working on a test case. update: added concrete values (see above). update: minimal repro code -ut |
Thanks for finding out the bug! =) I have large number of max readers and max db size just to prevent from reaching the limit. I do not actually need that much. Now I use 500 max readers and 5GB max db size. |
FYI, If crash did not occur, the extreme slowness would be observed (even the limit is less than 10). |
@LeeKingHung Working on resolving the crash. About the slowness: if you use 5GB or even 10GB as the upper limit, are you making sure that the affected devices actually have that much disk space available? Operations slowing down sounds very much like a device low on storage. |
Yes, all devices have more than 12GB available space. Does the upper limit depend on the available space? I thought only the current db size depends on it. |
Hi is there any temporary solution to avoid this error? It keeps crashing......... |
Sorry, none that we know of. |
No worries. By the way I noticed something, not sure it is related to this issue or not: |
Is there any estimation of the release time of the fix ? |
I got the same crash on many devices. huawei,xiaomi,samsung. And the same log "Java_io_objectbox_query_Query_nativeFind+72" and I didn't insert any data, just query,when I got the crash. my objectbox version is 2.2.0 |
This issue has been shared with the development team. As always, I can't give estimates on a fix. -ut |
@LeeKingHung, @frankqianghe I'm currently investigating this. Does the issue occur on both 32 and 64 bit configurations? Note that a CPU may be capable of 64 bit, but it is up to the OS to actually use it. I saw |
Due to my findings, I assume this it limited to 32 bit and large objects. |
A fix is confirmed internally. It required extensive changes and we will do some additional tests for the upcoming release. |
How to check whether it is 32 bit or 64 bit ? |
@LeeKingHung You have to check the device. The just released version 2.3.0 should fix this. Please verify and let us know. Thank you! |
I have one affected user (10 crashes) on a Samsung Galaxy Note5 (noblelte), 3840MB RAM, Android 7.0. It's the first time, I see this on the developer console after upgrading to ObjectBox 2.5.1.
|
any update?it's still there. 1 #00 pc 00042a20 /system/lib/libc.so (tgkill+12) [armeabi-v7a]2 #1 pc 000410b1 /system/lib/libc.so (pthread_kill+32) [armeabi-v7a] |
@Oo121oO It's probably another issue as the native stack looks different. Could you open a new issue with some more details, so this is not lost? Thanks! |
Issue Basics
I received the following crash when I called box.find method. This only happened sometimes. But once it happened, it would always happen later. Any clue ?
The text was updated successfully, but these errors were encountered: