Branko Čibej <[email protected]> writes: > It is reproducible whether run as a single test, all of fs-test or the > whole test suite; but only with SQLite 3.8.10.2. I suspect it is a test > bug, but haven't followed up; could be due to a bug in SQLite itself, > e.g., that the older version returns the wrong error code. > > The only potential problem as far as I can see is that 3.8.10.2 is the > version of SQLite shipped with OSX — hence, the version that most > binaries will be linking with.
Well, it gets interesting. I can reproduce the failure under OS X 10.11 with bundled SQLite 3.8.10.2. However, this failure is specific to SQLite that is shipped with OS X. Official versions (including 3.8.10.2 from [1]) return SQLITE_BUSY, as promised in the documentation, and the test passes. `dtrace` shows that the version shipped with OS X is heavily patched. There's a different syscall pattern: guarded_open_np/guarded_pwrite_np/ guarded_close_np instead of open/write/close, pread instead of lseek+read, different fcntl calls, etc. The sqlite3.h headers are also a bit different. I would guess that SQLite version shipped with OS X has a custom VFS implementation, which doesn't keep some of the promises of the official version, or contains a bug that results in an I/O error instead of expected SQLITE_BUSY error. Could you please confirm this by running the test with the official 3.8.10.2 from [1]? [1] https://sqlite.org/2015/sqlite-amalgamation-3081002.zip Thanks, Evgeny Kotkov
