net.sqlcipher.database.SQLiteException ??? not error exception on SQLiteDatabase.dbOpen

[kivsiak]

I cannot found clear conditions to reproduce bug. But 2-5% my application starts are interrupted with this.

I have icudt46l.zip in assets. I've checked and found that /icu/icudt46l.dat is exists in my app data folder.

To be sure i run loadLibs() in application class. However sometimes(!) i got this.

net.sqlcipher.database.SQLiteException: not an error
   at net.sqlcipher.database.SQLiteDatabase.dbopen(SQLiteDatabase.java)
   at net.sqlcipher.database.SQLiteDatabase.<init>(SQLiteDatabase.java:1942)
   at net.sqlcipher.database.SQLiteDatabase.openDatabase(SQLiteDatabase.java:875)
   at net.sqlcipher.database.SQLiteDatabase.openOrCreateDatabase(SQLiteDatabase.java:907)

Android 4.4.4 on nexus 7

[developernotes]

Hello @kivsiak

Do you only receive this on that specific device? You mention above that /icu/icudt46l.dat exists, do you actually mean /system/usr/icu/icudt46l.dat? Is loadLibs(…) running before you attempt to call SQLiteDatabase.openOrCreateDatabase?

[kivsiak]

Not a specific to device. Few devices with same problem.

/system/usr/icu/icudt46l.dat - No, mean /data/package.name/files/icu/icudt46l.dat

Yes i call loadLibs before any database operations. Worst of its not stable bug. According crashlitcs stats it happening in 2-5% of application runs. Not every one.

[laminsk]

I'm also getting the same error on nexus 5. Any help would be greatly appreciated!

[developernotes]

Hi @laminsk

Are you able to reliably reproduce the scenario on your Nexus 5. What version of Android in on your device?

[laminsk]

Thanks for the prompt reply. I have just managed to sort it out, basically removing and reinstalling the app fixed the problem. I'm running 4.4.2 and it was working alright until recently. I will keep testing and see how it goes. Many Thanks!

[draak567]

We have a commercial app deployed to a few hundred thousand users, and every once in a while, an app install breaks with this problem. The only fix is to completely remove the APK from the device (clearing the data has no effect) and to reinstall it.

Interestingly, uninstalling the APK and reinstalling the same APK always fixes the issue.

Happens very rarely. I would say less than 0.1% of installs. We've seen it internally too.

[jpuderer]

I'm also seeing this issue, and I'm unable to reproduce it reliably.

[marcardar]

There is a problem with the SQLiteDatabase.loadICUData() method: https://github.com/sqlcipher/android-database-sqlcipher/blob/master/src/net/sqlcipher/database/SQLiteDatabase.java#L87

You should delete any incomplete icudt46l.dat file in the catch{} (and also throw an exception) and also include a finally{} block to close the streams.

Furthermore, you should synchronize{} (probably easiest to just synchronize the loadLibs() method) because otherwise if two threads call loadLibs() around the same time and the first one is in the middle of extracting the zip, then the second one will proceed with the partially extracted zip.

It could be that sometimes the user is left with a corrupt icudt46l.dat file which never gets corrected until uninstall-reinstall

This might also explain observation of @draak567 (that Clear Data has no effect) in the case of insufficient storage space or repeatedly extracting zip to same broken storage area.

[developernotes]

Hi @marcardar

Thanks for the suggestions, we will definitely look to adjust this accordingly.

[brody4hire]

I also noticed the same issue in the following discussion on the new forum: https://discuss.zetetic.net/t/roots-of-the-problem-sqliteexception-not-an-error/586

For many error cases, jni/net_sqlcipher_database_SQLiteDatabase.cpp uses sqlite3_errmsg(handle) which tries to get the actual error message from the database handle. But there are certain cases where sqlite3_errmsg(handle) will return "not an error", as I found using https://www.google.com/#q=sqlite3+not+an+error and https://www.google.com/#q=sqlite3_errmsg+not+an+error:

• http://stackoverflow.com/questions/1136080/sqlite3-error-not-an-error-on-iphone-sdk
• http://iphonedevsdk.com/forum/iphone-sdk-development/49560-sqlite3-prepare-v2-returns-not-an-error-but-doesnt-write-anything.html
• http://stackoverflow.com/questions/8799848/not-an-error-in-iphone-sqlite

Looking at these links, I cannot figure out how this could happen in the native dbopen function. But in https://github.com/android/platform_frameworks_base/blob/master/core/jni/android_database_SQLiteConnection.cpp I notice the following major differences in error reporting:

• if sqlite3_open_v2() fails, they use the actual returned error code and an explicit message when raising an exception:

    int err = sqlite3_open_v2(path.string(), &db, sqliteFlags, NULL);
    if (err != SQLITE_OK) {
        throw_sqlite3_exception_errcode(env, err, "Could not open database");
        return 0;
    }

• in the other cases, if they detect a failure they just add an explicit message to describe where it failed, for example:

    if ((sqliteFlags & SQLITE_OPEN_READWRITE) && sqlite3_db_readonly(db, NULL)) {
        throw_sqlite3_exception(env, db, "Could not open the database in read/write mode.");
        sqlite3_close(db);
        return 0;
    }

I recommend that we add better error reporting to this project to avoid this kind of confusion.

[brody4hire]

Just issued PR #174 with fixes to show where SQLiteDatabase.dbopen is actually failing.