Skip Menu |
 

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

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

People
Owner: Nobody in particular
Requestors: nn6eumtr [...] gmail.com
Cc: perl-cpan [...] bereft.net
AdminCc:

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



Subject: DBD::SQLITE Error Report
Date: Sat, 28 Oct 2006 19:02:52 -0400
To: bug-DBD-SQLite [...] rt.cpan.org
From: "Private and Confidential" <nn6eumtr [...] gmail.com>
The "closing dbh with active statement handles" problem still exists in v1.13 of the module. This sample program shows the bug: #!/usr/local/bin/perl -w use DBI; use strict; my $dbh = DBI->connect("dbi:SQLite:dbname=testdb", '', '', {RaiseError => 1, AutoCommit => 0}); my $sql = "SELECT * FROM main"; my $sth = $dbh->prepare($sql) or warn $dbh->errstr; $sth->execute or warn $dbh->errstr; while(my @row = $sth->fetchrow_array) { #print join(', ', @$row) . "\n"; } $sth->finish or warn $dbh->errstr; #undef $sth; $dbh->rollback or warn $dbh->errstr; $dbh->disconnect or warn $dbh->errstr; If you uncomment the "undef $sth" line then the error goes away. I've used DBI with Oracle and Sybase, and I believe sth->finish should release the handle and it shouldn't require the explicit undef. Perl -v output is: Summary of my perl5 (revision 5 version 8 subversion 8) configuration: Platform: osname=linux, osvers=2.6.8-3-686, archname=i686-linux-thread-multi-64int uname='linux debian 2.6.8-3-686 #1 sat jul 15 10:32:25 utc 2006 i686 gnulinux ' config_args='' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=define use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include' ccversion='', gccversion='3.4.4 20050314 (prerelease) (Debian 3.4.3-13)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc libc=/lib/libc-2.3.2.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.3.2' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/local/lib/perl5/5.8.8/i686-linux-thread-multi-64int/CORE' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API Built under linux Compiled at Oct 22 2006 10:34:53 @INC: /usr/local/lib/perl5/5.8.8/i686-linux-thread-multi-64int /usr/local/lib/perl5/5.8.8 /usr/local/lib/perl5/site_perl/5.8.8/i686-linux-thread-multi-64int /usr/local/lib/perl5/site_perl/5.8.8 /usr/local/lib/perl5/site_perl The version of SQLITE I am using is 3.3.8.
Subject: Re: [rt.cpan.org #22688] AutoReply: DBD::SQLITE Error Report
Date: Mon, 6 Nov 2006 21:04:54 -0500
To: bug-DBD-SQLite [...] rt.cpan.org
From: "Private and Confidential" <nn6eumtr [...] gmail.com>
Download (untitled) / with headers
text/plain 406b
I have found the same results using USE_LOCAL_SQLITE=1 and using the 3.3.8shared library already installed on my system. A test program I wrote in C did not have any active handle issues so it must be something with the perl interface. I don't see any calls to sqlite3_finalize and that is probably the issue. I am hoping someone more familiar with writing DBDs can determine where the finalize should go.
Subject: Re: [rt.cpan.org #22688] AutoReply: DBD::SQLITE Error Report
Date: Wed, 22 Nov 2006 11:13:19 -0500
To: bug-DBD-SQLite [...] rt.cpan.org
From: "Private and Confidential" <nn6eumtr [...] gmail.com>
Download (untitled) / with headers
text/plain 581b
I've built the exact same version of Perl / dbd::sqlite on a Solaris machine and I've been unable to reproduce this bug there. The main differences: * Linux version was built with GCC, Solaris was built with a native compiler * Linux version had 64-bit integers, Solaris had 64-bit integers and memory model Otherwise I followed the same procedure for both. This suggests to me that something in the dbd::sqlite module is being miscompiled by GCC, or we are hitting an #ifdef that based on platform or memory module, is inadvertently missing a free on the Linux configuration.
From: ntyni [...] iki.fi
Download (untitled) / with headers
text/plain 845b
On Sat Oct 28 19:04:01 2006, nn6eumtr@gmail.com wrote: Show quoted text
> The "closing dbh with active statement handles" problem still exists > in > v1.13 of the module.
Hi, this has been reported on Debian as well as bug #390144 [1]. Another testcase can be found in the report. Apparently DBD::SQLite doesn't call sqlite3_finalize() for prepared statements at disconnect time, resulting in sqlite3_close() getting SQLITE_BUSY. A workaround is to explicitly undefine the prepared handle object, so that sqlite_st_destroy() gets called. In my understanding the code should keep track of the prepared handles so it can destroy them when disconnecting, as suggested in eg. the DBI::DBD documentation [2]. [1] http://bugs.debian.org/390144 [2] http://search.cpan.org/~timb/DBI/lib/DBI/DBD.pm#The_dbd_db_disconnect_method Cheers, -- Niko Tyni <ntyni@iki.fi>
Subject: Re: [rt.cpan.org #22688] DBD::SQLITE Error Report
Date: Wed, 29 Nov 2006 15:59:59 -0700
To: bug-DBD-SQLite [...] rt.cpan.org
From: "Private and Confidential" <nn6eumtr [...] gmail.com>
Download (untitled) / with headers
text/plain 1.1k
Perfect! I'm hoping the author reads these reports because it looks like we have some good test cases. On 11/26/06, ntyni@iki.fi via RT <bug-DBD-SQLite@rt.cpan.org> wrote: Show quoted text
> > > <URL: http://rt.cpan.org/Ticket/Display.html?id=22688 > > > On Sat Oct 28 19:04:01 2006, nn6eumtr@gmail.com wrote:
> > The "closing dbh with active statement handles" problem still exists > > in > > v1.13 of the module.
> > Hi, > > this has been reported on Debian as well as bug #390144 [1]. Another > testcase can be found in the report. > > Apparently DBD::SQLite doesn't call sqlite3_finalize() for prepared > statements at disconnect time, resulting in sqlite3_close() getting > SQLITE_BUSY. A workaround is to explicitly undefine the prepared handle > object, so that sqlite_st_destroy() gets called. > > In my understanding the code should keep track of the prepared handles > so it can destroy them when disconnecting, as suggested in eg. the > DBI::DBD documentation [2]. > > [1] http://bugs.debian.org/390144 > > [2] > > http://search.cpan.org/~timb/DBI/lib/DBI/DBD.pm#The_dbd_db_disconnect_method > > Cheers, > -- > Niko Tyni <ntyni@iki.fi> >
Should be resolved now


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.