Re: DBD::mysql::st execute warning

[prev] [thread] [next] [Date index for 2005/01/03]

cdbi@xxxxxxxxxx.xxx wrote:
> I'm trying to fix a problem that happens only after my application has
> been running for many hours, so it's hard to reproduce.  Here's what
> happens.
> 
> The application runs just fine for a long period of time, including
> calls into Class::DBI.  Many hours later, a call to Class::DBI fails and
> I see this output...
> 
> DBD::mysql::st execute warning:  at
> /home/dave/devel/slimservice/CPAN/DBIx/ContextualFetch.pm line 51.
> DBD::mysql::st fetchrow_arrayref failed: fetch() without execute() at
> /home/dave/devel/slimservice/CPAN/DBIx/ContextualFetch.pm line 69.
> Slim::DataStores::DBI::Pref can't SELECT mac, name, value
> FROM   prefs
> WHERE  name = ? AND mac = ?
> : DBD::mysql::st fetchrow_arrayref failed: fetch() without execute() at
> /home/dave/devel/slimservice/CPAN/DBIx/ContextualFetch.pm line 69.
>  at /home/dave/devel/slimservice/Slim/Utils/Prefs.pm line 623
> 
> My huntch is that during those hours of running the handle to the
> database has gone bad.  Something has to make it good again, and that
> something is not happening.  I'm new to DBI... hopefully someone out
> there can tell me just what to do.
> 
> I've added some code to ContextualFetch.pm, hoping to learn more about
> this "execute warning" mentioned in the output.  The line which seems to
> generate that message is:
> 
> 	my $ret = $sth->SUPER::execute(@_);
> 
> And $ret is undef after the call generates the warning.
> I print $sth->errstr() but it appears to be empty.
> And I print a call stack which looks like this...
> 
>    frame 0: DBIx::ContextualFetch::st::_untaint_execute
>    (/home/dave/devel/slimservice/CPAN/DBIx/ContextualFetch.pm line 31)
>    frame 1: DBIx::ContextualFetch::st::execute
>    (/home/dave/devel/slimservice/CPAN/Class/DBI.pm line 1069)
>    frame 2: (eval) (/home/dave/devel/slimservice/CPAN/Class/DBI.pm line
>    1068)
>    frame 3: Class::DBI::sth_to_objects
>    (/home/dave/devel/slimservice/CPAN/Class/DBI.pm line 1041)
>    frame 4: Class::DBI::_do_search
>    (/home/dave/devel/slimservice/CPAN/Class/DBI.pm line 1022)
>    frame 5: Class::DBI::search
>    (/home/dave/devel/slimservice/CPAN/Class/DBI.pm line 601)
>    frame 6: Class::DBI::retrieve
>    (/home/dave/devel/slimservice/Slim/Utils/Prefs.pm line 623)
> [snip]
> 
> I'm running my program again, with DBI_TRACE set to "15|SQL|mysql", but
> it could be a day or so before the problem occurs again.
> 
> Any help or suggestions are appreciated.  Thanks,

If you're using mod_perl have a look at the "morning bug" section of the
troubleshooting documentation. I've come across this recently and the
main fix is to implement a "ping" subroutine since mysql doesn't
implement one itself. Also things like caching statement handles without
using "prepare_cached" is a very bad thing.

In the main, it looks more like a DBI/DBD problem rather than a
Class::DBI one.

terra!