Skip Menu |
 

This queue is for tickets about the DBD-SQLite CPAN distribution.

Report information
The Basics
Id: 47983
Status: resolved
Priority: 0/
Queue: DBD-SQLite

People
Owner: Nobody in particular
Requestors: igor.bujna [...] post.cz
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

Attachments
DBD-SQLite-old-sqlite-workaround-20100531.patch.diff



Subject: DBD-SQLite with mod_perl
Date: Thu, 16 Jul 2009 10:00:04 +0200 (CEST)
To: bug-DBD-SQLite [...] rt.cpan.org
From: igor.bujna [...] post.cz
Download (untitled) / with headers
text/plain 3.2k
Good morning, I have little problem with implementation DBD-SQLite and mod_perl. Everything is operated on the last updated version of CentOS-5.2 and version DBD-SQLite is 1.25. When using the console, the program show all as it should be. But when using Apache and mod_perl than i have some problem. Configuration for apache Alias / test-cgi / tmp / test-cgi <Directory / tmp / test-cgi < AddHandler perl-script. Pl SetHandler perl-script # PerlResponseHandler ModPerl:: Registry PerlResponseHandler ModPerl:: PerlRun PerlOptions + ParseHeaders Options + ExecCGI </ Directory < This is test script #!/usr/bin/perl use strict; use DBI; my $dbh = DBI->connect("dbi:SQLite:dbname=/tmp/sqlite.db","","", {RaiseError => 1, PrintError => 1, AutoCommit => 1}); my $hash_ref = $dbh->selectall_hashref('SELECT * FROM pob ORDER BY city, c_pob;',"c_pob"); my %h_l = (); while(my($k, $d) = each %$hash_ref) { my $str = substr($d->{'city'},0,1); if (defined($str)) { my $s = uc($str); if (exists($h_l{$s})) { my $d = $h_l{$s}; push(@$d, $k); } else { $h_l{$s} = [$k]; } print $d->{'city'} . "\n"; } } $dbh->disconnect(); And there is eror in log httpd DBD::SQLite::db selectall_hashref failed: not an error at /tmp/test-cgi/test.pl line 11. [Wed Jul 15 23:14:08 2009] [error] DBD::SQLite::db selectall_hashref failed: not an error at /tmp/test-cgi/test.pl line 11.\n ModPerl::ROOT::ModPerl::PerlRun::tmp_test_cgi_test_2epl::handler('Apache2::RequestRec=SCALAR(0x802f4d84)') called at /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/ModPerl/RegistryCooker.pm line 204 eval {...} called at /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/ModPerl/RegistryCooker.pm line 204 ModPerl::RegistryCooker::run('ModPerl::PerlRun=HASH(0x8074ea00)') called at /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/ModPerl/RegistryCooker.pm line 170 ModPerl::RegistryCooker::default_handler('ModPerl::PerlRun=HASH(0x8074ea00)') called at /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/ModPerl/PerlRun.pm line 31 ModPerl::PerlRun::handler('ModPerl::PerlRun', 'Apache2::RequestRec=SCALAR(0x802f4d84)') called at -e line 0 eval {...} called at -e line 0 [Wed Jul 15 23:02:39 2009] [error] DBD::SQLite::db selectall_hashref failed: not an error at /tmp/test-cgi/test.pl line 33.\n at /tmp/test-cgi/test.pl line 33\n\tModPerl::ROOT::ModPerl::PerlRun::tmp_test_cgi_test_2epl::handler('Apache2::RequestRec=SCALAR(0x802f4d84)') called at /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/ModPerl/RegistryCooker.pm line 204\n\teval {...} called at /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/ModPerl/RegistryCooker.pm line 204\n\tModPerl::RegistryCooker::run('ModPerl::PerlRun=HASH(0x8074ea00)') called at /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/ModPerl/RegistryCooker.pm line 170\n\tModPerl::RegistryCooker::default_handler('ModPerl::PerlRun=HASH(0x8074ea00)') called at /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/ModPerl/PerlRun.pm line 31\n\tModPerl::PerlRun::handler('ModPerl::PerlRun', 'Apache2::RequestRec=SCALAR(0x802f4d84)') called at -e line 0\n\teval {...} called at -e line 0\n
Subject: Re: DBD-SQLite with mod_perl
Date: Sat, 18 Jul 2009 00:09:23 +0200 (CEST)
To: bug-DBD-SQLite [...] rt.cpan.org
From: igor.bujna [...] post.cz
Download (untitled) / with headers
text/plain 3.5k
Hello, i found this problem. Everything OK is in version 1.13 or 1.14, but in version 1.19 to newest 1.26 make this problem. Thank you nad bye Igor Bujna Show quoted text
> Good morning, > I have little problem with implementation DBD-SQLite and mod_perl. Everything > is operated on the last updated version of CentOS-5.2 and version DBD-SQLite is > 1.25. > When using the console, the program show all as it should be. But when using > Apache and mod_perl than i have some problem. > > Configuration for apache > > Alias / test-cgi / tmp / test-cgi > <Directory / tmp / test-cgi < > AddHandler perl-script. Pl > SetHandler perl-script > # PerlResponseHandler ModPerl:: Registry > PerlResponseHandler ModPerl:: PerlRun > PerlOptions + ParseHeaders > Options + ExecCGI > </ Directory < > > This is test script > > #!/usr/bin/perl > > use strict; > use DBI; > my $dbh = DBI->connect("dbi:SQLite:dbname=/tmp/sqlite.db","","", > {RaiseError => 1, PrintError => 1, AutoCommit => 1}); > > my $hash_ref = $dbh->selectall_hashref('SELECT * FROM pob ORDER BY city, > c_pob;',"c_pob"); > > my %h_l = (); > while(my($k, $d) = each %$hash_ref) { > my $str = substr($d->{'city'},0,1); > if (defined($str)) { > my $s = uc($str); > if (exists($h_l{$s})) { > my $d = $h_l{$s}; > push(@$d, $k); > } else { > $h_l{$s} = [$k]; > } > print $d->{'city'} . "\n"; > } > } > $dbh->disconnect(); > > > And there is eror in log httpd > > DBD::SQLite::db selectall_hashref failed: not an error at /tmp/test-cgi/test.pl > line 11. [Wed Jul 15 23:14:08 2009] [error] DBD::SQLite::db selectall_hashref > failed: not an error at /tmp/test-cgi/test.pl line 11.\n > ModPerl::ROOT::ModPerl::PerlRun::tmp_test_cgi_test_2epl::handler('Apache2::RequestRec=SCALAR(0x802f4d84)') > called at > /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/ModPerl/RegistryCooker.pm > line 204 eval {...} called at > /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/ModPerl/RegistryCooker.pm > line 204 ModPerl::RegistryCooker::run('ModPerl::PerlRun=HASH(0x8074ea00)') > called at > /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/ModPerl/RegistryCooker.pm > line 170 > ModPerl::RegistryCooker::default_handler('ModPerl::PerlRun=HASH(0x8074ea00)') > called at > /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/ModPerl/PerlRun.pm line > 31 ModPerl::PerlRun::handler('ModPerl::PerlRun', > 'Apache2::RequestRec=SCALAR(0x802f4d84)') called at -e line 0 eval {...} called > at -e line 0 [Wed Jul 15 23:02:39 2009] [error] DBD::SQLite::db > selectall_hashref failed: not an error at /tmp/test-cgi/test.pl line 33.\n at > /tmp/test-cgi/test.pl line > 33\n\tModPerl::ROOT::ModPerl::PerlRun::tmp_test_cgi_test_2epl::handler('Apache2::RequestRec=SCALAR(0x802f4d84)') > called at > /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/ModPerl/RegistryCooker.pm > line 204\n\teval {...} called at > /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/ModPerl/RegistryCooker.pm > line 204\n\tModPerl::RegistryCooker::run('ModPerl::PerlRun=HASH(0x8074ea00)') > called at > /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/ModPerl/RegistryCooker.pm > line > 170\n\tModPerl::RegistryCooker::default_handler('ModPerl::PerlRun=HASH(0x8074ea00)') > called at > /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/ModPerl/PerlRun.pm line > 31\n\tModPerl::PerlRun::handler('ModPerl::PerlRun', > 'Apache2::RequestRec=SCALAR(0x802f4d84)') called at -e line 0\n\teval {...} > called at -e line 0\n > >
Download (untitled) / with headers
text/plain 2.1k
Hi. I have the same problem with the same setup, CentOS 5.2. Is this a regression to the same error ("Not an error") from a bug in 2006? BTW there are a lot of these errors from building with CPAN, I do not know if they are related. Other modules with XS components are having these errors when building: gcc -c -I. -I/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/DBI -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -DVERSION=\"1.25\" -DXS_VERSION=\"1.25\" -fPIC "-I/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE" -DSQLITE_CORE -DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_COLUMN_METADATA -DNDEBUG=1 -DSQLITE_PTR_SZ=4 -DHAVE_USLEEP=1 SQLite.c SQLite.c: In function ‘boot_DBD__SQLite’: SQLite.c:1541: warning: passing argument 4 of ‘Perl_newXS’ discards qualifiers from pointer target type SQLite.c:1542: warning: passing argument 4 of ‘Perl_newXS’ discards qualifiers from pointer target type SQLite.c:1543: warning: passing argument 4 of ‘Perl_newXS’ discards qualifiers from pointer target type SQLite.c:1544: warning: passing argument 4 of ‘Perl_newXS’ discards qualifiers from pointer target type SQLite.c:1545: warning: passing argument 4 of ‘Perl_newXS’ discards qualifiers from pointer target type ... lots more ... On Fri Jul 17 22:18:17 2009, igor.bujna@post.cz wrote: Show quoted text
> Hello, > i found this problem. Everything OK is in version 1.13 or 1.14, but in > version 1.19 to newest 1.26 make this problem. > Thank you nad bye Igor Bujna >
> > Good morning, > > I have little problem with implementation DBD-SQLite and mod_perl.
> Everything
> > is operated on the last updated version of CentOS-5.2 and version
> DBD-SQLite is
> > 1.25. > > When using the console, the program show all as it should be. But
> when using
> > Apache and mod_perl than i have some problem.
Show quoted text
> > > > DBD::SQLite::db selectall_hashref failed: not an error at /tmp/test-
> cgi/test.pl
> > line 11. [Wed Jul 15 23:14:08 2009] [error] DBD::SQLite::db
> selectall_hashref
> > failed: not an error at /tmp/test-cgi/test.pl line 11.\n > >
BTW version of sqlite3 libs on my system is 3.3.6.
Download (untitled) / with headers
text/plain 915b
Igor did you recently install libapreq2 from CPAN? For a long time under CentOS 5.2, CPAN could not find libapreq2 (Apache2::Request/Apache2::Cookie). So I installed 2.12 from source. Recently after upgrading all my CPAN dependencies, libapreq2 was downloaded and installed. (Even though the same version of libapreq2 was already installed on the system.) I also had a problem with ExtUtils::CBuilder installing to the wrong path, a bug just fixed. Did CPAN rebuild libapreq2 for you? Mark On Fri Jul 17 22:18:17 2009, igor.bujna@post.cz wrote: Show quoted text
> Hello, > i found this problem. Everything OK is in version 1.13 or 1.14, but in > version 1.19 to newest 1.26 make this problem. > Thank you nad bye Igor Bujna >
> > Good morning, > > I have little problem with implementation DBD-SQLite and mod_perl.
> Everything
> > is operated on the last updated version of CentOS-5.2 and version
> DBD-SQLite is
> > 1.25.
Download (untitled) / with headers
text/plain 228b
I can no longer build libapreq2 or Encode::Detect either. I think that something in ExtUtils::ParseXS or ExtUtils::CBuilder was changed recently that causes problems with perl 5.8.8. WTF is going on? CentOS CPAN seems hosed.
Subject: Re: [rt.cpan.org #47983] Re: DBD-SQLite with mod_perl
Date: Thu, 23 Jul 2009 12:01:01 +0200 (CEST)
To: bug-DBD-SQLite [...] rt.cpan.org
From: igor.bujna [...] post.cz
Download (untitled) / with headers
text/plain 784b
I try it everything on newest CentOS-5.3 and there is same problem. I try with libapreq2-2.09-0.rc2.1.el5,perl-libapreq2-2.09-0.rc2.1.el5 libapreq2-devel-2.09-0.rc2.1.el5 but same problem. I think problem is in SQLite.XS on declaration function. Show quoted text
> ------------ Původní zpráva ------------ > Od: Mark Hedges via RT <bug-DBD-SQLite@rt.cpan.org> > Předmět: [rt.cpan.org #47983] Re: DBD-SQLite with mod_perl > Datum: 23.7.2009 06:29:25 > ---------------------------------------- > <URL: https://rt.cpan.org/Ticket/Display.html?id=47983 > > > I can no longer build libapreq2 or Encode::Detect either. I think that > something in ExtUtils::ParseXS or ExtUtils::CBuilder was changed > recently that causes problems with perl 5.8.8. WTF is going on? CentOS > CPAN seems hosed. > > >
Subject: Re: [rt.cpan.org #47983] Re: DBD-SQLite with mod_perl
Date: Fri, 24 Jul 2009 03:21:12 +1000
To: bug-DBD-SQLite [...] rt.cpan.org
From: Adam Kennedy <adamkennedybackup [...] gmail.com>
Download (untitled) / with headers
text/plain 177b
I'm not able to contribute usefully to these XS discussions, but just chirping in to say if you need any dev releases or blog calls for help, let me know and I'm there. Adam K
RT-Send-CC: adam [...] ali.as, igor.bujna [...] post.cz
Download (untitled) / with headers
text/plain 1.1k
On Thu Jul 23 06:01:28 2009, igor.bujna@post.cz wrote: Show quoted text
> I try it everything on newest CentOS-5.3 and there is same problem. I > try with libapreq2-2.09-0.rc2.1.el5,perl-libapreq2-2.09-0.rc2.1.el5 > libapreq2-devel-2.09-0.rc2.1.el5 but same problem. I think problem is > in SQLite.XS on declaration function.
Maybe the patch for ExtUtils::ParseXS at https://rt.cpan.org/Ticket/Display.html?id=48104 will help? Also the people on libapreq-dev list say they think it's a buggy httpd-devel package in CentOS that includes this bug: On Thu, 23 Jul 2009, Fred Moyer wrote: Show quoted text
> Looks like dev@httpd is aware of the issue and will be releasing a > fix. Haven't tried 5.3 centos but this sounds like they shipped a > version of apache that caused this. > > http://www.mail-archive.com/dev@httpd.apache.org/msg44177.html
Igor hey what yum repo has libapreq? It's not in ATRPMS, ATR or rpmforge. On Thu Jul 23 13:21:30 2009, adam@ali.as wrote: Show quoted text
> I'm not able to contribute usefully to these XS discussions, but just > chirping in to say if you need any dev releases or blog calls for > help, let me know and I'm there.
It would be helpful to find out who can update httpd-devel in CentOS. Mark
CC: igor.bujna [...] post.cz
Subject: Re: [rt.cpan.org #47983] Re: DBD-SQLite with mod_perl
Date: Wed, 29 Jul 2009 03:17:44 +1000
To: bug-DBD-SQLite [...] rt.cpan.org
From: Adam Kennedy <adam [...] ali.as>
Download (untitled) / with headers
text/plain 1.4k
Message forwarded to the Perl code #p5p channel for you. They are on it. Adam K On Tue, Jul 28, 2009 at 2:13 PM, Mark Hedges via RT<bug-DBD-SQLite@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=47983 > > > On Thu Jul 23 06:01:28 2009, igor.bujna@post.cz wrote:
>> I try it everything on newest CentOS-5.3 and there is same problem. I >> try with libapreq2-2.09-0.rc2.1.el5,perl-libapreq2-2.09-0.rc2.1.el5 >> libapreq2-devel-2.09-0.rc2.1.el5 but same problem. I think problem is >> in SQLite.XS on declaration function.
> > Maybe the patch for ExtUtils::ParseXS at > https://rt.cpan.org/Ticket/Display.html?id=48104 will help? > > Also the people on libapreq-dev list say they think it's a buggy > httpd-devel package in CentOS that includes this bug: > > On Thu, 23 Jul 2009, Fred Moyer wrote:
>> Looks like dev@httpd is aware of the issue and will be releasing a >> fix.  Haven't tried 5.3 centos but this sounds like they shipped a >> version of apache that caused this. >> >> http://www.mail-archive.com/dev@httpd.apache.org/msg44177.html
> > Igor hey what yum repo has libapreq?  It's not in ATRPMS, ATR or rpmforge. > > On Thu Jul 23 13:21:30 2009, adam@ali.as wrote:
>> I'm not able to contribute usefully to these XS discussions, but just >> chirping in to say if you need any dev releases or blog calls for >> help, let me know and I'm there.
> > It would be helpful to find out who can update httpd-devel in CentOS. > > Mark >
RT-Send-CC: adam [...] ali.as
Download (untitled) / with headers
text/plain 223b
On Tue Jul 28 13:18:02 2009, adam@ali.as wrote: Show quoted text
> Message forwarded to the Perl code #p5p channel for you. > > They are on it.
Thanks Adam but ... what are they on to? Do we know what the actual problem is? --mark--
RT-Send-CC: igor.bujna [...] post.cz, adam [...] ali.as
Download (untitled) / with headers
text/plain 775b
On Tue Jul 28 00:13:47 2009, MARKLE wrote: Show quoted text
> On Thu Jul 23 06:01:28 2009, igor.bujna@post.cz wrote:
> > I try it everything on newest CentOS-5.3 and there is same problem. I > > try with libapreq2-2.09-0.rc2.1.el5,perl-libapreq2-2.09-0.rc2.1.el5 > > libapreq2-devel-2.09-0.rc2.1.el5 but same problem. I think problem is > > in SQLite.XS on declaration function.
> > Maybe the patch for ExtUtils::ParseXS at > https://rt.cpan.org/Ticket/Display.html?id=48104 will help?
BTW installing the latest dev release 2.20_03 of ExtUtils::ParseXS fixed problems building other modules (like Encode::Detect) but it did not help this. I deleted site_perl and rebuild everything with the new ExtUtils::ParseXS just to be safe. Same problem with DBD::SQLite under mod_perl2. --mark--
Subject: Re: [rt.cpan.org #47983] Re: DBD-SQLite with mod_perl
Date: Thu, 30 Jul 2009 20:42:56 +1000
To: bug-DBD-SQLite [...] rt.cpan.org
From: Adam Kennedy <adam [...] ali.as>
Download (untitled) / with headers
text/plain 838b
My skills don't lie in C/XS, my skills lie in the Perl layer and build engineering (and more recently development team organisation, which is how I ended up being the maintainer of DBD::SQLite despite not knowing C) :) I'm afraid I don't really know any actual details about the problem, other than that they have acknowledged it. Drop into irc.perl.org #p5p if you'd like to have an in-person discussion about it with the relevant people. Adam K On Thu, Jul 30, 2009 at 3:15 AM, Mark Hedges via RT<bug-DBD-SQLite@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=47983 > > > On Tue Jul 28 13:18:02 2009, adam@ali.as wrote:
>> Message forwarded to the Perl code #p5p channel for you. >> >> They are on it.
> > Thanks Adam but ... what are they on to? > > Do we know what the actual problem is? > > --mark-- > > >
I've just run across this bug on CentOS 5.4 with the following packages installed:
 
httpd-devel-2.2.3-31.el5.centos
httpd-2.2.3-31.el5.centos
mod_perl-2.0.4-6.el5
 
When I install DBD::SQLite versions greater than 1.14 using CPAN, they work fine from the command line but fail under mod_perl with the dreaded "not an error" error as soon as any query is attempted on the (apparently successfully connected) DBI database handle.
 
I chased it into the DBD::SQLite C code (in 1.28_02) and discovered that sqlite3SafetyCheckOk() (as called from sqlite3LockAndPrepare() as called from sqlite3_prepare_v2()) is failing because magic != SQLITE_MAGIC_OPEN.  This is check is on line 19,545 of sqlite3.c:
 
 
The actual value of magic is 0, which is not one of the expected/allowed values, as per the source:
 
/*
** Possible values for the sqlite.magic field.
** The numbers are obtained at random and have no special meaning, other
** than being distinct from one another.
*/
#define SQLITE_MAGIC_OPEN     0xa029a697  /* Database is open */
#define SQLITE_MAGIC_CLOSED   0x9f3c2d33  /* Database is closed */
#define SQLITE_MAGIC_SICK     0x4b771290  /* Error and awaiting close */
#define SQLITE_MAGIC_BUSY     0xf03b7906  /* Database currently in use */
#define SQLITE_MAGIC_ERROR    0xb5357930  /* An SQLITE_MISUSE error occurred */
 
I have no idea why this happens ONLY under mod_perl, nor how it's connected to the httpd-devel package I have installed.  Can anyone help me understand this problem or offer a solution?  This bug report is from almost six months ago.  Any progress?  How can I help?
 
Download (untitled) / with headers
text/plain 2.1k
Hi. I've not finished my investigation but as of this writing, I've confirmed that 1) recent versions of DBD::SQLite and mod_perl 2.04 work fine under Debian lenny and FreeBSD 8.0, and 2) don't work under CentOS 5.4. As they work under other platforms and DBD::SQLite itself works fine from the CentOS console, I'm vaguely suspecting some (possibly CentOS-specific) clever security stuff is preventing from their working, but it looks like they even don't work when I disable selinux, so I'm not sure. On 2010-01-06 Wed 17:57:15, JSIRACUSA wrote: Show quoted text
> I've just run across this bug on CentOS 5.4 with the following > packages > installed: httpd-devel-2.2.3-31.el5.centoshttpd-2.2.3- > 31.el5.centosmod_perl-2.0.4-6.el5 > When I install DBD::SQLite versions greater than 1.14 using CPAN, they > work > fine from the command line but fail under mod_perl with the dreaded > "not an > error" error as soon as any query is attempted on the (apparently > successfully > connected) DBI database handle. I chased it into the DBD::SQLite C > code (in > 1.28_02) and discovered that sqlite3SafetyCheckOk() (as called from > sqlite3LockAndPrepare() as called from sqlite3_prepare_v2()) is > failing because > magic != SQLITE_MAGIC_OPEN. This is check is on line 19,545 of > sqlite3.c: > http://cpansearch.perl.org/src/ADAMK/DBD-SQLite-1.28_02/sqlite3.c The > actual > value of magic is 0, which is not one of the expected/allowed values, > as per > the source: /*** Possible values for the sqlite.magic field.** The > numbers are > obtained at random and have no special meaning, other** than being > distinct > from one another.*/#define SQLITE_MAGIC_OPEN 0xa029a697 /* Database is > open */#define > SQLITE_MAGIC_CLOSED 0x9f3c2d33 /* Database is closed */#define > SQLITE_MAGIC_SICK 0x4b771290 /* Error and awaiting close */#define > SQLITE_MAGIC_BUSY 0xf03b7906 /* Database currently in use */#define > SQLITE_MAGIC_ERROR 0xb5357930 /* An SQLITE_MISUSE error occurred */ I > have no > idea why this happens ONLY under mod_perl, nor how it's connected to > the > httpd-devel package I have installed. Can anyone help me understand > this > problem or offer a solution? This bug report is from almost six months > ago. Any > progress? How can I help?
From: mozo [...] mozo.jp
Download (untitled) / with headers
text/plain 4.4k
Hi, I got a clue for this bug. One of the Apache's dependencies, libaprutil-1.so, links to /usr/lib/libsqlite3.so.0, and its symbols conflicts with those of the bundled version of sqlite3. To work around this, I had to patch Makefile.PL to do the following things: 1. Change the line "if ( 0 )" to "if ( 1 )" that follows the comment that states "this block is if ( 0 ) to discourage casualusers building against the system SQLite." 2. Apply the attached patch to Makefile.PL so that DBD::SQLite would avoid using the new API that the version of SQLite that comes up with CentOS 5 doesn't have. Hope this helps. Regards, Moriyoshi On Fri Jul 17 22:18:17 2009, igor.bujna@post.cz wrote: Show quoted text
> Hello, > i found this problem. Everything OK is in version 1.13 or 1.14, but in > version 1.19 to newest 1.26 make this problem. > Thank you nad bye Igor Bujna >
> > Good morning, > > I have little problem with implementation DBD-SQLite and mod_perl.
> Everything
> > is operated on the last updated version of CentOS-5.2 and version
> DBD-SQLite is
> > 1.25. > > When using the console, the program show all as it should be. But
> when using
> > Apache and mod_perl than i have some problem. > > > > Configuration for apache > > > > Alias / test-cgi / tmp / test-cgi > > <Directory / tmp / test-cgi < > > AddHandler perl-script. Pl > > SetHandler perl-script > > # PerlResponseHandler ModPerl:: Registry > > PerlResponseHandler ModPerl:: PerlRun > > PerlOptions + ParseHeaders > > Options + ExecCGI > > </ Directory < > > > > This is test script > > > > #!/usr/bin/perl > > > > use strict; > > use DBI; > > my $dbh = DBI->connect("dbi:SQLite:dbname=/tmp/sqlite.db","","", > > {RaiseError => 1, PrintError => 1,
> AutoCommit => 1});
> > > > my $hash_ref = $dbh->selectall_hashref('SELECT * FROM pob ORDER BY
> city,
> > c_pob;',"c_pob"); > > > > my %h_l = (); > > while(my($k, $d) = each %$hash_ref) { > > my $str = substr($d->{'city'},0,1); > > if (defined($str)) { > > my $s = uc($str); > > if (exists($h_l{$s})) { > > my $d = $h_l{$s}; > > push(@$d, $k); > > } else { > > $h_l{$s} = [$k]; > > } > > print $d->{'city'} . "\n"; > > } > > } > > $dbh->disconnect(); > > > > > > And there is eror in log httpd > > > > DBD::SQLite::db selectall_hashref failed: not an error at /tmp/test-
> cgi/test.pl
> > line 11. [Wed Jul 15 23:14:08 2009] [error] DBD::SQLite::db
> selectall_hashref
> > failed: not an error at /tmp/test-cgi/test.pl line 11.\n > >
>
ModPerl::ROOT::ModPerl::PerlRun::tmp_test_cgi_test_2epl::handler('Apache2::RequestRec=SCALAR(0x802f4d84)') Show quoted text
> > called at > > /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-
> multi/ModPerl/RegistryCooker.pm
> > line 204 eval {...} called at > > /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-
> multi/ModPerl/RegistryCooker.pm
> > line 204
> ModPerl::RegistryCooker::run('ModPerl::PerlRun=HASH(0x8074ea00)')
> > called at > > /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-
> multi/ModPerl/RegistryCooker.pm
> > line 170 > >
>
ModPerl::RegistryCooker::default_handler('ModPerl::PerlRun=HASH(0x8074ea00)') Show quoted text
> > called at > > /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-
> multi/ModPerl/PerlRun.pm line
> > 31 ModPerl::PerlRun::handler('ModPerl::PerlRun', > > 'Apache2::RequestRec=SCALAR(0x802f4d84)') called at -e line 0 eval
> {...} called
> > at -e line 0 [Wed Jul 15 23:02:39 2009] [error] DBD::SQLite::db > > selectall_hashref failed: not an error at /tmp/test-cgi/test.pl line
> 33.\n at
> > /tmp/test-cgi/test.pl line > >
>
33\n\tModPerl::ROOT::ModPerl::PerlRun::tmp_test_cgi_test_2epl::handler('Apache2::RequestRec=SCALAR(0x802f4d84)') Show quoted text
> > called at > > /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-
> multi/ModPerl/RegistryCooker.pm
> > line 204\n\teval {...} called at > > /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-
> multi/ModPerl/RegistryCooker.pm
> > line
> 204\n\tModPerl::RegistryCooker::run('ModPerl::PerlRun=HASH(0x8074ea00)')
> > called at > > /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-
> multi/ModPerl/RegistryCooker.pm
> > line > >
>
170\n\tModPerl::RegistryCooker::default_handler('ModPerl::PerlRun=HASH(0x8074ea00)') Show quoted text
> > called at > > /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-
> multi/ModPerl/PerlRun.pm line
> > 31\n\tModPerl::PerlRun::handler('ModPerl::PerlRun', > > 'Apache2::RequestRec=SCALAR(0x802f4d84)') called at -e line
> 0\n\teval {...}
> > called at -e line 0\n > > > >
Subject: DBD-SQLite-old-sqlite-workaround-20100531.patch.diff
diff -ur DBD-SQLite-1.30_02~/dbdimp.c DBD-SQLite-1.30_02/dbdimp.c --- DBD-SQLite-1.30_02~/dbdimp.c 2010-05-31 04:55:25.000000000 +0900 +++ DBD-SQLite-1.30_02/dbdimp.c 2010-05-31 05:21:48.000000000 +0900 @@ -29,6 +29,10 @@ #define sqlite_exec(h,sql) _sqlite_exec(aTHX_ h, imp_dbh->db, sql) #define sqlite_open(dbname,db) _sqlite_open(aTHX_ dbh, dbname, db) +#ifndef HAVE_SQLITE3_SQL +#define sqlite3_sql(stmt) "(prepared statement)" +#endif + static void _sqlite_trace(pTHX_ char *file, int line, SV *h, imp_xxh_t *imp_xxh, const char *what) { @@ -446,7 +450,11 @@ croak_if_db_is_null(); +#ifdef HAVE_SQLITE3_PREPARE_V2 rc = sqlite3_prepare_v2(imp_dbh->db, statement, -1, &(imp_sth->stmt), &extra); +#else + rc = sqlite3_prepare(imp_dbh->db, statement, -1, &(imp_sth->stmt), &extra); +#endif if (rc != SQLITE_OK) { sqlite_error(sth, rc, sqlite3_errmsg(imp_dbh->db)); if (imp_sth->stmt) { diff -ur DBD-SQLite-1.30_02~/Makefile.PL DBD-SQLite-1.30_02/Makefile.PL --- DBD-SQLite-1.30_02~/Makefile.PL 2010-05-31 04:55:25.000000000 +0900 +++ DBD-SQLite-1.30_02/Makefile.PL 2010-05-31 05:22:51.000000000 +0900 @@ -122,7 +122,7 @@ # the system SQLite. We expect that anyone sophisticated enough to use # a system sqlite is also sophisticated enough to have a patching system # that can change the if ( 0 ) to if ( 1 ) -my ($sqlite_local, $sqlite_base, $sqlite_lib, $sqlite_inc); +my ($sqlite_local, $sqlite_base, $sqlite_lib, $sqlite_inc, $sqlite_version); if ( 0 ) { require File::Spec; if ( $sqlite_base = (grep(/SQLITE_LOCATION=.*/, @ARGV))[0] ) { @@ -143,14 +143,14 @@ # Now check for a compatible sqlite3 unless ( $sqlite_local ) { - my ($dir, $file, $fh, $version); + my ($dir, $file, $fh, $version_string); print "Checking installed SQLite version...\n" if $ENV{AUTOMATED_TESTING}; if ( $sqlite_inc ) { open($fh, '< ' , File::Spec->catfile($sqlite_inc, 'sqlite3.h')) or die "Error opening sqlite3.h in $sqlite_inc: $!"; while ( defined($_ = <$fh>) ) { if (/\#define\s+SQLITE_VERSION_NUMBER\s+(\d+)/) { - $version = $1; + $sqlite_version = $1; last; } } @@ -163,21 +163,26 @@ open($fh, "<", $file) or die "Error opening $file: $!"; while ( defined($_ = <$fh>) ) { if (/\#define\s+SQLITE_VERSION_NUMBER\s+(\d+)/) { - $version = $1; + $sqlite_version = $1; last; } } close($fh); - last if $version; + last if $sqlite_version; } } - unless ( $version && ($version >= 3006000) ) { - warn "SQLite version must be at least 3.6.0. No header file at that\n"; + $version_string = sprintf("%d.%d.%d", int($sqlite_version / 1e6), int($sqlite_version / 1e3) % 1e2, $sqlite_version % 1e3); + unless ( $sqlite_version && ($sqlite_version >= 3003000) ) { + warn "SQLite version must be at least 3.3.0. No header file at that\n"; warn "version or higher was found. Using the local version instead.\n"; $sqlite_local = 1; undef $sqlite_lib; undef $sqlite_inc; + } elsif ( $sqlite_version >= 3003011 ) { + print "Looks good\n" if $ENV{AUTOMATED_TESTING}; } else { + warn "SQLite version should be at least 3.3.11, but I found a header file \n"; + warn "of the version $version_string. Falls back to use the deprecated interface.\n"; print "Looks good\n" if $ENV{AUTOMATED_TESTING}; } } @@ -217,6 +222,11 @@ '-DSQLITE_ENABLE_COLUMN_METADATA', '-DNDEBUG=1', ); + +if ( $sqlite_version >= 3003011 ) { + push @CC_DEFINE, '-DHAVE_SQLITE3_PREPARE_V2', '-DHAVE_SQLITE3_SQL'; +} + if ( $Config{d_usleep} || $Config{osname} =~ m/linux/ ) { push @CC_DEFINE, '-DHAVE_USLEEP=1'; }
RT-Send-CC: mozo [...] mozo.jp
Hi, moriyoshi-san. Sorry for the late reply. Thank you for a patch. It made things much clearer for me. To our sadness, however, it didn't seem to solve the whole issue. DBD::SQLite uses sqlite3_next_stmt (which requires SQLite 3.6.0) to prevent memory leaks, and sqlite3_sql (also since 3.6.0) not only to trace statements but also to fix transaction gaps between DBI and the SQLite library. Probably we can do the same things if we include sqliteInt.h to use internal stuff, but it's not available unless we get the SQLite source from the SQLite repository or a non-amalgamated tarball (i.e. installing a package like sqlite-devel doesn't work for this). Besides, DBD::SQLite is used to other modules like O/R mappers. So, DBD::SQLite is requested to be consistent, not to vary from systems to systems, as that makes their debugging much harder, not to mention ours. That's why the option to use installed library is disabled by default. I'm still wondering what's the best fix for this issue, but for now, I'm not inclined to apply your patch. It might be better to recommend for people to rebuild their apache with the latest SQLite source, but that might also cause other issues elsewhere... Anyway, thank you for your contribution, Kenichi On 2010-5-31 Mon 01:51:04, moriyoshi wrote: Show quoted text
> Hi, > > I got a clue for this bug. One of the Apache's dependencies, > libaprutil-1.so, links to /usr/lib/libsqlite3.so.0, and its symbols > conflicts with those of the bundled version of sqlite3. To work > around > this, I had to patch Makefile.PL to do the following things: > > 1. Change the line "if ( 0 )" to "if ( 1 )" that follows the comment > that states "this block is if ( 0 ) to discourage casualusers building > against the system SQLite." > > 2. Apply the attached patch to Makefile.PL so that DBD::SQLite would > avoid using the new API that the version of SQLite that comes up with > CentOS 5 doesn't have. > > Hope this helps. > > Regards, > Moriyoshi > > On Fri Jul 17 22:18:17 2009, igor.bujna@post.cz wrote:
> > Hello, > > i found this problem. Everything OK is in version 1.13 or 1.14, but
> in
> > version 1.19 to newest 1.26 make this problem. > > Thank you nad bye Igor Bujna > >
> > > Good morning, > > > I have little problem with implementation DBD-SQLite and mod_perl.
> > Everything
> > > is operated on the last updated version of CentOS-5.2 and version
> > DBD-SQLite is
> > > 1.25. > > > When using the console, the program show all as it should be. But
> > when using
> > > Apache and mod_perl than i have some problem. > > > > > > Configuration for apache > > > > > > Alias / test-cgi / tmp / test-cgi > > > <Directory / tmp / test-cgi < > > > AddHandler perl-script. Pl > > > SetHandler perl-script > > > # PerlResponseHandler ModPerl:: Registry > > > PerlResponseHandler ModPerl:: PerlRun > > > PerlOptions + ParseHeaders > > > Options + ExecCGI > > > </ Directory < > > > > > > This is test script > > > > > > #!/usr/bin/perl > > > > > > use strict; > > > use DBI; > > > my $dbh = DBI->connect("dbi:SQLite:dbname=/tmp/sqlite.db","","", > > > {RaiseError => 1, PrintError => 1,
> > AutoCommit => 1});
> > > > > > my $hash_ref = $dbh->selectall_hashref('SELECT * FROM pob ORDER
> BY
> > city,
> > > c_pob;',"c_pob"); > > > > > > my %h_l = (); > > > while(my($k, $d) = each %$hash_ref) { > > > my $str = substr($d->{'city'},0,1); > > > if (defined($str)) { > > > my $s = uc($str); > > > if (exists($h_l{$s})) { > > > my $d = $h_l{$s}; > > > push(@$d, $k); > > > } else { > > > $h_l{$s} = [$k]; > > > } > > > print $d->{'city'} . "\n"; > > > } > > > } > > > $dbh->disconnect(); > > > > > > > > > And there is eror in log httpd > > > > > > DBD::SQLite::db selectall_hashref failed: not an error at
> /tmp/test-
> > cgi/test.pl
> > > line 11. [Wed Jul 15 23:14:08 2009] [error] DBD::SQLite::db
> > selectall_hashref
> > > failed: not an error at /tmp/test-cgi/test.pl line 11.\n > > >
> >
> ModPerl::ROOT::ModPerl::PerlRun::tmp_test_cgi_test_2epl::handler
('Apache2::RequestRec=SCALAR(0x802f4d84)') Show quoted text
> > > called at > > > /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-
> > multi/ModPerl/RegistryCooker.pm
> > > line 204 eval {...} called at > > > /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-
> > multi/ModPerl/RegistryCooker.pm
> > > line 204
> > ModPerl::RegistryCooker::run('ModPerl::PerlRun=HASH(0x8074ea00)')
> > > called at > > > /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-
> > multi/ModPerl/RegistryCooker.pm
> > > line 170 > > >
> >
> ModPerl::RegistryCooker::default_handler('ModPerl::PerlRun=HASH
(0x8074ea00)') Show quoted text
> > > called at > > > /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-
> > multi/ModPerl/PerlRun.pm line
> > > 31 ModPerl::PerlRun::handler('ModPerl::PerlRun', > > > 'Apache2::RequestRec=SCALAR(0x802f4d84)') called at -e line 0 eval
> > {...} called
> > > at -e line 0 [Wed Jul 15 23:02:39 2009] [error] DBD::SQLite::db > > > selectall_hashref failed: not an error at /tmp/test-cgi/test.pl
> line
> > 33.\n at
> > > /tmp/test-cgi/test.pl line > > >
> >
> 33\n\tModPerl::ROOT::ModPerl::PerlRun::tmp_test_cgi_test_2epl::handler
('Apache2::RequestRec=SCALAR(0x802f4d84)') Show quoted text
> > > called at > > > /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-
> > multi/ModPerl/RegistryCooker.pm
> > > line 204\n\teval {...} called at > > > /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-
> > multi/ModPerl/RegistryCooker.pm
> > > line
> >
> 204\n\tModPerl::RegistryCooker::run('ModPerl::PerlRun=HASH
(0x8074ea00)') Show quoted text
> > > called at > > > /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-
> > multi/ModPerl/RegistryCooker.pm
> > > line > > >
> >
> 170\n\tModPerl::RegistryCooker::default_handler('ModPerl::PerlRun=HASH
(0x8074ea00)') Show quoted text
> > > called at > > > /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-
> > multi/ModPerl/PerlRun.pm line
> > > 31\n\tModPerl::PerlRun::handler('ModPerl::PerlRun', > > > 'Apache2::RequestRec=SCALAR(0x802f4d84)') called at -e line
> > 0\n\teval {...}
> > > called at -e line 0\n > > > > > >
> >
Download (untitled) / with headers
text/plain 148b
Closing this ticket as DBD::SQLite 1.34_01 with a fix to this problem is out. If you still experience the same problem, please reopen this. Thanks.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.