Hi,
We’re receiving exceptions with the following stack:
(20650): net.sqlcipher.database.SQLiteException: not an error
(20650): at net.sqlcipher.database.SQLiteDatabase.dbopen(Native Method)
(20650): at net.sqlcipher.database.SQLiteDatabase.(SQLiteDatabase.java:1942)
(20650): at net.sqlcipher.database.SQLiteDatabase.openDatabase(SQLiteDatabase.java:875)
(20650): at net.sqlcipher.database.SQLiteDatabase.openDatabase(SQLiteDatabase.java:868)
(20650): at net.sqlcipher.database.SQLiteDatabase.openOrCreateDatabase(SQLiteDatabase.java:903)
(20650): at net.sqlcipher.database.SQLiteDatabase.openOrCreateDatabase(SQLiteDatabase.java:899)
The native dbopen (from SQLiteDatabase.cpp) function calls throw_sqlite3_exception in several places, but I can’t figure which exact line was called in my case. I noticed that before each throw_sqlite3_exception call there’s LOGE call, but I don’t get those logs in logcat.
Could you please explain how to enable those logs? And which tag it uses (is it “Database”)?
Alex.
The calls to LOGE within SQLiteDatabase.cpp should route directly to logcat, below is an example of a failing test case I created within the SQLCipher for Android test suite.
You might want to verify that you are not filtering logcat which could prevent you from viewing certain messages.
Thanks for prompt answer.
I have verified that I’m not filtering out the Database tag.
I checked the dbopen function once again, and the only place that calls throw_sqlite3_exception without logging the error is right after the register_android_functions function. And since I still not see logs in logcat, I believe that this is where my call fails.
So what is register_android_functions (sqlite’s)? I browsed its source, and it deals with (among other things) with unicode collations. Which make me think that something is wrong with my ICU files or sqlite collation initialization.
I noticed that in setICURoot function you set the “SQLCIPHER_ICU_PREFIX” environment variable. Could you please point me on the source where you actually using it?
Another thing that might be related to my problem: a few months ago I’ve added a library that works directly with sqllite (that’s fine with me), and it works with icu v5.2. Most probably it somewhere initializes sqlite to use this specific version. I’m afraid that this leads to collisions with sqlcipher’s icu initialization.
Is there a way I can verify that sqlite initialized with proper icu before calling openOrCreateDatabase?
Hello @AlexLipov
Are you building SQLCipher for Android from source, or using the provided binaries? Are you able to reproduce this behavior in a simple application, or is it localized to your application which is also using another version of SQLite and ICU 5.2? It is possible there could be a conflict. Have you integrated SQLCipher for Android per the documentation here? Have you verified you are bundling icudt46l.zip within your assets folder?
When the ICU source is build, we include a CFLAG to identify the environment variable (i.e., SQLCIPHER_ICU_PREFIX) in which ICU should use to find its dat file. This environment variable is set during the SQLiteDatabase.loadLibs(…) process.
Are you building SQLCipher for Android from source, or using the provided binaries?
Have you integrated SQLCipher for Android per the documentation here?
Integrated the provided binaries according to aforementioned documentation.
Are you able to reproduce this behavior in a simple application?
Unfortunately not - I’m receiving those errors sporadically.
Have you verified you are bundling icudt46l.zip within your assets folder?
Yes, and verified that it is being unzipped to app’s /files/icu folder.
I’ve added print to logcat with register_android_functions’s function return value, and currently manually building from source. Do you have any other tips to track down this issue?
Many thanks!