Debugging question: tracing the origin of an error.
in [Perl]
|
From: Ted Byers on 19 May 2010 20:40 On May 19, 5:46 pm, Ted Byers <r.ted.by...(a)gmail.com> wrote: > On May 13, 5:56 pm, "C.DeRykus" <dery...(a)gmail.com> wrote: > > > > > On May 13, 11:56 am, Ted Byers <r.ted.by...(a)gmail.com> wrote: > > > > On May 13, 2:03 pm, "C.DeRykus" <dery...(a)gmail.com> wrote: > > > > > On May 13, 10:10 am, Ted Byers <r.ted.by...(a)gmail.com> wrote: > > > > > > I have done all the usual things (as specified in the FAQ), and more, > > > > > but it isn't enough. > > > > > > Here is how my script starts: > > > > > > use strict; > > > > > use warnings; > > > > > use DBI; > > > > > use DateTime::Format::MySQL; > > > > > use Date::Manip; > > > > > use DateTime::Format::DateManip; > > > > > > BEGIN { > > > > > $SIG{__WARN__} = sub{ print STDERR "Perl: ", @_; }; > > > > > $SIG{__DIE__} = sub{ print STDERR "Perl: ", @_; exit 1}; > > > > > > } > > > > > > $| = 1; > > > > > > In the body of the script, this script does very little except make a > > > > > DB connection, place the values from the record set that results from > > > > > a trivial select query into a variable, and then prints it. Then all > > > > > handles are closed and the progrma ends. The error actually arises > > > > > after the last statement (and does not appear in ANY of my other > > > > > scripts that use the packes listed above). > > > > > > Here is the error statement I get: > > > > > > Perl: Can't call method "FETCH" on an undefined value at C:/Perl/site/ > > > > > lib/Win32/TieRegistry.pm line 1485, <DATA> line 335 during global > > > > > destruction. > > > > > > At no time have I made direct use of the file mentioned, so it must be > > > > > something one of the above packages has done. However, there is no > > > > > information provided as to what happened that led to this error. It > > > > > does not even say what object is being destructed or what package > > > > > created, or failed to create, it. > > > > > > How can I modify the signal handling I set up above so that I can get > > > > > this information? > > > > > Here's an purported cure: > > > > > END { $^W = 0; } > > > > Alas, the purported cure "END { $^W = 0; }" doesn't work in this > > > instance (unless I used it incorrectly). In any event, do you know > > > how that purported cure is supposed to work? > > > I thought I recalled seeing the error/cure once before. > > But, here's a thread that suggests just wrapping the > > disconnect. Their error output is virtually the same: > > > { $^W = 0; $dbh->disconnect } > > > perl case.pl > > DBI::db=HASH(0x8f68e40) trace level set to 9 in > > ... > > <- DESTROY= undef at unknown location! > > (in cleanup) Can't call method "FETCH" on an > > undefined value at > > C:/opt/perl/site/lib/Win32/TieRegistry.pm > > line 1486 during global destruction. > > > > I am using ActiveSate's perl (v5.10.0) on Windows, and have examined > > > each of the tools I thought might have something useful, but either > > > they didn't have something that would answer my question or I didn't > > > understand the documentation. > > > > Almost a decade ago, I wrote a C++ template class that I used to wrap > > > all exception classes and, using RTTI, I made exceptions traceable, > > > including not only the line and file of the source code where the > > > exception arose but also the class affected and all functions applied > > > to it from the time an instance of the class was created to the time > > > the exception was produced; and this in addition to a simple call > > > stack. This proved priceless in debugging my own code (and > > > identifying cases where I was hit by a bug in one or another of the > > > libraries I used, so I could focus on finding a work-around rather > > > than seeking a bug that didn't exist in my code). But, it was useful > > > only when I could compile it into my code which normally meant my own > > > code only. Alas, it relied on compiler specific macros in addition to > > > a couple of my own, and the language has changed since I did that. > > > > Anyway, in addition to making this specific error go away, what I > > > really need is something I can include at the top of my script and > > > have it produce info about any object the script makes (whether > > > explicitly or indirectly as part of the internals of a package that > > > had been included), and what happens to it, but prints this info only > > > if that object is involved in an error: basically a perl equivalent of > > > the traceable exceptions I'd made in C++ so very long ago. > > > ... > > > If this new cure doesn't work, you might try one of DBI's > > higher trace settings too as they demo in the thread. > > > -- > > Charles DeRykus > > OK, Combining Steve's suggestion (with teh suggested ammendment > regarding '&;), with yours, at trace level 10, I get the following > output AFTER all my source code has been executed correctly: > > >> DESTROY DISPATCH (DBI::st=HASH(0x242e39c) rc1/1 @1 g0 > ima10004 pid#18652) > <> DESTROY(DBI::st=HASH(0x242e39c)) ignored for outer handle > (inner DBI::st=HASH(0x2e48dcc) has ref cnt 1) > >> DESTROY DISPATCH (DBI::st=HASH(0x2e48dcc) rc1/1 @1 g0 > ima10004 pid#18652) > -> DESTROY for DBD::mysql::st (DBI::st=HASH(0x2e48dcc)~INNER) > thr#3424c > <- DESTROY= undef > DESTROY (dbih_clearcom) (sth 0x2e48dcc, com 0x24459b4, imp > DBD::mysql::st): > FLAGS 0x180191: COMSET Warn RaiseError PrintError PrintWarn > PARENT DBI::db=HASH(0x242e7ec) > KIDS 0 (0 Active) > NUM_OF_FIELDS 5 > NUM_OF_PARAMS 0 > dbih_clearcom 0x2e48dcc (com 0x24459b4, type 3) done. > > >> DESTROY DISPATCH (DBI::db=HASH(0x242e6ac) rc1/1 @1 g0 > ima10004 pid#18652) > <> DESTROY(DBI::db=HASH(0x242e6ac)) ignored for outer handle > (inner DBI::db=HASH(0x242e7ec) has ref cnt 1) > >> DESTROY DISPATCH (DBI::db=HASH(0x242e7ec) rc1/1 @1 g0 > ima10004 pid#18652) > -> DESTROY for DBD::mysql::db (DBI::db=HASH(0x242e7ec)~INNER) > thr#3424c > imp_dbh->pmysql: 242864c > <- DESTROY= undef > DESTROY (dbih_clearcom) (dbh 0x242e7ec, com 0x245a44c, imp > DBD::mysql::db): > FLAGS 0x180391: COMSET Warn RaiseError PrintError PrintWarn > AutoCommit > PARENT DBI::dr=HASH(0x242ec9c) > KIDS 0 (0 Active) > IMP_DATA HASH(0x242e78c) > dbih_clearcom 0x242e7ec (com 0x245a44c, type 2) done. > > -- DBI::END ($@: , $!: ) > >> disconnect_all DISPATCH (DBI::dr=HASH(0x24066d4) rc1/3 @1 g0 > ima801 pid#18652) at C:/Perl/site/lib/DBI.pm line 731 via at k:/ > Projects/NewRiskModel/Simple.Risk.Model.pl line 0 > -> disconnect_all for DBD::mysql::dr > (DBI::dr=HASH(0x24066d4)~0x242ec9c) thr#3424c > <- disconnect_all= (not implemented) at C:/Perl/site/lib/DBI.pm > line 731 via at k:/Projects/NewRiskModel/Simple.Risk.Model.pl line 0 > ! >> DESTROY DISPATCH (DBI::dr=HASH(0x24066d4) rc1/1 @1 g0 > ima10004 pid#18652) during global destruction > ! <> DESTROY(DBI::dr=HASH(0x24066d4)) ignored for outer handle > (inner DBI::dr=HASH(0x242ec9c) has ref cnt 1) > ! >> DESTROY DISPATCH (DBI::dr=HASH(0x242ec9c) rc1/1 @1 g0 > ima10004 pid#18652) during global destruction > ! -> DESTROY in DBD::_::common for DBD::mysql::dr > (DBI::dr=HASH(0x242ec9c)~INNER) thr#3424c > ! <- DESTROY= undef during global destruction > DESTROY (dbih_clearcom) (drh 0x242ec9c, com 0x23f95d4, imp global > destruction): > FLAGS 0x100215: COMSET Active Warn PrintWarn AutoCommit > PARENT undef > KIDS 0 (0 Active) > dbih_clearcom 0x242ec9c (com 0x23f95d4, type 1) done. > > Trace: > k:/Projects/NewRiskModel/Simple.Risk.Model.pl, (eval), k:/Projects/ > NewRiskModel/Simple.Risk.Model.pl, Win32::TieRegistry::DESTROY, C:/ > Perl/site/lib/Win32/TieRegistry.pm, Line: 1485 > (eval), C:/Perl/site/lib/Win32/TieRegistry.pm, Line: 1485 > > Can't call method "FETCH" on an undefined value at C:/Perl/site/lib/ > Win32/TieRegistry.pm line 1485, <DATA> line 335 during global > destruction. > > Compilation finished at Wed May 19 16:41:23 > > Correct me if I am wrong, it looks like DBI is disconnecting/ > destroying children recursively up through their parents, until > everything is destroyed, and then the error happens. It still isn't > clear what object it is trying to call fetch on. I will continue > trying with still higher trace levels, but I am baffled why this hits > here but not in my other scripts that use DBI. It doesn't seem to > matter if I call $dbh->disconnect(), though my inclination is to call > it once I have all the data I need to process. > > Any other ideas about why this happens and how best to address it? > > Thanks > > Ted Just an update, the trae output does not change even if I go up to the highest trace level.
From: Ted Byers on 19 May 2010 20:40 On May 19, 5:46 pm, Ted Byers <r.ted.by...(a)gmail.com> wrote: > On May 13, 5:56 pm, "C.DeRykus" <dery...(a)gmail.com> wrote: > > > > > On May 13, 11:56 am, Ted Byers <r.ted.by...(a)gmail.com> wrote: > > > > On May 13, 2:03 pm, "C.DeRykus" <dery...(a)gmail.com> wrote: > > > > > On May 13, 10:10 am, Ted Byers <r.ted.by...(a)gmail.com> wrote: > > > > > > I have done all the usual things (as specified in the FAQ), and more, > > > > > but it isn't enough. > > > > > > Here is how my script starts: > > > > > > use strict; > > > > > use warnings; > > > > > use DBI; > > > > > use DateTime::Format::MySQL; > > > > > use Date::Manip; > > > > > use DateTime::Format::DateManip; > > > > > > BEGIN { > > > > > $SIG{__WARN__} = sub{ print STDERR "Perl: ", @_; }; > > > > > $SIG{__DIE__} = sub{ print STDERR "Perl: ", @_; exit 1}; > > > > > > } > > > > > > $| = 1; > > > > > > In the body of the script, this script does very little except make a > > > > > DB connection, place the values from the record set that results from > > > > > a trivial select query into a variable, and then prints it. Then all > > > > > handles are closed and the progrma ends. The error actually arises > > > > > after the last statement (and does not appear in ANY of my other > > > > > scripts that use the packes listed above). > > > > > > Here is the error statement I get: > > > > > > Perl: Can't call method "FETCH" on an undefined value at C:/Perl/site/ > > > > > lib/Win32/TieRegistry.pm line 1485, <DATA> line 335 during global > > > > > destruction. > > > > > > At no time have I made direct use of the file mentioned, so it must be > > > > > something one of the above packages has done. However, there is no > > > > > information provided as to what happened that led to this error. It > > > > > does not even say what object is being destructed or what package > > > > > created, or failed to create, it. > > > > > > How can I modify the signal handling I set up above so that I can get > > > > > this information? > > > > > Here's an purported cure: > > > > > END { $^W = 0; } > > > > Alas, the purported cure "END { $^W = 0; }" doesn't work in this > > > instance (unless I used it incorrectly). In any event, do you know > > > how that purported cure is supposed to work? > > > I thought I recalled seeing the error/cure once before. > > But, here's a thread that suggests just wrapping the > > disconnect. Their error output is virtually the same: > > > { $^W = 0; $dbh->disconnect } > > > perl case.pl > > DBI::db=HASH(0x8f68e40) trace level set to 9 in > > ... > > <- DESTROY= undef at unknown location! > > (in cleanup) Can't call method "FETCH" on an > > undefined value at > > C:/opt/perl/site/lib/Win32/TieRegistry.pm > > line 1486 during global destruction. > > > > I am using ActiveSate's perl (v5.10.0) on Windows, and have examined > > > each of the tools I thought might have something useful, but either > > > they didn't have something that would answer my question or I didn't > > > understand the documentation. > > > > Almost a decade ago, I wrote a C++ template class that I used to wrap > > > all exception classes and, using RTTI, I made exceptions traceable, > > > including not only the line and file of the source code where the > > > exception arose but also the class affected and all functions applied > > > to it from the time an instance of the class was created to the time > > > the exception was produced; and this in addition to a simple call > > > stack. This proved priceless in debugging my own code (and > > > identifying cases where I was hit by a bug in one or another of the > > > libraries I used, so I could focus on finding a work-around rather > > > than seeking a bug that didn't exist in my code). But, it was useful > > > only when I could compile it into my code which normally meant my own > > > code only. Alas, it relied on compiler specific macros in addition to > > > a couple of my own, and the language has changed since I did that. > > > > Anyway, in addition to making this specific error go away, what I > > > really need is something I can include at the top of my script and > > > have it produce info about any object the script makes (whether > > > explicitly or indirectly as part of the internals of a package that > > > had been included), and what happens to it, but prints this info only > > > if that object is involved in an error: basically a perl equivalent of > > > the traceable exceptions I'd made in C++ so very long ago. > > > ... > > > If this new cure doesn't work, you might try one of DBI's > > higher trace settings too as they demo in the thread. > > > -- > > Charles DeRykus > > OK, Combining Steve's suggestion (with teh suggested ammendment > regarding '&;), with yours, at trace level 10, I get the following > output AFTER all my source code has been executed correctly: > > >> DESTROY DISPATCH (DBI::st=HASH(0x242e39c) rc1/1 @1 g0 > ima10004 pid#18652) > <> DESTROY(DBI::st=HASH(0x242e39c)) ignored for outer handle > (inner DBI::st=HASH(0x2e48dcc) has ref cnt 1) > >> DESTROY DISPATCH (DBI::st=HASH(0x2e48dcc) rc1/1 @1 g0 > ima10004 pid#18652) > -> DESTROY for DBD::mysql::st (DBI::st=HASH(0x2e48dcc)~INNER) > thr#3424c > <- DESTROY= undef > DESTROY (dbih_clearcom) (sth 0x2e48dcc, com 0x24459b4, imp > DBD::mysql::st): > FLAGS 0x180191: COMSET Warn RaiseError PrintError PrintWarn > PARENT DBI::db=HASH(0x242e7ec) > KIDS 0 (0 Active) > NUM_OF_FIELDS 5 > NUM_OF_PARAMS 0 > dbih_clearcom 0x2e48dcc (com 0x24459b4, type 3) done. > > >> DESTROY DISPATCH (DBI::db=HASH(0x242e6ac) rc1/1 @1 g0 > ima10004 pid#18652) > <> DESTROY(DBI::db=HASH(0x242e6ac)) ignored for outer handle > (inner DBI::db=HASH(0x242e7ec) has ref cnt 1) > >> DESTROY DISPATCH (DBI::db=HASH(0x242e7ec) rc1/1 @1 g0 > ima10004 pid#18652) > -> DESTROY for DBD::mysql::db (DBI::db=HASH(0x242e7ec)~INNER) > thr#3424c > imp_dbh->pmysql: 242864c > <- DESTROY= undef > DESTROY (dbih_clearcom) (dbh 0x242e7ec, com 0x245a44c, imp > DBD::mysql::db): > FLAGS 0x180391: COMSET Warn RaiseError PrintError PrintWarn > AutoCommit > PARENT DBI::dr=HASH(0x242ec9c) > KIDS 0 (0 Active) > IMP_DATA HASH(0x242e78c) > dbih_clearcom 0x242e7ec (com 0x245a44c, type 2) done. > > -- DBI::END ($@: , $!: ) > >> disconnect_all DISPATCH (DBI::dr=HASH(0x24066d4) rc1/3 @1 g0 > ima801 pid#18652) at C:/Perl/site/lib/DBI.pm line 731 via at k:/ > Projects/NewRiskModel/Simple.Risk.Model.pl line 0 > -> disconnect_all for DBD::mysql::dr > (DBI::dr=HASH(0x24066d4)~0x242ec9c) thr#3424c > <- disconnect_all= (not implemented) at C:/Perl/site/lib/DBI.pm > line 731 via at k:/Projects/NewRiskModel/Simple.Risk.Model.pl line 0 > ! >> DESTROY DISPATCH (DBI::dr=HASH(0x24066d4) rc1/1 @1 g0 > ima10004 pid#18652) during global destruction > ! <> DESTROY(DBI::dr=HASH(0x24066d4)) ignored for outer handle > (inner DBI::dr=HASH(0x242ec9c) has ref cnt 1) > ! >> DESTROY DISPATCH (DBI::dr=HASH(0x242ec9c) rc1/1 @1 g0 > ima10004 pid#18652) during global destruction > ! -> DESTROY in DBD::_::common for DBD::mysql::dr > (DBI::dr=HASH(0x242ec9c)~INNER) thr#3424c > ! <- DESTROY= undef during global destruction > DESTROY (dbih_clearcom) (drh 0x242ec9c, com 0x23f95d4, imp global > destruction): > FLAGS 0x100215: COMSET Active Warn PrintWarn AutoCommit > PARENT undef > KIDS 0 (0 Active) > dbih_clearcom 0x242ec9c (com 0x23f95d4, type 1) done. > > Trace: > k:/Projects/NewRiskModel/Simple.Risk.Model.pl, (eval), k:/Projects/ > NewRiskModel/Simple.Risk.Model.pl, Win32::TieRegistry::DESTROY, C:/ > Perl/site/lib/Win32/TieRegistry.pm, Line: 1485 > (eval), C:/Perl/site/lib/Win32/TieRegistry.pm, Line: 1485 > > Can't call method "FETCH" on an undefined value at C:/Perl/site/lib/ > Win32/TieRegistry.pm line 1485, <DATA> line 335 during global > destruction. > > Compilation finished at Wed May 19 16:41:23 > > Correct me if I am wrong, it looks like DBI is disconnecting/ > destroying children recursively up through their parents, until > everything is destroyed, and then the error happens. It still isn't > clear what object it is trying to call fetch on. I will continue > trying with still higher trace levels, but I am baffled why this hits > here but not in my other scripts that use DBI. It doesn't seem to > matter if I call $dbh->disconnect(), though my inclination is to call > it once I have all the data I need to process. > > Any other ideas about why this happens and how best to address it? > > Thanks > > Ted Just an update, the trae output does not change even if I go up to the highest trace level.
From: Ted Byers on 19 May 2010 21:05 On May 19, 6:54 pm, Ben Morrow <b...(a)morrow.me.uk> wrote: > Quoth Ted Byers <r.ted.by...(a)gmail.com>: > > > > > Trace: > > k:/Projects/NewRiskModel/Simple.Risk.Model.pl, (eval), k:/Projects/ > > NewRiskModel/Simple.Risk.Model.pl, Win32::TieRegistry::DESTROY, C:/ > > Perl/site/lib/Win32/TieRegistry.pm, Line: 1485 > > (eval), C:/Perl/site/lib/Win32/TieRegistry.pm, Line: 1485 > > > Can't call method "FETCH" on an undefined value at C:/Perl/site/lib/ > > Win32/TieRegistry.pm line 1485, <DATA> line 335 during global > > destruction. > > > Compilation finished at Wed May 19 16:41:23 > > Am I correct that line 1485 of your copy of Win32/TieRegistry.pm is the > last line here? > > sub DESTROY > { > my $self= shift(@_); > return if tied(%$self); > my $unload; > eval { $unload= $self->{UNLOADME}; 1 } > > If so I can't see how that could be calling tie magic, since the code's > just checked that it *isn't* tied. In any case, back up your copy of > Win32/TieRegistry.pm and add > > use Devel::Peek (); > use Carp (); > Devel::Peek::Dump($self); > Carp::confess("huh?"); > > just before that line, and post the result. > > Ben Thanks Ben, I hadn't noticed that, but I was out of my depth as I have never used the tie magic, and didn't know which of the packages I used would or why. In any event, here is the output after adding the four lines you suggest: >> disconnect DISPATCH (DBI::db=HASH(0x244bc3c) rc1/1 @1 g0 ima10c01 pid#29840) at k:/Projects/NewRiskModel/Simple.Risk.Model.pl line 228 -> disconnect for DBD::mysql::db (DBI::db=HASH(0x244bc3c)~0x244bd7c) thr#3424c imp_dbh->pmysql: 244f314 <- disconnect= 1 at k:/Projects/NewRiskModel/Simple.Risk.Model.pl line 228 >> DESTROY DISPATCH (DBI::st=HASH(0x244b92c) rc1/1 @1 g0 ima10004 pid#29840) <> DESTROY(DBI::st=HASH(0x244b92c)) ignored for outer handle (inner DBI::st=HASH(0x2e95e3c) has ref cnt 1) >> DESTROY DISPATCH (DBI::st=HASH(0x2e95e3c) rc1/1 @1 g0 ima10004 pid#29840) -> DESTROY for DBD::mysql::st (DBI::st=HASH(0x2e95e3c)~INNER) thr#3424c <- DESTROY= undef DESTROY (dbih_clearcom) (sth 0x2e95e3c, com 0x2476014, imp DBD::mysql::st): FLAGS 0x180191: COMSET Warn RaiseError PrintError PrintWarn PARENT DBI::db=HASH(0x244bd7c) KIDS 0 (0 Active) NUM_OF_FIELDS 5 NUM_OF_PARAMS 0 dbih_clearcom 0x2e95e3c (com 0x2476014, type 3) done. >> DESTROY DISPATCH (DBI::db=HASH(0x244bc3c) rc1/1 @1 g0 ima10004 pid#29840) <> DESTROY(DBI::db=HASH(0x244bc3c)) ignored for outer handle (inner DBI::db=HASH(0x244bd7c) has ref cnt 1) >> DESTROY DISPATCH (DBI::db=HASH(0x244bd7c) rc1/1 @1 g0 ima10004 pid#29840) -> DESTROY for DBD::mysql::db (DBI::db=HASH(0x244bd7c)~INNER) thr#3424c <- DESTROY= undef DESTROY (dbih_clearcom) (dbh 0x244bd7c, com 0x247e3b4, imp DBD::mysql::db): FLAGS 0x180391: COMSET Warn RaiseError PrintError PrintWarn AutoCommit PARENT DBI::dr=HASH(0x245a424) KIDS 0 (0 Active) IMP_DATA HASH(0x244bd1c) dbih_clearcom 0x244bd7c (com 0x247e3b4, type 2) done. -- DBI::END ($@: , $!: ) >> disconnect_all DISPATCH (DBI::dr=HASH(0x2428bdc) rc1/3 @1 g0 ima801 pid#29840) at C:/Perl/site/lib/DBI.pm line 731 via at k:/ Projects/NewRiskModel/Simple.Risk.Model.pl line 0 -> disconnect_all for DBD::mysql::dr (DBI::dr=HASH(0x2428bdc)~0x245a424) thr#3424c <- disconnect_all= (not implemented) at C:/Perl/site/lib/DBI.pm line 731 via at k:/Projects/NewRiskModel/Simple.Risk.Model.pl line 0 ! >> DESTROY DISPATCH (DBI::dr=HASH(0x2428bdc) rc1/1 @1 g0 ima10004 pid#29840) during global destruction ! <> DESTROY(DBI::dr=HASH(0x2428bdc)) ignored for outer handle (inner DBI::dr=HASH(0x245a424) has ref cnt 1) ! >> DESTROY DISPATCH (DBI::dr=HASH(0x245a424) rc1/1 @1 g0 ima10004 pid#29840) during global destruction ! -> DESTROY in DBD::_::common for DBD::mysql::dr (DBI::dr=HASH(0x245a424)~INNER) thr#3424c ! <- DESTROY= undef during global destruction DESTROY (dbih_clearcom) (drh 0x245a424, com 0x1836ffc, imp global destruction): FLAGS 0x100215: COMSET Active Warn PrintWarn AutoCommit PARENT undef KIDS 0 (0 Active) dbih_clearcom 0x245a424 (com 0x1836ffc, type 1) done. SV = RV(0x22c15b0) at 0x22c15a4 REFCNT = 1 FLAGS = (PADMY,ROK) RV = 0x1c53074 SV = PVHV(0x1e45c4c) at 0x1c53074 REFCNT = 2 FLAGS = (OBJECT,SHAREKEYS) STASH = 0x1f5b01c "Win32::TieRegistry" ARRAY = 0x222f58c (0:14, 1:14, 2:4) hash quality = 121.5% KEYS = 22 FILL = 18 MAX = 31 RITER = -1 EITER = 0x0 Elt "CntValues" HASH = 0x359bb702 SV = IV(0x230a7b0) at 0x230a7b4 REFCNT = 1 FLAGS = (IOK,pIOK) IV = 0 Elt "MaxSubClassLen" HASH = 0xb3d551a2 SV = IV(0x230a860) at 0x230a864 REFCNT = 1 FLAGS = (IOK,pIOK) IV = 0 Elt "FLAGS" HASH = 0x1773e623 SV = IV(0x230a9c0) at 0x230a9c4 REFCNT = 1 FLAGS = (IOK,pIOK) IV = 136 Trace: k:/Projects/NewRiskModel/Simple.Risk.Model.pl, (eval), k:/Projects/ NewRiskModel/Simple.Risk.Model.pl, Win32::TieRegistry::DESTROY, C:/ Perl/site/lib/Win32/TieRegistry.pm, Line: 1488 Carp::confess, C:/Perl/lib/Carp.pm, Line: 45 huh? at C:/Perl/site/lib/Win32/TieRegistry.pm line 1488 Win32::TieRegistry::DESTROY('Win32::TieRegistry=HASH(0x1c53074)') called at k:/Projects/NewRiskModel/Simple.Risk.Model.pl line 0 eval {...} called at k:/Projects/NewRiskModel/Simple.Risk.Model.pl line 0 Compilation finished at Wed May 19 20:59:57 Adding your four lines seems to have added the lines beginning with SV = RV(0x22c15b0) at 0x22c15a4, but none of that info means anything to me. Any light that can be shed on this would be appreciated. Thanks Ted
From: Ted Byers on 19 May 2010 21:05 On May 19, 6:54 pm, Ben Morrow <b...(a)morrow.me.uk> wrote: > Quoth Ted Byers <r.ted.by...(a)gmail.com>: > > > > > Trace: > > k:/Projects/NewRiskModel/Simple.Risk.Model.pl, (eval), k:/Projects/ > > NewRiskModel/Simple.Risk.Model.pl, Win32::TieRegistry::DESTROY, C:/ > > Perl/site/lib/Win32/TieRegistry.pm, Line: 1485 > > (eval), C:/Perl/site/lib/Win32/TieRegistry.pm, Line: 1485 > > > Can't call method "FETCH" on an undefined value at C:/Perl/site/lib/ > > Win32/TieRegistry.pm line 1485, <DATA> line 335 during global > > destruction. > > > Compilation finished at Wed May 19 16:41:23 > > Am I correct that line 1485 of your copy of Win32/TieRegistry.pm is the > last line here? > > sub DESTROY > { > my $self= shift(@_); > return if tied(%$self); > my $unload; > eval { $unload= $self->{UNLOADME}; 1 } > > If so I can't see how that could be calling tie magic, since the code's > just checked that it *isn't* tied. In any case, back up your copy of > Win32/TieRegistry.pm and add > > use Devel::Peek (); > use Carp (); > Devel::Peek::Dump($self); > Carp::confess("huh?"); > > just before that line, and post the result. > > Ben Thanks Ben, I hadn't noticed that, but I was out of my depth as I have never used the tie magic, and didn't know which of the packages I used would or why. In any event, here is the output after adding the four lines you suggest: >> disconnect DISPATCH (DBI::db=HASH(0x244bc3c) rc1/1 @1 g0 ima10c01 pid#29840) at k:/Projects/NewRiskModel/Simple.Risk.Model.pl line 228 -> disconnect for DBD::mysql::db (DBI::db=HASH(0x244bc3c)~0x244bd7c) thr#3424c imp_dbh->pmysql: 244f314 <- disconnect= 1 at k:/Projects/NewRiskModel/Simple.Risk.Model.pl line 228 >> DESTROY DISPATCH (DBI::st=HASH(0x244b92c) rc1/1 @1 g0 ima10004 pid#29840) <> DESTROY(DBI::st=HASH(0x244b92c)) ignored for outer handle (inner DBI::st=HASH(0x2e95e3c) has ref cnt 1) >> DESTROY DISPATCH (DBI::st=HASH(0x2e95e3c) rc1/1 @1 g0 ima10004 pid#29840) -> DESTROY for DBD::mysql::st (DBI::st=HASH(0x2e95e3c)~INNER) thr#3424c <- DESTROY= undef DESTROY (dbih_clearcom) (sth 0x2e95e3c, com 0x2476014, imp DBD::mysql::st): FLAGS 0x180191: COMSET Warn RaiseError PrintError PrintWarn PARENT DBI::db=HASH(0x244bd7c) KIDS 0 (0 Active) NUM_OF_FIELDS 5 NUM_OF_PARAMS 0 dbih_clearcom 0x2e95e3c (com 0x2476014, type 3) done. >> DESTROY DISPATCH (DBI::db=HASH(0x244bc3c) rc1/1 @1 g0 ima10004 pid#29840) <> DESTROY(DBI::db=HASH(0x244bc3c)) ignored for outer handle (inner DBI::db=HASH(0x244bd7c) has ref cnt 1) >> DESTROY DISPATCH (DBI::db=HASH(0x244bd7c) rc1/1 @1 g0 ima10004 pid#29840) -> DESTROY for DBD::mysql::db (DBI::db=HASH(0x244bd7c)~INNER) thr#3424c <- DESTROY= undef DESTROY (dbih_clearcom) (dbh 0x244bd7c, com 0x247e3b4, imp DBD::mysql::db): FLAGS 0x180391: COMSET Warn RaiseError PrintError PrintWarn AutoCommit PARENT DBI::dr=HASH(0x245a424) KIDS 0 (0 Active) IMP_DATA HASH(0x244bd1c) dbih_clearcom 0x244bd7c (com 0x247e3b4, type 2) done. -- DBI::END ($@: , $!: ) >> disconnect_all DISPATCH (DBI::dr=HASH(0x2428bdc) rc1/3 @1 g0 ima801 pid#29840) at C:/Perl/site/lib/DBI.pm line 731 via at k:/ Projects/NewRiskModel/Simple.Risk.Model.pl line 0 -> disconnect_all for DBD::mysql::dr (DBI::dr=HASH(0x2428bdc)~0x245a424) thr#3424c <- disconnect_all= (not implemented) at C:/Perl/site/lib/DBI.pm line 731 via at k:/Projects/NewRiskModel/Simple.Risk.Model.pl line 0 ! >> DESTROY DISPATCH (DBI::dr=HASH(0x2428bdc) rc1/1 @1 g0 ima10004 pid#29840) during global destruction ! <> DESTROY(DBI::dr=HASH(0x2428bdc)) ignored for outer handle (inner DBI::dr=HASH(0x245a424) has ref cnt 1) ! >> DESTROY DISPATCH (DBI::dr=HASH(0x245a424) rc1/1 @1 g0 ima10004 pid#29840) during global destruction ! -> DESTROY in DBD::_::common for DBD::mysql::dr (DBI::dr=HASH(0x245a424)~INNER) thr#3424c ! <- DESTROY= undef during global destruction DESTROY (dbih_clearcom) (drh 0x245a424, com 0x1836ffc, imp global destruction): FLAGS 0x100215: COMSET Active Warn PrintWarn AutoCommit PARENT undef KIDS 0 (0 Active) dbih_clearcom 0x245a424 (com 0x1836ffc, type 1) done. SV = RV(0x22c15b0) at 0x22c15a4 REFCNT = 1 FLAGS = (PADMY,ROK) RV = 0x1c53074 SV = PVHV(0x1e45c4c) at 0x1c53074 REFCNT = 2 FLAGS = (OBJECT,SHAREKEYS) STASH = 0x1f5b01c "Win32::TieRegistry" ARRAY = 0x222f58c (0:14, 1:14, 2:4) hash quality = 121.5% KEYS = 22 FILL = 18 MAX = 31 RITER = -1 EITER = 0x0 Elt "CntValues" HASH = 0x359bb702 SV = IV(0x230a7b0) at 0x230a7b4 REFCNT = 1 FLAGS = (IOK,pIOK) IV = 0 Elt "MaxSubClassLen" HASH = 0xb3d551a2 SV = IV(0x230a860) at 0x230a864 REFCNT = 1 FLAGS = (IOK,pIOK) IV = 0 Elt "FLAGS" HASH = 0x1773e623 SV = IV(0x230a9c0) at 0x230a9c4 REFCNT = 1 FLAGS = (IOK,pIOK) IV = 136 Trace: k:/Projects/NewRiskModel/Simple.Risk.Model.pl, (eval), k:/Projects/ NewRiskModel/Simple.Risk.Model.pl, Win32::TieRegistry::DESTROY, C:/ Perl/site/lib/Win32/TieRegistry.pm, Line: 1488 Carp::confess, C:/Perl/lib/Carp.pm, Line: 45 huh? at C:/Perl/site/lib/Win32/TieRegistry.pm line 1488 Win32::TieRegistry::DESTROY('Win32::TieRegistry=HASH(0x1c53074)') called at k:/Projects/NewRiskModel/Simple.Risk.Model.pl line 0 eval {...} called at k:/Projects/NewRiskModel/Simple.Risk.Model.pl line 0 Compilation finished at Wed May 19 20:59:57 Adding your four lines seems to have added the lines beginning with SV = RV(0x22c15b0) at 0x22c15a4, but none of that info means anything to me. Any light that can be shed on this would be appreciated. Thanks Ted
From: Steve M on 20 May 2010 01:38
On 5/13/2010 10:10 AM, Ted Byers wrote: > I have done all the usual things (as specified in the FAQ), and more, > but it isn't enough. > > Here is how my script starts: > > use strict; > use warnings; > use DBI; > use DateTime::Format::MySQL; > use Date::Manip; > use DateTime::Format::DateManip; > <snip> > > At no time have I made direct use of the file mentioned, so it must be > something one of the above packages has done. Well. Maybe. At least indirectly. Win32::TieRegistry is being called by something else, and I'm wondering..... I've done a little digging, and one article I ran across said that DBI worked fine with Sybase and an older Oracle, but a *newer* copy of Oracle gave the error message you are getting. Hmmm...... I definitely getting the impression it may be a driver issue of some kind... Probably wrong, but I'd certainly look into it. Maybe even try a clean install of Strawberry Perl. (I recommend it because though I've used Activestate for years it recently annoyed me for the last time. :-) Ah.. if you do install Strawberry, more than likely you'll want to check your paths if 'things' don't work out of the box. On my 'Doze machine, I had to fiddle the path to Perl. hth, \s -- "There is no use in your walking five miles to fish when you can depend on being just as unsuccessful near home." M. Twain |