3

A stable, web-based, single-threaded/process, perl application running in production started throwing this error intermittently and only under heavy system load. We can't identify the root cause.

Usage: DBD::Pg::db::DESTROY(dbh) during global destruction

Can anyone offer any explanation of this error? It appears to be thrown from Pg.sx when DESTROY is called without an argument (self?) when Perl is cleaning up before shutting down. (I see that message in older source code via google, but not in our version.) Our environment:

  • OS: FreeBSD 8.3-STABLE
  • Perl v5.14.2
  • DBD::Pg v2.19.3
  • PostgreSQL: v9.2.3
Allen
  • 718
  • 8
  • 9
  • Does your code ever call (or perhaps goto) DESTROY explicitly? By AUTOLOAD, maybe? What version of DBI? – pilcrow Feb 22 '13 at 22:36
  • @pilcrow - (Sorry, I didn't notice your comment before.) DBI v1.623. My code doesn't call DESTROY or use AUTOLOAD. The process appears to be complete and Perl is in cleanup. I have a signal handler trapping the exception and prints a little stack trace (caller()) which shows only the trap routine running, not from my code (as happens when it traps a real error). – Allen Mar 04 '13 at 16:09

2 Answers2

4

Here is a shot in the dark.

DBI database handles are usually destroyed just like any other object - when nothing references them. However, things can prevent the handle from being destroyed naturally:

  • Handle is a package global
  • Handle forms part of a cyclic reference that Perl cannot automatically free

When this happens, the object is destroyed as part of 'global destruction' which basically just undefs everything and calls DESTROY in, practically, a random order. This may be what is causing your spurious errors.

To begin with, you can try enumerating your DB handles at the start and end of your script and see if any are still in use by the end. See this code snippet:

sub show_child_handles {
    my ($h, $level) = @_;
    printf "%sh %s %s\n", $h->{Type}, "\t" x $level, $h;
    show_child_handles($_, $level + 1)
        for (grep { defined } @{$h->{ChildHandles}});
}

my %drivers = DBI->installed_drivers();
show_child_handles($_, 0) for (values %drivers);

If you're not sure why the object is still in use, you can use Devel::Cycle on some big data structures to find them.

You may also find DBI's tracing functionality useful. Export DBI_TRACE=2 before running your script and it'll log every time a handle is created or destroyed.

rjh
  • 49,276
  • 4
  • 56
  • 63
  • Thanks, a great answer, but doesn't fit my scenario AFAIK, but am still considering it. I have tried the DB trace() but it shows normal processing. This seems to happen after I commit() and exit(); I expected Perl to clean it up normally. The error implies a missing argument to DESTROY()? This has ran for years fine, then suddenly that day started spewing this message. – Allen Mar 04 '13 at 16:22
  • It should clean up after exit, but it didn't (and global destruction was done instead) which implies something is keeping a hold of the database handle. Global destruction would explain the error because it is possible for the dbh to be undefined before the destructor is called (!) As I said though, these are shots in the dark. If the code has not been changed, then perhaps either DBD::Pg was upgraded, or your database config (timeout?) has been changed? – rjh Mar 05 '13 at 10:58
3

In my case it started to happen after upgrading a server, therefore it seems to be a PostgreSql/Perl/DBD version specific error.

This error suddenly started to be thrown in all scripts where I don't explicitely destroy a database handle. Adding $dbx->disconnect() solved it.

Update: this workaround fixed the errors only in some of my scripts. In others the error persists also when explicitely destroying the database handle.

Community
  • 1
  • 1
P.Zaccaria
  • 311
  • 3
  • 9