SQLiteCantOpenDatabaseException unable to open db-journal

I’m getting an exception that comes from SQLite not being able to open db-journal. I’m running a lot of queries successfully, but at some point it crashes. This happens rarely, and it is hard to reproduce.

If you google “db-journal” and SQLiteCantOpenDatabaseException , it gives a lot of similar crashes that people have (without using DBFlow), and the solution they suggest is to close the DB handle, wait a second and try to open it again.

The first question, should it be done inside DBFlow, or can it be done in my code ?

Another question is: is it possible to catch this kind of exception centrally somehow, because I don’t want to put every DBFlow call in a try-catch. (or should I?)

Device: Google Nexus 7 OS : Android 5

log:

[ 08-27 15:43:07.297  3493: 3493 E/SQLiteLog ]
(14) cannot open file at line 30046 of [9491ba7d73]
(14) os_unix.c:30046: (24) open(/data/data/com.my.app/databases/data.db-journal) - 
[ 08-27 15:43:07.297  3493: 3493 E/SQLiteLog ]
(14) statement aborts at 26: [SELECT * FROM ...] unable to open database file
FATAL EXCEPTION: main
android.database.sqlite.SQLiteCantOpenDatabaseException: unable to open database file (code 14)
    at android.database.sqlite.SQLiteConnection.nativeExecuteForCursorWindow(Native Method)
    at android.database.sqlite.SQLiteConnection.executeForCursorWindow(SQLiteConnection.java:845)
    at android.database.sqlite.SQLiteSession.executeForCursorWindow(SQLiteSession.java:836)
    at android.database.sqlite.SQLiteQuery.fillWindow(SQLiteQuery.java:62)
    at android.database.sqlite.SQLiteCursor.fillWindow(SQLiteCursor.java:144)
    at android.database.sqlite.SQLiteCursor.getCount(SQLiteCursor.java:133)
    at android.database.AbstractCursor.moveToPosition(AbstractCursor.java:197)
    at android.database.AbstractCursor.moveToFirst(AbstractCursor.java:237)
    at com.raizlabs.android.dbflow.sql.SqlUtils.convertToList(SqlUtils.java:134)
    at com.raizlabs.android.dbflow.sql.SqlUtils.queryList(SqlUtils.java:56)
    at com.raizlabs.android.dbflow.sql.language.BaseModelQueriable.queryList(BaseModelQueriable.java:35)
    at com.raizlabs.android.dbflow.sql.language.Where.queryList(Where.java:347)

[ahangchen]

I got my answer. This crash happened when I do a lot of query on my DB; Then, sqlite will open a lot of page; you can have a look at sqlite3.c or pager.c, when it failed on sqlitepcacheFetchStress() because memory limit, the pager will open a temporary file using the unixOpen(), unixOpen() will invoke unixGetTempname() to get the temp file name, unixGetTempname() will invoke unixTempFileDir() to get the directory for the temp file, and what you can see in unixTempFileDir()?

/*
** Return the name of a directory in which to put temporary files.
** If no suitable temporary file directory can be found, return NULL.
*/
static const char *unixTempFileDir(void){
  static const char *azDirs[] = {
     0,
     0,
     0,
     "/var/tmp",
     "/usr/tmp",
     "/tmp",
     0        /* List terminator */
  };
  unsigned int i;
  struct stat buf;
  const char *zDir = 0;

  azDirs[0] = sqlite3_temp_directory;
  if( !azDirs[1] ) azDirs[1] = getenv("SQLITE_TMPDIR");
  if( !azDirs[2] ) azDirs[2] = getenv("TMPDIR");
  for(i=0; i<sizeof(azDirs)/sizeof(azDirs[0]); zDir=azDirs[i++]){
    if( zDir==0 ) continue;
    if( osStat(zDir, &buf) ) continue;
    if( !S_ISDIR(buf.st_mode) ) continue;
    if( osAccess(zDir, 07) ) continue;
    break;
  }
  return zDir;
}

in android system, none of the directory is writable, so sqlite use “.” for temp file, which means current working directory. That’s all right, but what is current working directory? I use system(“ls . > /sdcarc/0.txt”); and cat the 0.txt in adb shell and found that

 current working directory is "/", the root directory of system !!!!!!

so it’s sure that sqlite can not create of open this temp file named “./etilqs_3P2SKRP0Ge6cj3T”. It means that, every app using sqlite on android system may crash for this reason.

To trigger this crash, you can insert a lot of records into you databases and repeatly do something like select * from a where a.x in (select * from b) or other things that will rapidly exhaust the memory for page, and you will trigger sqlite to open this kind of temp file and get the crash.

so how to fix the problem? Our team found a solution: execute this sql : “PRAGMA temp_store_directory=‘your_dir_name’” when you first open a database connection, so the temp dir will be set to somewhere writable.

I suggest to set the temp dir to your database directory’s subdirectory like: /data/data/packagename/my_temp_dir don’t set the directory to sdcard, which will cause a failure of fstat in sqltie,

Sqlite will automatically clear the temp files under the directory after the temp file is useless, except for some terrible condition like that sqlite opens a temp file, but crash before it removes the temp file.

Good luck.

if you can understand Chinese, you can have a look at this link: http://www.cnblogs.com/hellocwh/p/5061805.html I make a summary of this BUG.

[quibbler01]

open it！