Skip Menu |
 

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

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

People
Owner: Nobody in particular
Requestors: siracusa [...] mindspring.com
Cc:
AdminCc:

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



Subject: Spurious "not an error" and "bind or column index out of range" errirs
Download (untitled) / with headers
text/plain 1.8k
DBD::SQLite 1.13 intermittently spits out strange errors like these: DBD::SQLite::st fetchrow_hashref warning: not an error(0) at dbdimp.c line 504 DBD::SQLite::st execute failed: bind or column index out of range(25) at dbdimp.c line 376 The first one is just baffling. (Not an error?) The second one looks legit, but I tracked it down and found that the number of bind columns was correct. I tried chasing it through the C code and found a situation where the number "?" of placeholders found by DBD::SQLite was one less than the actual number of "?" in the SQL. (p->nVar was 3 when there were clearly 4 "?" placeholders in p->zSql.) This was not a complex query either, just a standard INSERT into a table with four INTEGER columns. The intermittent nature is why there's no script to reproduce this issue attached to this bug report. I wrote such a script, but then DBD::SQLite decided to start behaving itself and refused to throw the error. In much more complex code (the Rose::DB::Object test suite) it'd still happen, but not in an isolated version of the call. I even added some of the surrounding calls in an attempt to get it to fail, but eventually gave up. But the *really* strange thing is that DBD::SQLite 1.13 seems to get progressively worse as time goes on. This morning, I could run the whole Rose::DB::Object test suite against SQLite with DBD::SQLite 1.13 and I only got one "not an error" error. As the day progressed, with no code changes anywhere, it started to throw some "bind or column index out of range(25)" errors. (Yes, I deleted the SQLite database file between runs.) I downgraded to DBD::SQLite 1.12 and the test suite immediately ran without any errors at all. Sorry this is such a bad bug report. I'm still trying to isolate this, but I just thought someone should know that 1.13 is, like, totally wonky.
Download (untitled) / with headers
text/plain 2.1k
On Wed Sep 13 15:02:41 2006, JSIRACUSA wrote: Show quoted text
> DBD::SQLite 1.13 intermittently spits out strange errors like these: > > DBD::SQLite::st fetchrow_hashref warning: not an error(0) at dbdimp.c > line 504 > > DBD::SQLite::st execute failed: bind or column index out of range(25) at > dbdimp.c line 376 > > The first one is just baffling. (Not an error?) The second one looks > legit, but I tracked it down and found that the number of bind columns > was correct. I tried chasing it through the C code and found a > situation where the number "?" of placeholders found by DBD::SQLite was > one less than the actual number of "?" in the SQL. (p->nVar was 3 when > there were clearly 4 "?" placeholders in p->zSql.) This was not a > complex query either, just a standard INSERT into a table with four > INTEGER columns. > > The intermittent nature is why there's no script to reproduce this issue > attached to this bug report. I wrote such a script, but then > DBD::SQLite decided to start behaving itself and refused to throw the > error. In much more complex code (the Rose::DB::Object test suite) it'd > still happen, but not in an isolated version of the call. I even added > some of the surrounding calls in an attempt to get it to fail, but > eventually gave up. > > But the *really* strange thing is that DBD::SQLite 1.13 seems to get > progressively worse as time goes on. This morning, I could run the > whole Rose::DB::Object test suite against SQLite with DBD::SQLite 1.13 > and I only got one "not an error" error. As the day progressed, with no > code changes anywhere, it started to throw some "bind or column index > out of range(25)" errors. (Yes, I deleted the SQLite database file > between runs.) I downgraded to DBD::SQLite 1.12 and the test suite > immediately ran without any errors at all. > > Sorry this is such a bad bug report. I'm still trying to isolate this, > but I just thought someone should know that 1.13 is, like, totally wonky.
I have a sneaky suspicion that it's this (rather critical) change that broke everything for everyone: http://axkit.org/cgi-bin/viewcvs.cgi/DBD-SQLite/dbdimp.c.diff?r1=1.61&r2=1.62 Let me know if you revert that one change and it starts working again.
Actually I take that back - I'm fairly sure I've now found the bug and fixed it.
Subject: [rt.cpan.org #21472] fix?!
Date: Tue, 10 Oct 2006 21:13:33 +0200
To: bug-DBD-SQLite [...] rt.cpan.org
From: gregor herrmann <gregor+debian [...] comodo.priv.at>
Download (untitled) / with headers
text/plain 484b
Hi, could you publish your fix or even better a new version of DBD-SQLite? The bug has already hit the Debian Packages (cf. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=388717 ) Thanks, gregor (Debian Perl Group) -- .''`. http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4 : :' : debian: the universal operating system - http://www.debian.org/ `. `' member of https://www.vibe.at/ | how to reply: http://got.to/quote/ `- NP: Spider Murphy Gang: Reißverschluß
Download signature.asc
application/pgp-signature 189b

Message body not shown because it is not plain text.

According to MSERGEANT, this was fixed in 1.14, so resolving this bug.


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.