Android getting database disk image is malformed (code 11) error

Question

In my application I'm getting this database disk image is malformed (code 11) error for some users. I googled it and come to know that when db image is malformed Android deletes it and recreate new db file which is happening for some users.

The problem here is out of 10 users I'm getting this error for db is recreated only for 2-3 users, and I am unable to get reproduce this. I don't know that why this is happening. If the db is malformed for 10 users then why the android is not recreating the db for all the 10 users. Why only for those 2-3 users? Can somebody point me in the right direction how to handle it?

Update:I am still unable to reproduce the issue, but I was able to get some logs. Here they are:

08-28 08:35:44.847 E/SQLiteLog(15123): (11) database corruption at 
line 65088 of [00bb9c9ce4]
08-28 08:35:44.847 E/SQLiteLog(15123): (11) statement aborts at 67      
08-28 08:35:44.857 E/DefaultDatabaseErrorHandler(15123): Corruption 
reported by sqlite on database: 
/data/data/com.retail.posmaster/databases/GrofersRetail
08-28 08:35:45.377 D/dalvikvm(15123): GC_EXPLICIT freed 2639K, 62% 
free 7479K/19228K, paused 4ms+8ms, total 82ms
08-28 08:35:45.727 E/DefaultDatabaseErrorHandler(15123): !@ Delete old 
.mark file
08-28 08:35:45.737 E/DefaultDatabaseErrorHandler(15123): !@ DB 
Corruption has happened before this
08-28 08:35:45.757 E/DefaultDatabaseErrorHandler(15123): !@ DB 
Corruption has happened before this

Gamut

Do you have huge data on DB? – Brinker

yes my db is around 2-5 mb – Gamut

that should be normal. Is there a pattern? same device? same OS? – Brinker

no not till now and sometimes its even more around 10 or more mb – Gamut

It is a well known problem , you can take a look at https://mcmap.net/q/237604/-sqlite3-database-or-disk-is-full-the-database-disk-image-is-malformed – Co

I already have a look at it and but this is not helpful for me – Gamut

Answer 1

As I have seen many users have up voted this so I am assuming that a lot of other people are facing the same issue. We were unable to trace back this and now it's not a valid use case in our organization as we have moved away from maintaining a DB in our Android application due to some changes in product roadmap and business logic. I have done some research to find out why it was happening and I have some insights. So if your DB size is very large and you are trying to load it into the memory and you do not have sufficient memory the DB file can get corrupted. One other reason can be that you are maintaining multiple DB connections and trying to access the DB from multiple connections without closing the previous connections properly. Please try to maintain a single connection and use a content provider. The problem with the android system is if DB file is malformed or corrupted due to any reason it won't give you an exception or any other way to handle it manually by yourself. The next time when you are trying to do an operation on the DB and trying to connect to the DB file and when the system detects that the file has been corrupted, Android system recreates a fresh new file and all your data is lost. That's the default behaviour from the android system. So if you are facing this issue in your application also, try to debug for the issue why your DB file is getting corrupted because once your DB file is corrupted you can't do anything to stop this behaviour. One other thing you can do is move to some other DB like Realm. You can explore that as I am not aware of their behaviour as we only experienced this on SQLite DB.

Gamut

Answer 2

I have the same problem.

Compatibility WAL (Write-Ahead Logging) for Apps

Android 9 introduces a special mode of SQLiteDatabase called Compatibility WAL (write-ahead logging) that allows a database to use journal_mode=WAL while preserving the behavior of keeping a maximum of one connection per database.

You may try this...

public class YourSQLiteOpenHelper extends SQLiteOpenHelper {
...
@Override
public void onConfigure(SQLiteDatabase db) {
    super.onConfigure(db);
    // Disable WAL
    db.disableWriteAheadLogging();
    // Enable WAL
    // db.enableWriteAheadLogging();
}
...

Vocalic

1van are you able about recreate issue & check these changes are fixing the issue ? – Langan