After running some DProf exec graphs I see the following as the reason for
dying (which now seems to be very DBD::Oracle-centric and perhaps a
possible bug):
GLGC::Mod1::DBScan::new # Create top-level object
RA::Root::new
GxRte::new
GLGC::Mod1::new
RA::Root::new
GLGC::Mod1::getDBH
DBI::connect
DBI::install_driver
DBI::dr::connect
DBD::Oracle::dr::connect
DBD::Oracle::ORA_OCI
DBI::_new_dbh
DBI::_handles
DBI::_new_handle
DBI::st::TIEHASH
DBI::_setup_handle
DBD::Oracle::db::_login # First call to Oracle login
works fine
DBI::db::STORE
DBI::db::STORE
GLGC::Mod1::DBScan::DataSet::new # Create sub-object, also HAS-A
GLGC::Mod1 object
RA::Root::new
GxRte::new
GLGC::Mod1::new
RA::Root::new
GLGC::Mod1::getDBH # GLGC::Mod1's db initalization routine, which
worked fine above
DBI::connect
DBI::install_driver
DBI::dr::connect
DBD::Oracle::dr::connect
DBD::Oracle::ORA_OCI
DBI::_new_dbh
DBI::_handles
DBI::_new_handle
DBI::st::TIEHASH
DBI::_setup_handle
DBD::Oracle::db::_login # But for some reason dies
here, same init string as above
DBI::dr::errstr
Carp::carp
Carp::shortmess # Error occurs here, can't find
Carp/Heavy.pm
[ all modules then run DESTROY routines ...]
Checking the source for DBD::Oracle it looks like the _login routine is in
the XS module, which I have not yet hunted down to read. Does anyone
(TimB?) have any idea why some sort of login failure would result in a
state in which the system could not find Carp/Heavy.pm but in which @INC
looks to be completely intact (see first post below)?
Alternatively, why would db::_login fail in the third iteration of a series
of double GLGC::Mod1 module creations and destructions when it worked just
fine in the first two iterations? I've even tried to specifcally undef the
instances rather than just letting them go out of scope to no avail. Nor
does explicitly disconnecting the DBH reference within the GLGC::Mod1
instance before undef'ing the instance seem to help.
Has anyone seen anything like this before?
- j
-------------------------------------------------
James Diggans
Bioinformatics Programmer
Gene Logic, Inc.
Phone: 301.987.1756
FAX: 301.987.1701
jdiggans@genel
ogic.com To: [EMAIL PROTECTED]
cc:
10/22/01 05:12 Subject: Can't find Carp/Heavy.pm ...
PM
What's Carp have to do w/ the DBI, you ask? Well, I have a script that
iterates over a series of activities, creating an instance of a different
module per activity. Each of these sub-modules makes use of the DBI and
DBD::Oracle.
No matter in which order the activities are executed the THIRD iteration
always fails out (eliminating, IMHO, syntax error as a source) with:
Root::Module1::SubModule1::Module1c debugging on
Root::Module1 - No existing connection, connecting to database ...
Can't locate Carp/Heavy.pm in @INC (@INC contains:
/home/jdiggans/pubSun /home/jdiggans/pub
/usr/local/lib/perl5/5.6.0/sun4-solaris /usr/local/lib/perl5/5.6.0
/usr/local/lib/perl5/site_perl/5.6.0/sun4-solaris
/usr/local/lib/perl5/site_perl/5.6.0 /usr/local/lib/perl5/site_perl .)
at /usr/local/lib/perl5/5.6.0/Carp.pm line 109.
Now clearly /usr/local/lib/perl5/5.6.0/Carp/Heavy.pm exists and is
world-readable, since it works for the first two iterations as well as
every other script running on this system. I've tracked this problem to
DBI.pm since the line indicated by the error is in Carp.pm's shortmess()
routine, called only by its carp() and croak() methods. I use only confess
() in my modules, but croak() and carp() are used extensively in DBI.pm
though since Carp is dying I have no way to officially track it to a line#
in DBI.
My question, then, is has anyone ever seen something like this? The
sub-objects should be going out of scope with each interation so extra db
connections certainly still shouldn't be laying around ... and why always
on the third iteration? Any ideas/help/things to do to get more
information/etc are greatly appreciated.
Regards,
-j
-------------------------------------------------
James Diggans
Bioinformatics Programmer
Gene Logic, Inc.
Phone: 301.987.1756
FAX: 301.987.1701
