'database disk image is malformed' in in-memory database
(1.1) By cmgain on 2022-06-29 08:45:30 edited from 1.0 [source]
We have a server process on RHEL using .NET System.Data.SQLite (version 1.0.115.5 with SQLite 3.37.0) as an in-memory database with connection string "FullUri=file:/RDSSVC?vfs=memdb". There are multiple threads accessing the database using their own connections, only one is modifying it.
In one of the read-only threads while running a query, we received a SQL error 'database disk image is malformed' with error code 11 - the same query is being run frequently and was fine a few seconds before and afterwards (i.e. it was executed without errors)
What could be causing this or rather how can we work out what went wrong to avoid it? Memory usage and CPU load at the time seems to have been normal.
Any pointers most welcome - Thanks!
(2) By Rowan Worth (sqweek) on 2022-06-30 07:11:37 in reply to 1.1 [link] [source]
Can you track down the compilation flags for the underlying sqlite build? Aside from a bug, the only thing that jumps out at me as a possible cause of (transient) corruption of an in-memory database is a misuse of -DSQLITE_THREADSAFE=0 at compile time, or equivalently SQLITE_CONFIG_SINGLETHREAD at runtime.
(but it seems wildly unlikely that the distributors of the .NET package would build with that flag, especially as there isn't a deluge of weird bug reports)
(3) By cmgain on 2022-06-30 09:47:15 in reply to 2 [link] [source]
Nothing obvious (to me at least) here
| compile_options |
|---|
| ATOMIC_INTRINSICS=1 |
| CODEC=see |
| COMPILER=gcc-5.4.0 20160609 |
| DEFAULT_AUTOVACUUM |
| DEFAULT_CACHE_SIZE=-2000 |
| DEFAULT_FILE_FORMAT=4 |
| DEFAULT_JOURNAL_SIZE_LIMIT=-1 |
| DEFAULT_MMAP_SIZE=0 |
| DEFAULT_PAGE_SIZE=4096 |
| DEFAULT_PCACHE_INITSZ=20 |
| DEFAULT_RECURSIVE_TRIGGERS |
| DEFAULT_SECTOR_SIZE=4096 |
| DEFAULT_SYNCHRONOUS=2 |
| DEFAULT_WAL_AUTOCHECKPOINT=1000 |
| DEFAULT_WAL_SYNCHRONOUS=2 |
| DEFAULT_WORKER_THREADS=0 |
| ENABLE_API_ARMOR |
| ENABLE_COLUMN_METADATA |
| ENABLE_DBSTAT_VTAB |
| ENABLE_FTS3 |
| ENABLE_LOAD_EXTENSION |
| ENABLE_MEMORY_MANAGEMENT |
| ENABLE_PREUPDATE_HOOK |
| ENABLE_RTREE |
| ENABLE_SESSION |
| ENABLE_STAT4 |
| ENABLE_STMTVTAB |
| ENABLE_UPDATE_DELETE_LIMIT |
| HAS_CODEC |
| MALLOC_SOFT_LIMIT=1024 |
| MAX_ATTACHED=30 |
| MAX_COLUMN=2000 |
| MAX_COMPOUND_SELECT=500 |
| MAX_DEFAULT_PAGE_SIZE=8192 |
| MAX_EXPR_DEPTH=1000 |
| MAX_FUNCTION_ARG=127 |
| MAX_LENGTH=1000000000 |
| MAX_LIKE_PATTERN_LENGTH=50000 |
| MAX_MMAP_SIZE=0x7fff0000 |
| MAX_PAGE_COUNT=1073741823 |
| MAX_PAGE_SIZE=65536 |
| MAX_SQL_LENGTH=1000000000 |
| MAX_TRIGGER_DEPTH=1000 |
| MAX_VARIABLE_NUMBER=32766 |
| MAX_VDBE_OP=250000000 |
| MAX_WORKER_THREADS=8 |
| MUTEX_PTHREADS |
| SOUNDEX |
| SYSTEM_MALLOC |
| TEMP_STORE=1 |
| THREADSAFE=1 |
| USE_URI |
(4) By mistachkin on 2022-06-30 17:25:07 in reply to 3 [link] [source]
Are you able to share the schema of the database(s) involved and the sequence of SQL commands that led up to this?
(5) By cmgain on 2022-07-07 11:09:13 in reply to 4 [link] [source]
Not really :-(
Apart from this one incidence, it is working fine. Just a bunch of straightforward tables and queries against them - all fairly basic and not even SQLite specific.
(6) By mistachkin on 2022-07-07 19:41:56 in reply to 5 [link] [source]
Perhaps your RAM experienced a cosmic ray? Do you use ECC memory?