Re: selectrow_hashref() propagating wrong message (bug in DBD::mysql)

--00163630ed3dce26ff048d28ab17
Content-Type: text/plain; charset=ISO-8859-1

Hello All,

I have started to see random "fetch() without execute()" messages on a
production when mysql is under heavy load. I believe the thread below
describes my problem (from dbi-dev mailing list circa 2007). The production
system is currently using an older version of DBD::mysql and I wanted to
make sure this bug was fixed before scheduling an upgrade. I looked through
changesets on github and couldn't pinpoint when it was fixed. I tried to
compare the error handling between trunk and my version and couldn't see any
major difference (forgive me, it is my first time looking through dbd::mysql
source). My question is was this fixed? And if so, what was the fix?

Thanks,

Paul

===============

HTML version of the thread =>
http://www.nntp.perl.org/group/perl.dbi.dev/2007/03/msg4881. html

===============

From:
Patrick Galbraith
Date:
March 5, 2007 13:51
Subject:
Re: selectrow_hashref() propagating wrong message (bug in DBD::mysql)
Message ID:
45EC90D1.8080502@patg.net

Tim Bunce wrote:

Randy, Tim,

Thanks for the report and suggested fix. I'll fix this issue.

Kind regards,

Patrick

>On Fri, Mar 02, 2007 at 12:52:01PM -0800, Randy Harmon wrote:
>
>
>>Using DBI 1.53 as of this morning (also happened with 1.48).
>>
>>selectrow_hashref() was reporting "fetch() without execute()" when
>>$dbh->{PrintError} is true. Since selectrow_hashref() is an opaque
>>function call, I'd expect it to report the actual error from the database.
>>
>>I suspected a database corruption problem, as this db server got hit
>>with an unexpected reboot. But I wanted to be sure. So I set
>>$dbh->{TraceLevel} = 2, and got the following output, indicating the
>>error message I suspected
>>
>>Is this an issue already known and slated for fix in an upcoming version?
>>
>>
>
>It's a bug in DBD::mysql:
>
>
>
>>-> selectrow_hashref for DBD::mysql::db (DBI::db=HASH(0x8d37b24)~0x8d28294
'select * from [...fnord...]'')
>>1 -> prepare for DBD::mysql::db (DBI::db=HASH(0x8d28294)~INNER 'select
>>* from [...fnord...]'' undef)
>>Setting mysql_use_result to 0
>>1 <- prepare= DBI::st=HASH(0x8de92f4) at DBI.pm line 1534
>> -> execute for DBD::mysql::st (DBI::st=HASH(0x8de92f4)~0x8dd5018)
>> -> dbd_st_execute for 08e0ccc0
>>Incorrect key file for table '[fnord]'; try to repair it error 1034
>>recorded: Incorrect key file for table '[fnord]'; try to repair it
>> <- dbd_st_execute -1 rows
>> !! ERROR: 1034 'Incorrect key file for table '[fnord]'; try to repair
it' (err#0)
>> <- execute= -1 at DBI.pm line 1569
>>
>>
>
>The DBD::mysql execute method should return undef on error, not -1.
>
>Tim.
>
>


--
Patrick Galbraith, Senior Programmer
Grazr - Easy feed grazing and sharing
http://www.grazr.com

Satyam Eva Jayate - Truth Alone Triumphs
Mundaka Upanishad

--00163630ed3dce26ff048d28ab17--

Re: selectrow_hashref() propagating wrong message (bug in DBD::mysql)

--0016e6441f34c120e404939ce86a
Content-Type: text/plain; charset=ISO-8859-1

I finally figured out the problem. The situation happens when an execute
has an error and row_num is -1 (unknown number of rows). There are a bunch
of ways to solve the problem, I added the following block before the last
return in dbd_st_execute in dbdimp.c:

1712a1713,1716
> /* patch added to catch case where an error has occurred and
imp_sth->row_num = -1 (unknown number of rows) */
> if (mysql_errno(&imp_dbh->mysql) && imp_sth->row_num == -1) {
> return -2;
> }

I confirmed that this bug happens in the current version of DBD::mysql too.
Please note the above diff is for my older version of the module and the
same fix will work but the line numbers in the above diff will probably be
off.

Thanks,

Paul

On Fri, Aug 6, 2010 at 10:42 AM, Paul Silevitch wrote:

> Hello All,
>
> I have started to see random "fetch() without execute()" messages on a
> production when mysql is under heavy load. I believe the thread below
> describes my problem (from dbi-dev mailing list circa 2007). The production
> system is currently using an older version of DBD::mysql and I wanted to
> make sure this bug was fixed before scheduling an upgrade. I looked through
> changesets on github and couldn't pinpoint when it was fixed. I tried to
> compare the error handling between trunk and my version and couldn't see any
> major difference (forgive me, it is my first time looking through dbd::mysql
> source). My question is was this fixed? And if so, what was the fix?
>
> Thanks,
>
> Paul
>
> ===============
>
> HTML version of the thread =>
> http://www.nntp.perl.org/group/perl.dbi.dev/2007/03/msg4881. html
>
> ===============
>
> From:
> Patrick Galbraith
> Date:
> March 5, 2007 13:51
> Subject:
> Re: selectrow_hashref() propagating wrong message (bug in DBD::mysql)
> Message ID:
> 45EC90D1.8080502@patg.net
>
> Tim Bunce wrote:
>
> Randy, Tim,
>
> Thanks for the report and suggested fix. I'll fix this issue.
>
> Kind regards,
>
> Patrick
>
> >On Fri, Mar 02, 2007 at 12:52:01PM -0800, Randy Harmon wrote:
> >
> >
> >>Using DBI 1.53 as of this morning (also happened with 1.48).
> >>
> >>selectrow_hashref() was reporting "fetch() without execute()" when
> >>$dbh->{PrintError} is true. Since selectrow_hashref() is an opaque
> >>function call, I'd expect it to report the actual error from the
> database.
> >>
> >>I suspected a database corruption problem, as this db server got hit
> >>with an unexpected reboot. But I wanted to be sure. So I set
> >>$dbh->{TraceLevel} = 2, and got the following output, indicating the
> >>error message I suspected
> >>
> >>Is this an issue already known and slated for fix in an upcoming version?
> >>
> >>
> >
> >It's a bug in DBD::mysql:
> >
> >
> >
> >>-> selectrow_hashref for DBD::mysql::db
> (DBI::db=HASH(0x8d37b24)~0x8d28294 'select * from [...fnord...]'')
> >>1 -> prepare for DBD::mysql::db (DBI::db=HASH(0x8d28294)~INNER 'select
> >>* from [...fnord...]'' undef)
> >>Setting mysql_use_result to 0
> >>1 <- prepare= DBI::st=HASH(0x8de92f4) at DBI.pm line 1534
> >> -> execute for DBD::mysql::st (DBI::st=HASH(0x8de92f4)~0x8dd5018)
> >> -> dbd_st_execute for 08e0ccc0
> >>Incorrect key file for table '[fnord]'; try to repair it error 1034
> >>recorded: Incorrect key file for table '[fnord]'; try to repair it
> >> <- dbd_st_execute -1 rows
> >> !! ERROR: 1034 'Incorrect key file for table '[fnord]'; try to repair
> it' (err#0)
> >> <- execute= -1 at DBI.pm line 1569
> >>
> >>
> >
> >The DBD::mysql execute method should return undef on error, not -1.
> >
> >Tim.
> >
> >
>
>
> --
> Patrick Galbraith, Senior Programmer
> Grazr - Easy feed grazing and sharing
> http://www.grazr.com
>
> Satyam Eva Jayate - Truth Alone Triumphs
> Mundaka Upanishad
>
>
>
>
>

--0016e6441f34c120e404939ce86a--