samtregar has asked for the wisdom of the Perl Monks concerning the following question:

Hello all. I'm trying to fix a problem in DBIx::Timeout where a warning gets printed when the timeout kills a MySQL thread. This warning isn't affected by the DBI Warn or PrintWarn attributes. It looks like:

   DBD::mysql::db selectcol_arrayref failed: Unknown error at ...

I can catch it with $SIG{__WARN__} but I'm having a hard time figuring out where it's coming from. I tried sticking a call to Devel::StackTrace in a $SIG{__WARN__} handler, but that didn't show me a source. I also tried greping DBD::mysql and DBI for the warning text, without luck.

Any ideas about how I can find the source of this warning?

UPDATE: I found the source of the warning. The DBI PrintError attribute was set on, and amazingly can't be turned off after connect(). Trying to set this attribute to 0 turns it on as surely as 1. Remind me again why DBI had to reimplement hashes?

UPDATE 2: Ok, it seems you can turn PrintError off, but connect_cached() will turn it back on. Stills seems wrong, but less wrong than not being able to turn it off at all.

-sam

Replies are listed 'Best First'.
Re: Tracing a warning
by bart (Canon) on Sep 18, 2006 at 18:13 UTC
    There's a stacktracing version of warn in Carp: cluck. You can enable it (globally, and temporarily) by using:
    use Carp; local $SIG{__WARN__} = \&Carp::cluck;
Re: Tracing a warning
by Ovid (Cardinal) on Sep 18, 2006 at 18:14 UTC

    It doesn't always help, but Devel-Trace can often work wonders:

        perl -d:Trace someprogram.pl

    Basically, you want to redirect the output somewhere because that prints out every line executed before it gets executed. Even small programs often have much more stuff going on behind the scenes than folks realize.

    Cheers,
    Ovid

    New address of my CGI Course.

Re: Tracing a warning
by Anonymous Monk on Sep 19, 2006 at 07:16 UTC