Bug #32100 for DBD-SQLite: t/06error.t fails using SQLite 3.5.4

Sat Jan 05 17:00:33 2008 wyant [...] cpan.org - Ticket created

Subject:

t/06error.t fails using SQLite 3.5.4

Test t/06error.t only runs the first of its two tests under Perl 5.10.0 under Mac OS X 10.3.9, when linked against SQLite 3.5.4. Test t/07busy.t also only runs the first four of its 8 tests. I have not looked into t/07busy.t, but t/06error.t, when run stand-alone, exits with a bus error (which I take to be actually more like "address out of bounds" or "segment violation") when attempting to execute the '$db->do (...)' inside the eval just before the second 'ok'. When linked against the bundled 3.4.2, there are no test errors in the same configuration, so I presume that it's SQLite 3.5 that's the problem. The SQLite web sute says that the API has been fiddled with for 3.5, but I have not attempted to come up with a patch. Thank you for your time, attention, and trouble, and please let me know if I can provide any additional information. The "Normal" criticality means something like "I can work with the bundled SQLite just fine, thinks, so don't declare an all-out emergency for this." Tom Wyant

Sun Jan 13 17:30:38 2008 radek [...] pld-linux.org - Correspondence added

From:

radek [...] pld-linux.org

On Linux with perl 5.8.8 and sqlite 3.5.4 only the 06error.t fails (same way, core dump on second test). Interesting: I can only replicate it when running from make; these two fail: make test TEST_FILES=t/06error.t TEST_VERBOSE=1 echo "x:\n\tprove -bdv t/06error.t" > moo; make -f moo x This succeeds: prove -bdv t/06error.t 100% reproductible. Backtrace: [...] Loaded symbols for /usr/lib/libsqlite3.so.0 Core was generated by `/usr/bin/perl5.8.8 -Iblib/arch -Iblib/lib t/06error.t'. Program terminated with signal 11, Segmentation fault. #0 0x405d0063 in sqlite3_finalize (pStmt=0x81da270) at src/vdbeapi.c:47 47 sqlite3_mutex *mutex = v->db->mutex; (gdb) bt #0 0x405d0063 in sqlite3_finalize (pStmt=0x81da270) at src/vdbeapi.c:47 #1 0x4057d34e in sqlite_st_destroy () from blib/arch/auto/DBD/SQLite/SQLite.so #2 0x40572fc0 in XS_DBD__SQLite__st_DESTROY () from blib/arch/auto/DBD/SQLite/SQLite.so #3 0x405664e6 in XS_DBI_dispatch () from /usr/lib/perl5/vendor_perl/5.8.0/i686-pld-linux-thread-multi/auto/DBI/DBI.so #4 0x400a6b48 in Perl_pp_entersub () from /usr/lib/perl5/5.8.8/i686-pld-linux-thread-multi/CORE/libperl.so.5.8.0 #5 0x400411e1 in ?? () from /usr/lib/perl5/5.8.8/i686-pld-linux-thread-multi/CORE/libperl.so.5.8.0 [...]

Sun Jan 13 17:30:40 2008 The RT System itself - Status changed from 'new' to 'open'

Mon Jan 14 12:39:11 2008 wyant [...] cpan.org - Correspondence added

From:

wyant [...] cpan.org

Hmmm. Here are my results: $ prove -bv --nocolor t/06error.t t/06error...... 1..2 # Running under perl version 5.010000 for darwin # Current time local: Mon Jan 14 12:22:21 2008 # Current time GMT: Mon Jan 14 17:22:21 2008 # Using Test.pm version 1.25 ok 1 Failed 1/2 subtests Test Summary Report ------------------- t/06error.t (Wstat: 11 Tests: 1 Failed: 0) Parse errors: Bad plan. You planned 2 tests but ran 1. Files=1, Tests=1, 1 wallclock secs ( 0.03 usr 0.03 sys + 0.18 cusr 0.06 csys = 0.30 CPU) Result: FAIL $ perl -Mblib t/06error.t 1..2 # Running under perl version 5.010000 for darwin # Current time local: Mon Jan 14 12:21:36 2008 # Current time GMT: Mon Jan 14 17:21:36 2008 # Using Test.pm version 1.25 ok 1 Segmentation fault Both also appear to be 100% reproduceable. My 'prove' does not have -d; it is based on App::Prove 3.07. At this point I'm not sure where to go. I have seen code that failed under 'make test' but not otherwise, but never understood why, or what the difference was. I certainly don't know how to solve a problem that can't be reproduced in an environment that lets you work on it. And yet, since it fails in the test environment, this _will_ come up again. I am certainly willing to be a pair of stupid hands for you if you can think of something for me to do, since I'm the one with the environment where the failure can be reproduced. Or even to try to figure it out myself, though I can't guarantee anything.

Wed Jan 16 09:08:00 2008 SHLOMIF [...] cpan.org - Correspondence added

From:

SHLOMIF [...] cpan.org

On Mon Jan 14 12:39:11 2008, WYANT wrote: Show quoted text

> Hmmm. Here are my results: >

I'm on Mandriva Cooker Linux on kernel 2.6.24-rc7 on a P4-2.4GHz machine, and am also able to reproduce this strange problem. Here's what I discovered: 1. make test yields the following: <<<<<<<<<< Failed Test Stat Wstat Total Fail List of Failed ------------------------------------------------------------------------------- t/06error.t 0 11 2 2 2 t/08create_function.t 0 11 18 26 6-18 Show quoted text

>>>>>>>>>>

2. On a new UNIX user, make test yields only: <<<<<<<<< Failed Test Stat Wstat Total Fail List of Failed ------------------------------------------------------------------------------- t/08create_function.t 0 11 18 26 6-18 Failed 1/29 test scripts. 13/463 subtests failed. Files=29, Tests=463, 20 wallclock secs ( 2.46 cusr + 0.49 csys = 2.95 CPU) Failed 1/29 test programs. 13/463 subtests failed. make: *** [test_dynamic] Error 255 Show quoted text

>>>>>>>>>

3. Running the files using "prove" or perl -blib normally yields no problem: 4. <<<<<<<<<<<< shlomi:~/progs/Rpms/BUILD/DBD-SQLite-1.14$ perl -Mblib t/08create_function.t 1..18 # Running under perl version 5.010000 for linux # Current time local: Wed Jan 16 16:05:17 2008 # Current time GMT: Wed Jan 16 14:05:17 2008 # Using Test.pm version 1.25 ok 1 ok 2 ok 3 ok 4 ok 5 Segmentation fault shlomi:~/progs/Rpms/BUILD/DBD-SQLite-1.14$ prove -b t/08create_function.t t/08create_function....ok All tests successful. Files=1, Tests=18, 0 wallclock secs ( 0.08 cusr + 0.01 csys = 0.09 CPU) Show quoted text

>>>>>>>>>>

But it cannot be reproduced in gdb. 5. I tried running <<<<<<< ( source ~/perl.env ; /usr/bin/perl5.10.0 "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t ) Show quoted text

>>>>>>>

and it worked. perl.env is the environment that perl runs under during "make test". ------------------- It's a very strange bug, indeed. Regards, Shlomi Fish

Mon Mar 10 15:33:59 2008 ntyni [...] iki.fi - Correspondence added

From:

ntyni [...] iki.fi

This is the same problem as ticket #30558, and there's a fix there. Just use sqlite3_reset() instead of sqlite3_finalize() in the two places in dbdimp.c that already have a comment to the same effect. It looks like SQLite 3.5 is less forgiving about this long-standing bug in DBD-SQLite, causing an assertion failure and an abort trap for us. FWIW, this also Debian bug #470281 (http://bugs.debian.org/470281). The same bug is also causing a DBIx-Class test failure, see ticket #33308. Cheers, -- Niko Tyni / Debian Perl Group ntyni@debian.org

Tue Mar 11 05:02:18 2008 islue [...] cpan.org - Cc ISLUE added

Tue Mar 11 20:14:29 2008 wyant [...] cpan.org - Correspondence added

On Mon Mar 10 15:33:59 2008, ntyni@iki.fi wrote: Show quoted text

> This is the same problem as ticket #30558, and there's a fix there. Just > use sqlite3_reset() instead of sqlite3_finalize() in the two places in > dbdimp.c that already have a comment to the same effect.

Exactly right. With the change, I get no test errors building against SQLite 3.5.6. I guess the title didn't jump out at me when I originally looked to see if I was reporting a known bug. Thanks for the tip-off. Tom Wyant

Wed Mar 19 18:18:44 2008 cweyl [...] alumni.drew.edu - Correspondence added

Subject:	[rt.cpan.org #32100]
Date:	Wed, 19 Mar 2008 15:18:14 -0700
To:	bug-DBD-SQLite [...] rt.cpan.org
From:	"Chris Weyl" <cweyl [...] alumni.drew.edu>

This bug is also addressed in Fedora at: https://bugzilla.redhat.com/show_bug.cgi?id=245699 -- Chris Weyl Ex astris, scientia

Fri Apr 03 23:02:01 2009 adamk [...] cpan.org - Correspondence added

This should now be resolved in 1.19_07

Fri Apr 03 23:02:09 2009 adamk [...] cpan.org - Status changed from 'open' to 'resolved'