Branko Čibej <brane_at_apache.org> writes:
> It is reproducible whether run as a single test, all of fs-test or the
> whole test suite; but only with SQLite 184.108.40.206. 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 220.127.116.11 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 18.104.22.168.
However, this failure is specific to SQLite that is shipped with OS X.
Official versions (including 22.214.171.124 from ) 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
Could you please confirm this by running the test with the official 126.96.36.199
Received on 2016-11-24 00:05:48 CET