[DBD-SQLite] SQLite 3.7.0 now in SVN - new bugs to fix

[Stefan Evert]

On 22 Jul 2010, at 04:54, Darren Duncan wrote:

> From my own testing, the simple substitution of 3.7.0 for the previous 3.6.23.1 broke a couple of our tests:
> 
> t/08_busy.t                            (Wstat: 512 Tests: 23 Failed: 2)
>  Failed tests:  11, 22
>  Non-zero exit status: 2
> t/28_schemachange.t                    (Wstat: 512 Tests: 9 Failed: 2)
>  Failed tests:  7-8
>  Non-zero exit status: 2
> 
> ... and these cite 'disk I/O error' as the problem.
> 

Same here (Mac OS X 10.6.4 with system Perl):

> t/08_busy.t .............................. 11/23 
> #   Failed test at t/08_busy.t line 101.
> # Your testing environment might be too slow to pass this test: DBD::SQLite::db do failed: disk I/O error at t/08_busy.t line 100, <READER> line 1.
> t/08_busy.t .............................. 22/23 
> #   Failed test at t/08_busy.t line 101.
> # Your testing environment might be too slow to pass this test: DBD::SQLite::db do failed: disk I/O error at t/08_busy.t line 100, <READER> line 2.
> # Looks like you failed 2 tests of 23.
> t/08_busy.t .............................. Dubious, test returned 2 (wstat 512, 0x200)

> t/28_schemachange.t ...................... 6/9 DBD::SQLite::db do failed: disk I/O error at t/28_schemachange.t line 56.
> 
> #   Failed test 'DROP TABLE table1'
> #   at t/28_schemachange.t line 56.
> # Error: 'disk I/O error'
> DBD::SQLite::db do failed: disk I/O error at t/28_schemachange.t line 57.
> 
> #   Failed test 'CREATE TABLE table2 (id INTEGER NOT NULL, name CHAR (64) NOT NULL)'
> #   at t/28_schemachange.t line 57.
> # Error: 'disk I/O error'
> # Looks like you failed 2 tests of 9.
> t/28_schemachange.t ...................... Dubious, test returned 2 (wstat 512, 0x200)

I don't have time to investigate right now, but both failing tests seem to be connected with concurrent access to a table by two forked processes (the test script forks a child, which does concurrent access).

At least in the second case, the DROP TABLE and CREATE TABLE commands are issued by the main process (after the child has dropped table2) and are supposed to succeed, so I believe there's something else going on than changed error codes (unless they trigger a bug within SQLite itself).

Best,
Stefan