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



_______________________________________________
DBD-SQLite mailing list
DBD-SQLite@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite

Reply via email to