When do you close your Cursors or are you relying on the finalizer to close them?

from sqlite-android.

I always read the data then explicitly close the cursor asap. This is possibly a problem in SQLite Android Binding. But I have no time to get a minimal test case now....

from sqlite-android.

Please try the 3.12.1-1 version

from sqlite-android.

@npurushe OOM is gone

from sqlite-android.

Great! thanks for reporting

from sqlite-android.

Hello. I can still reproduce this in certain phones...Galaxy Note3, Android 5.0

from sqlite-android.

Do you get any warnings in your adb log from the SQLite tag (or anything with the message A resource was acquired at attached stack trace but never released) ? Is it only on Android 5.0?

from sqlite-android.

@npurushe no, there is none. but the native dirty memory will increase to around 60 mb. I can only reproduce it in one Android 5.0 phone, a Galaxy Note 3, with a Samsung custom Android 5.0. This is very wired to me, as the whole sqlite subsystem is in this project and shouldn't be platform dependent. Or it is not a real memory leak, but maybe it is because on that phone the memory constraint is different and this project doesn't meet the constraint but the system one meet.

from sqlite-android.

@npurushe just read your README.md about the read performance. So this project allocate memory differently compared to "SQLite Android Binding" project and Android embedded SQLite? Please reopen this issue because I am sure it still exists..

OK. after read the AOSP code and your code, seems the issue is AOSP create memory in ashmem but your code create memory in app heap... So I will see if I can make memory allocation smaller

from sqlite-android.

Yes that is the primary difference. I looked at the CursorWindow allocations and everything that was allocated was freed in all tests, so are you sure there is an issue there? How many cursors do you have open while running your program?

from sqlite-android.