Debugging question: tracing the origin of an error.
in [Perl]
|
From: Ted Byers on 19 May 2010 16:51 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
From: Ted Byers on 19 May 2010 16:51 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
From: Ted Byers on 19 May 2010 17:46 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
From: sln on 19 May 2010 18:04 On Wed, 19 May 2010 14:46:43 -0700 (PDT), Ted Byers <r.ted.byers(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: >> >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? > No but, your googlegroups.com is tripple posting this to usenet. -sln
From: Ben Morrow on 19 May 2010 18:54
Quoth Ted Byers <r.ted.byers(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 |