Subject: | HandleError subroutine sometimes called with Destroyed handle |
Date: | Sat, 11 Oct 2014 15:17:58 -0700 |
To: | bug-DBD-Sybase [...] rt.cpan.org |
From: | Skef Iterum <skef [...] skef.org> |
When using database-level select statements (such as
selectrow_arrayref), I occasionally get errors like the
following:
DBD::Sybase::st DESTROY failed: Server message number=8179 severity=16 state=2 line=1 server=XXX <http://www.perlmonks.org/?node=XXX> text=Could not find prepared statement with handle 0. at lib/LSPDB.pm line 27.
DBD::Sybase::db selectrow_hashref failed: Server message number=8179 severity=16 state=2 line=1 server=XXX <http://www.perlmonks.org/?node=XXX> text=Could not find prepared statement with handle 0. at lib/LSPDB.pm line 27.
The first message presumably comes from a statement
handle used inside the call. Unfortunately, if a HandleError
subroutine is set, it gets called both for the statement
handle and also for the database handle. If that subroutine
simply calls "die", you get an error like this:
(in cleanup) DBD::Sybase::st DESTROY failed: Server message number=8179 severity=16 state=2 line=1 server=XXX <http://www.perlmonks.org/?node=XXX> text=Could not find prepared statement with handle 0. at lib/LSPDB.pm line 27.
DBD::Sybase::db selectrow_hashref failed: Server message number=8179 severity=16 state=2 line=1 server=XXX <http://www.perlmonks.org/?node=XXX> text=Could not find prepared statement with handle 0. at lib/LSPDB.pm line 27.
But if you do something more elaborate in the HandleError
subroutine, like try to throw an exception, all hell breaks loose.
(My Throwable::Error-derived exception tends to cause perl
to freeze trying to eat all the memory on the system.)
As it happens, the handle passed into the subroutine is pretty
much destroyed already -- 'Type' is not defined as 'st', for
example. I've been working around the problem using this
check, but I think any call that passes a destroyed handle to
something expecting a good one is probably a bug.
I can't guarantee this is a DBD::Sybase problem, but I've
been using a variety of databases with DBI over time, and
I've only ever seen this with recent versions of DBD::Sybase.
Skef