-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Sort() signal 11 on version 73 #529
Comments
Thanks for the feedback. I'll investigate and get back to you. |
@codezion can you provide some context to the issue? I have tried to increase the number of objects in the unit tests with a factor of 10, and I don't get a signal 11 crash. |
There is already quite much db operation in the app and several tables and a lot of data. With sorting the lib crach after some tens or hundreds db operations and So no timing related. UI is filled with information from the DB. When sorting commented out, I can not crach the app no matter how hard i try. If that information do not help. I can try to create test code for you. Thank you for the fast reacting. Does this info help you? Here the table I try to sort. There are about 10 longs and Strings more. public class ActorStatus extends RealmObject Here the code that do or not do the sorting: // crash if any way of sorting is in use: And here the signal 11 and stack: D/CrashAnrDetector( 2391): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000010 |
Thanks for the information. I haven't been able to reproduce it in our unit tests (they actually sort three times). From the stack trace above, the crash seems to come from |
Yes. I think sort actually goes through well (I will test more) but if sort is used, some later use of the handle causes the crach. I haven't found a way to clean create a new handle after the sort query. It is like that after sorting some internal pointer becomes empty or someting and when sort is not used, all remains in order. I do not yet understand well how all works internally but seems that data remains at the lib side instead of java side to the last moment, that is good. |
The queries in Realm do not copy any data. The You have to be careful not to copy a Currently, the sorting is not done in-place i.e., a new |
The code basically do one query with sort. Then ExpandableListView' adapter starts to draw lines to the UI list based on data in RealmResults. There are getSize() and getView(position) in the adapter. At the time of getSize() query is done and kept in memory during multiple getViews. Touch of the screen causes redraw. With sort that crach after few touch and without sort never. Also if I use only realm's size() during the adaper getSize() and do a fresh query during each getView it do not crash. There should not be any changes to the db or anyting during the operation, but I continue commentig out more code to see waht is the core. Not much left anymore tho. Realm is so amazing fast that fresh queries are not problem, but nobody believes that before trying themself. It is like 0.5 ms wasting of user time. So this way I get ahead with sort() way |
Have you seen our new adapter example: https://github.com/realm/realm-java/tree/master/examples/adapterExample |
Yes. Thank you for good examples. I need a hierachical list so I think I need to use BaseExpandableListAdapter instead. |
I have very similar behaviour. If I pass realm.where(YPRegion.class).findAll().sort("region") to RealmBaseAdapter, it will crash. |
There was mention in another post that maybe this crash happens because of two instances of Realm (in same process). I am quite sure there was only one all the time. I haven't anymore the exact code left, but could try to recreate it at some point. My current fix is still the fresh queries inside each method so any Realm data is not reused between methods. Huge amount of queries, but works with sort this way. |
I've manually create only one instance, but later create two independent Adapters with two requests. Will the source or the log help you? |
@tseglevskiy If you can share your code (either publicly or privately), it would be of great help. |
The project is here: The right tab contains data from Realm tables. Corresponding code is here: If in the file |
@tseglevskiy the sort works in unit tests not sure why it crashes with your app. For now can you try and make another RealmResult that does the sorting. We are looking into the problem. Hope it helps for now. |
@benjaminprakash88 did you try to use my app? Did you take the crash successfully? Your peace of code looks like the mine except you use variable for ResultList. Unfortunately it crashes by the same way. |
@tseglevskiy Yeah i did try it and it did crash with the Once i changed it like that i could run the app. Where do the app crash for you? |
I have tried to single step through the app, and it seems that the crash happens in line 213 in The async task called in line 166 does have its own Realm instance. This is fine as sharing realm instances and objects across threads has undefined behaviour. |
@kneth nope, the crash happens independently of spinner.setSelection(). right now it happens in 2 seconds after this call (I've printed two messages to log around it). I made a copy of RealmBaseAdapter and put log messages at start and finish of every method. Crash happens in the method getItem in call realmResults.get(i), i=0. Interesting that it is the second call of this method. The first one with the same i = 0 runs correctly. |
It think, it may help you. Look into your io.realm.internal.TableView.nativeToString. My assumption is you have problems with sorting non-english UTF-8 strings. W/dalvikvm(24994): JNI WARNING: input is not valid Modified UTF-8: illegal continuation byte 0x2e |
This point do not make difference to this bug hunting, but because of the adapters are on table, the adapter example needs a face lift. The idea of holder pattern is to get rid of extra findViewById() calls, now it calls it all the time, so the holder in the example is useless. By using holder pattern correctly, the speed of Realm becomes better visible. Changes of timing affects to visibility of bugs sometimes as well. Two changes. private static class MyViewHolder {TextView tvTimeStamp;} @OverRide |
@codezion Thank you very much, I've done it. Really it was my question yesterday why we heed the holder. :) |
@tseglevskiy The string handling in Java is a bit strange if I remember correctly. And you have a lot of non-latin characters, and we might have an issue there (I notice the |
@tseglevskiy I have reviewed our code at the JNI layer (C++ code), and I have found some old - and potential wrong - string conversions. I'm grateful for your patience and your log file above! |
@tseglevskiy We haven't been able to resolve the issue. Just to rule out a problem with UTF strings, can you try to use a spreadsheet with only English letters? |
We now got a theory now for the sort issue, but just need to make and test a possible solution. We hope to be able to provide a fix for this very early next week. |
This should be fixed now with release 0.75.1. Please reopen if that's not the case! |
Exactly like 72 with enough queries (Fixed now). Could it be similar buffer size problem at sort() side?
The text was updated successfully, but these errors were encountered: