I can now reliably corrupt the database using standard commands. An SQL script can be downloaded at the address below that creates a database and then stresses it until a corruption happens.
http://www.emclient.com/temp/sqlite_corrupt_log.zip Please help fix the problem or at least confirm that others can reproduce it using the same script. Best regards, Filip Navara On Fri, Aug 20, 2010 at 5:25 PM, Filip Navara <filip.nav...@gmail.com> wrote: > Hello, > > is there anybody willing to help analyze corrupted database for > possible bug in SQLite? > > It is a database file taken from one of our test machines and it is > only few days old at most. The database file was only ever accessed > with SQLite 3.7.0.1. It has page size of 1024, WAL mode, > synchronous=FULL and incremental vacuum. No power failure happened on > that machine. Apparently somewhere during the course of execution of > our application the database free page list become corrupted. This is > for the third time this week the same error happened, but only this > time I have a copy of the database file. It is 887 Mb big (although > the real data consume less than 2 Mb) and so it is rather problematic > to provide the file. A copy is available at > http://www.emclient.com/temp/mail_data.zip. > > The database was accessed on Windows machine using SQLite 3.7.0.1 > 64-bit build. The following statements are the only ones that were > executed against the database besides SELECTs and initial schema > definition: > > INSERT INTO LocalMailContents ( > "id", "partName", "contentType", "contentId", > "contentDescription", "contentTransferEncoding", > "contentMD5", "contentDisposition", "contentLanguage", > "contentLocation", "partHeader", "partBody", > "synchronizationKey", "contentLength") > VALUES > (@id, @partName, @contentType, @contentId, @contentDescription, > �...@contenttransferencoding, @contentMD5, @contentDisposition, > �...@contentlanguage, @contentLocation, @partHeader, @partBody, > �...@synchronizationkey, @contentLength) > UPDATE LocalMailContents SET synchronizationk...@synchronizationkey > WHERE i...@id AND partna...@partname > UPDATE LocalMailContents SET parthead...@partheader WHERE i...@id AND > partna...@partname > UPDATE LocalMailContents SET partbo...@partcontent WHERE i...@id AND > partna...@partname > DELETE FROM LocalMailContents WHERE id IN (<list of oids>); > PRAGMA freelist_count; > PRAGMA incremental_vacuum(<a number between 24 and 4096>); > > The error messages produced by "pragma integrity_check" are > > *** in database main *** > Main freelist: invalid page number 866828 > Page 396 is never used > Page 473 is never used > Page 14780 is never used > Page 14915 is never used > Page 153649 is never used > Page 210894 is never used > Page 319247 is never used > Page 397006 is never used > Page 416545 is never used > Page 416636 is never used > Page 416704 is never used > Page 416705 is never used > Page 416706 is never used > Page 416707 is never used > Page 416708 is never used > Page 416710 is never used > Page 416711 is never used > ... > > I tried to locate the missing freelist pages in the database file and > they definitely were there at some point, but I am not familiar enough > with the file format to track the whole freelist and find where the > corruption exactly happen. All I know is that page 388 is corrupted > and points to a location outside of the database file. > > Thanks, > Filip Navara > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
