Debugging question: tracing the origin of an error.
in [Perl]
|
From: Ted Byers on 13 May 2010 13:10 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? Thanks Ted
From: C.DeRykus on 13 May 2010 14:03 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; } -- Charles DeRykus
From: Ted Byers on 13 May 2010 14:56 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; } > > -- > Charles DeRykus Thanks Charles. 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 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. I realize Perl isn't C++, and that the specific method I'd used is probably not viable in perl, but since both languages are Turing complete, anything that is possible in one ought to be possible in the other. So, then, what to do? Thanks Ted
From: C.DeRykus on 13 May 2010 17:56 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
From: bugbear on 14 May 2010 04:04 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; > > 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? The perl debugger might well be worth a try. Disclaimer - I hardly ever use it! BugBear
|
Next
|
Last
Pages: 1 2 3 4 5 6 Prev: FAQ 3.30 What's MakeMaker? Next: FAQ 8.41 How do I use an SQL database? |