On Sat, Sep 04, 2010 at 08:55:43AM -0700, Jerry Kaidor wrote:
> > There may be relevant lines above or below the ones you've quoted.
> > Please post them as well.
> >
> > Enabling tracing (see DBI docs) would help identify what's happening
> > when this message (from sv_dump) is produced.
>
> *** The error lines I posted are all there is. There is nothing before
> them or after them.
Odd.
The sv_dump output is that of a DBI handle that has no magic attached.
> I have tried to bracket the problem in time by producing my own error
> that I use as a "mark" in the apache error log. No matter where I put
> my "mark" error, it occurs BEFORE the problem. So the problem is
> occurring after my application finishes ALL its DBI work, and all that
> remains is to spit out the HTML.
It's possibly a problem with unordered global destruction of objects.
> So I suspected some kind of "shutdown" problem. I added code to call
> disconnect() for every single dbh in the system. No difference :(.
If you're using Apache::DBI somewhere then disconnect() is probably
disabled.
Looking at the DBI.xs source, the only sv_dump() calls that are enabled
when not tracing are those that relate to invalid handles. All of those
are followed by croak()'s. So perhaps there's no other info in the log
because you're catching and discarding the exception.
If so, this may help: $SIG{__DIE__} = sub { warn @_ };
but showing you all the exceptions being thrown. It might be noisy.
It might also not work if something else messes with $SIG{__DIE__}.
> I will enable tracing later today and report the results.
Neither of the two files you sent contain the sv_dump output you're
concerned about. So I can't determine where it's coming from.
Tim.
