On 11/06/2015 11:57 PM, Alexandre Mainville wrote: > Hi, > > I am experiencing database corruption using zipvfs on android 64 > bits (x86_64). > The same program executing on 32 bits runs without problems. > > The program creates a new database on every run and does a series of > inserts and updates (always the same series of operations). > > Both programs produce the same SQLITE_DEBUG trace up until the point the 64 > bit version outputs: > zipvfs database is corrupt. Line 1100 of [9d6c1880fb] > because of a zero size payload in a slot header. > > I am waiting on a device to test behavior with arm64-v8a. > > I am using sqlite 3.8.8.3 and zipvfs 3.8.8. > > If anyone has experienced the same or has some insight on this, it would be > greatly appreciated.
Are you able to run this on a workstation? If so, try running the program under valgrind ( http://valgrind.org ). One way to debug this might be to run the zipvfs integrity-check (i.e. ZIPVFS_CTRL_INTEGRITY_CHECK) after each transaction. If you can figure out which transaction is introducing the corruption and take a copy of the database before and after it is executed, we might be able to figure out what is going on based on that and the log below. Another would be to capture the statements executed using an sqlite3_trace() callback, then try to use them to reproduce the corruption using the shell tool. Even if that doesn't produce the corruption, it will be worth running such a script under valgrind to search for uninitialized variable problems etc. I can't see any bugfixes in the changelog since 3.8.8 to do with corrupt databases, but it might be worth upgrading to the latest zipvfs and sqlite to check if the problem is still present anyway. Regards, Dan.
