Debugging question: tracing the origin of an error.
in [Perl]
|
From: Steve M on 15 May 2010 00:10 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; > > 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 I use the below to trace down this sort of thing.. Posted it in response to something else (CGI related) a few weeks ago and no one pointed out any obvious no-no's so it was either more or less acceptable or else was thought so stupid is was ignored. :-) Anyway, the meat of the thing uses Perl's caller function and it iterates back through stack frames recording a trace. Very useful at times and may help you determine what is going on... I DID fiddle this a little bit to run from command line (html stuff removed) so it might have a syntax error, though it doesn't look like it... # a different approach to trapping errors..... # screws up eval used as an error trap $SIG{'__DIE__'} = $SIG{'__WARN__'} = sub { my $error = shift; chomp $error; $error =~ s/[<&>]/"&#".ord($&).";"/ge; # entity escape; $error = &Caller_error_path( $error,1,0 ); print "$error\n"; exit 0; }; sub Caller_error_path { my $error = shift; my $Shift = shift; my $Pop = shift; $error ||= ''; my $i = 0; my @call_list = (); while( my($p, $f, $l, $s, $h, $w ) = caller($i++) ){ my $string = ''; $f and $string .= "$f, "; $l and $string .= "Line: $l\n"; $s and $s !~ /main::__ANON__/ and $string .= "$s, "; push @call_list, $string; } $Shift and shift @call_list; $Pop and pop @call_list; @call_list = reverse @call_list; my $path = "\nTrace:\n"; $path .= join '', @call_list; return "$path\n$error"; } 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
From: Tad McClellan on 15 May 2010 08:39 Steve M <stevem_clipthis_(a)clubtrout.com> wrote: > no one pointed out > any obvious no-no's > $error = &Caller_error_path( $error,1,0 ); You should lose that ampersand. perldoc -q function What's the difference between calling a function as &foo and foo()? -- Tad McClellan email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/" The above message is a Usenet post. I don't recall having given anyone permission to use it on a Web site.
From: Steve M on 15 May 2010 15:24 On 5/15/2010 5:39 AM, Tad McClellan wrote: > Steve M<stevem_clipthis_(a)clubtrout.com> wrote: > >> no one pointed out >> any obvious no-no's > >> $error =&Caller_error_path( $error,1,0 ); > > > You should lose that ampersand. > > > perldoc -q function > > What's the difference between calling a function as&foo and foo()? > > Hmmmm... Well, I got a comment. :-) Bear with me being a little thick here, as I'm not sure I see a functional problem with the way I'm doing it. First, I admit that my understanding of prototypes is not as strong as it might be since I rarely fiddle with them. Nevertheless, my understanding is/was that using the '&' makes no difference except for passing the current @_ which makes no difference (as far as I can tell) if the called function does not address it's own @_ in any way. The docs referenced seem to say the same thing (to me). They show an example demonstrating the differing behavior, explain a usage for the behavior, but do not indicate one should not make a call as I have done above. In the code referenced above, I *am* passing arguments and the docs (and Programming Perl) seem to say I'm correct in thinking '&' or not makes no difference in that case. Am I???? If the called function performed based on the existence of passed value(s), then I can see the point of worrying about it. On the other hand I would hope I'd know what a subroutine I was calling did, and I am aware of the issue, so..... In short, is this a style/usage thing? Or am I totally missing some other potential problem? TIA, \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
From: Ben Morrow on 15 May 2010 17:01 Quoth Steve M <stevem_clipthis_(a)clubtrout.com>: > On 5/15/2010 5:39 AM, Tad McClellan wrote: > > Steve M<stevem_clipthis_(a)clubtrout.com> wrote: > > > >> no one pointed out > >> any obvious no-no's > > > >> $error =&Caller_error_path( $error,1,0 ); > > > > > > You should lose that ampersand. <snip> > In short, is this a style/usage thing? Or am I totally missing some > other potential problem? It's mostly a style/usage thing. The biggest potential problem is that the & calls ignore prototypes; a smaller (but IMHO just as important) problem is that the & asks for a rather specific and rarely-wanted feature that you don't need in this case, so anyone reading that code has to think 'Why is that & there? Why does this call need to override prototypes?'. Ben
From: Steve M on 15 May 2010 23:14
On 5/15/2010 2:01 PM, Ben Morrow wrote: > > Quoth Steve M<stevem_clipthis_(a)clubtrout.com>: >> On 5/15/2010 5:39 AM, Tad McClellan wrote: >>> Steve M<stevem_clipthis_(a)clubtrout.com> wrote: >>> >>>> no one pointed out >>>> any obvious no-no's >>> >>>> $error =&Caller_error_path( $error,1,0 ); >>> >>> >>> You should lose that ampersand. > <snip> >> In short, is this a style/usage thing? Or am I totally missing some >> other potential problem? > > It's mostly a style/usage thing. The biggest potential problem is that > the& calls ignore prototypes; a smaller (but IMHO just as important) > problem is that the& asks for a rather specific and rarely-wanted > feature that you don't need in this case, so anyone reading that code > has to think 'Why is that& there? Why does this call need to override > prototypes?'. > > Ben > OK, I guess I can see that. I was aware of the pass through issue(s), but wrote that way anyway because it makes/made it easier for me to visually scan the code for subroutine calls. And I wasn't real concerned about the prototype issues since I don't use that approach. But if it makes things confusing for the next poor sod who comes along.... well, I'm not planning on living forever. Thanks guys, you've given me something to think about. \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 |