Skip Menu |
 

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

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

People
Owner: Nobody in particular
Requestors: BENBOOTH [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 1.38_01
Fixed in: (no value)



Subject: Can't load SQLite::VirtualTable extension via DBD::SQLite
Download (untitled) / with headers
text/plain 544b
When I try to load the SQLite::VirtualTable extension module using "select load_extension('perlvtab.so')", the next time I try to execute another query, the program exits and I get the following error message: Can't make DBI com handle for DBD::SQLite::st: unknown package. Running the same commands under the sqlite3 shell does not have this problem. I attached a test case that demonstrates the problem. I have only tried it with the SQLite::VirtualTable extension module. I have tested it on ArchLinux 64-bit and Mac OS X 10.8 64-bit.
Subject: test.pl
Download test.pl
text/x-perl 500b
#!/usr/bin/env perl use DBI; use File::Temp; use Text::CSV; use strict; use warnings; my $dbh = DBI->connect("dbi:SQLite::memory:", undef, undef, { RaiseError=>1, PrintError=>1, }); # load the virtual table extension $dbh->sqlite_enable_load_extension(1); my $libname = shift || '/usr/local/lib/perlvtab.so'; my $sth; $sth = $dbh->prepare('select load_extension('.$dbh->quote($libname).')'); $sth->execute; my $sth2 = $dbh->prepare('create table t (c1 text);'); $sth2->execute; ok(1);
Download (untitled) / with headers
text/plain 1015b
Hi. Could you also check a few things? 1) Does sqlite_load_extension() (introduced in 1.38_01) work for you? 2) Have you SQLite::VirtualTable compiled with "correct" (or at least recent enough) sqlite3 headers? The module seems to use system- installed headers, but they are not always the same as used to build DBD::SQLite (compare $DBD::SQLite::sqlite_version and `sqlite3 - version`). On Sat Oct 20 06:50:39 2012, BENBOOTH wrote: Show quoted text
> When I try to load the SQLite::VirtualTable extension module using > "select > load_extension('perlvtab.so')", the next time I try to execute another > query, the program exits > and I get the following error message: > > Can't make DBI com handle for DBD::SQLite::st: unknown package. > > Running the same commands under the sqlite3 shell does not have this > problem. > > I attached a test case that demonstrates the problem. I have only > tried it with the > SQLite::VirtualTable extension module. I have tested it on ArchLinux > 64-bit and Mac OS X 10.8 > 64-bit.
Download (untitled) / with headers
text/plain 1.6k
Sorry it took so long to reply: On Fri Oct 19 22:38:40 2012, ISHIGAKI wrote: Show quoted text
> Hi. Could you also check a few things? > > 1) Does sqlite_load_extension() (introduced in 1.38_01) work for you?
No, I get the same error: Can't make DBI com handle for DBD::SQLite::st: unknown package. I attached the modified version of test.pl which uses sqlite_load_extension(). Show quoted text
> > 2) Have you SQLite::VirtualTable compiled with "correct" (or at least > recent enough) sqlite3 headers? The module seems to use system- > installed headers, but they are not always the same as used to build > DBD::SQLite (compare $DBD::SQLite::sqlite_version and `sqlite3 - > version`).
Here are the versions on Mac OS X 10.8.2: $ sqlite3 --version 3.7.14 2012-09-03 15:42:36 c0d89d4a9752922f9e367362366efde4f1b06f2a $ perl -MDBD::SQLite -le 'print $DBD::SQLite::sqlite_version' 3.7.14 And on my up-to-date ArchLinux machine: $ sqlite3 --version 3.7.14.1 2012-10-04 19:37:12 091570e46d04e84b67228e0bdbcd6e1fb60c6bdb $ perl -MDBD::SQLite -le 'print $DBD::SQLite::sqlite_version' 3.7.14 Ben Show quoted text
> > > > On Sat Oct 20 06:50:39 2012, BENBOOTH wrote:
> > When I try to load the SQLite::VirtualTable extension module using > > "select > > load_extension('perlvtab.so')", the next time I try to execute another > > query, the program exits > > and I get the following error message: > > > > Can't make DBI com handle for DBD::SQLite::st: unknown package. > > > > Running the same commands under the sqlite3 shell does not have this > > problem. > > > > I attached a test case that demonstrates the problem. I have only > > tried it with the > > SQLite::VirtualTable extension module. I have tested it on ArchLinux > > 64-bit and Mac OS X 10.8 > > 64-bit.
> >
Subject: test.pl
Download test.pl
text/x-perl 468b
#!/usr/bin/env perl use Test::Simple tests=>1; use DBI; use File::Temp; use Text::CSV; use strict; use warnings; my $dbh = DBI->connect("dbi:SQLite::memory:", undef, undef, { RaiseError=>1, PrintError=>1, }); # load the virtual table extension $dbh->sqlite_enable_load_extension(1); my $libname = shift || '/usr/local/lib/perlvtab.so'; $dbh->sqlite_load_extension($libname); my $sth2 = $dbh->prepare('create table t (c1 text);'); $sth2->execute; ok(1);
Download (untitled) / with headers
text/plain 839b
On Thu Oct 25 13:43:06 2012, BENBOOTH wrote: Show quoted text
> > 1) Does sqlite_load_extension() (introduced in 1.38_01) work for
> you? > > No, I get the same error: > > Can't make DBI com handle for DBD::SQLite::st: unknown package.
After some further investigation, I realized that SQLite::VirtualTable is spawning its own perl interpreter. I think what's happening is that, for some reason, having two perl interpreters running in the same process is causing perl to throw weird errors and terminate. The two perl interpreters are somehow stepping on each other and that's why it keeps failing. I filed a bug report with the SQLite::VirtualTable author, but got no response. It seems like perl supports having multiple interpreters in the same process, so I'm not sure which module is at fault here, or whether this is a bug in perl itself.
Download (untitled) / with headers
text/plain 338b
I tracked down the problem to SQLite::VirtualTable not using Perl_get_context() and PERL_SET_CONTEXT to switch contexts between the main perl interpreter and the interpreter it spawns. I wrote a patch and submitted it to the bug report for SQLite::VirtualTable. Since this problem isn't caused by DBD::SQLite I will close this ticket.


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.