|
perldebtut - Perl debugging tutorial
A (very) lightweight introduction in the use of the perl debugger, and a
pointer to existing, deeper sources of information on the subject of debugging
perl programs.
There's an extraordinary number of people out there who don't appear to know
anything about using the perl debugger, though they use the language every
day.
This is for them.
First of all, there's a few things you can do to make your life a lot more
straightforward when it comes to debugging perl programs, without using the
debugger at all. To demonstrate, here's a simple script, named "hello", with
a problem:
$var1 = 'Hello World';
$var2 = "$varl\n";
print $var2;
exit;
While this compiles and runs happily, it probably won't do what's expected,
namely it doesn't print "Hello World\n" at all; It will on the other hand do
exactly what it was told to do, computers being a bit that way inclined. That
is, it will print out a newline character, and you'll get what looks like a
blank line. It looks like there's 2 variables when (because of the typo)
there's really 3:
$var1 = 'Hello World';
$varl = undef;
$var2 = "\n";
To catch this kind of problem, we can force each variable to be declared
before use by pulling in the strict module, by putting 'use strict;' after the
first line of the script.
Now when you run it, perl complains about the 3 undeclared variables and we
get four error messages because one variable is referenced twice:
Global symbol "$var1" requires explicit package name at ./t1 line 4.
Global symbol "$var2" requires explicit package name at ./t1 line 5.
Global symbol "$varl" requires explicit package name at ./t1 line 5.
Global symbol "$var2" requires explicit package name at ./t1 line 7.
Execution of ./hello aborted due to compilation errors.
Luvverly! and to fix this we declare all variables explicitly and now our
script looks like this:
use strict;
my $var1 = 'Hello World';
my $varl = undef;
my $var2 = "$varl\n";
print $var2;
exit;
We then do (always a good idea) a syntax check before we try to run it again:
> perl -c hello
hello syntax OK
And now when we run it, we get "\n" still, but at least we know why. Just
getting this script to compile has exposed the '$varl' (with the letter 'l')
variable, and simply changing $varl to $var1 solves the problem.
Ok, but how about when you want to really see your data, what's in that
dynamic variable, just before using it?
use strict;
my $key = 'welcome';
my %data = (
'this' => qw(that),
'tom' => qw(and jerry),
'welcome' => q(Hello World),
'zip' => q(welcome),
);
my @data = keys %data;
print "$data{$key}\n";
exit;
Looks OK, after it's been through the syntax check (perl -c scriptname), we
run it and all we get is a blank line again! Hmmmm.
One common debugging approach here, would be to liberally sprinkle a few print
statements, to add a check just before we print out our data, and another just
after:
print "All OK\n" if grep($key, keys %data);
print "$data{$key}\n";
print "done: '$data{$key}'\n";
And try again:
> perl data
All OK
done: ''
After much staring at the same piece of code and not seeing the wood for the
trees for some time, we get a cup of coffee and try another approach. That
is, we bring in the cavalry by giving perl the '-d' switch on the command
line:
> perl -d data
Default die handler restored.
Loading DB routines from perl5db.pl version 1.07
Editor support available.
Enter h or `h h' for help, or `man perldebug' for more help.
main::(./data:4): my $key = 'welcome';
Now, what we've done here is to launch the built-in perl debugger on our
script. It's stopped at the first line of executable code and is waiting for
input.
Before we go any further, you'll want to know how to quit the debugger: use
just the letter 'q', not the words 'quit' or 'exit':
DB<1> q
>
That's it, you're back on home turf again.
Fire the debugger up again on your script and we'll look at the help menu.
There's a couple of ways of calling help: a simple 'h' will get the summary
help list, '|h' (pipe-h) will pipe the help through your pager (which is
(probably 'more' or 'less'), and finally, 'h h' (h-space-h) will give you
the entire help screen. Here is the summary page:
D1h
List/search source lines: Control script execution:
l [ln|sub] List source code T Stack trace
- or . List previous/current line s [expr] Single step [in expr]
v [line] View around line n [expr] Next, steps over subs
f filename View source in file <CR/Enter> Repeat last n or s
/pattern/ ?patt? Search forw/backw r Return from subroutine
M Show module versions c [ln|sub] Continue until position
Debugger controls: L List break/watch/actions
o [...] Set debugger options t [expr] Toggle trace [trace expr]
<[<]|{[{]|>[>] [cmd] Do pre/post-prompt b [ln|event|sub] [cnd] Set breakpoint
! [N|pat] Redo a previous command B ln|* Delete a/all breakpoints
H [-num] Display last num commands a [ln] cmd Do cmd before line
= [a val] Define/list an alias A ln|* Delete a/all actions
h [db_cmd] Get help on command w expr Add a watch expression
h h Complete help page W expr|* Delete a/all watch exprs
|[|]db_cmd Send output to pager ![!] syscmd Run cmd in a subprocess
q or ^D Quit R Attempt a restart
Data Examination: expr Execute perl code, also see: s,n,t expr
x|m expr Evals expr in list context, dumps the result or lists methods.
p expr Print expression (uses script's current package).
S [[!]pat] List subroutine names [not] matching pattern
V [Pk [Vars]] List Variables in Package. Vars can be ~pattern or !pattern.
X [Vars] Same as "V current_package [Vars]".
y [n [Vars]] List lexicals in higher scope <n>. Vars same as V.
For more help, type h cmd_letter, or run man perldebug for all docs.
More confusing options than you can shake a big stick at! It's not as bad as
it looks and it's very useful to know more about all of it, and fun too!
There's a couple of useful ones to know about straight away. You wouldn't
think we're using any libraries at all at the moment, but 'M' will show
which modules are currently loaded, and their version number, while 'm'
will show the methods, and 'S' shows all subroutines (by pattern) as
shown below. 'V' and 'X' show variables in the program by package
scope and can be constrained by pattern.
DB<2>S str
dumpvar::stringify
strict::bits
strict::import
strict::unimport
Using 'X' and cousins requires you not to use the type identifiers ($@%), just
the 'name':
DM<3>X ~err
FileHandle(stderr) => fileno(2)
Remember we're in our tiny program with a problem, we should have a look at
where we are, and what our data looks like. First of all let's view some code
at our present position (the first line of code in this case), via 'v':
DB<4> v
1
2: use strict;
3
4==> my $key = 'welcome';
5: my %data = (
6 'this' => qw(that),
7 'tom' => qw(and jerry),
8 'welcome' => q(Hello World),
9 'zip' => q(welcome),
10 );
At line number 4 is a helpful pointer, that tells you where you are now. To
see more code, type 'v' again:
DB<4> v
8 'welcome' => q(Hello World),
9 'zip' => q(welcome),
10 );
11: my @data = keys %data;
12: print "All OK\n" if grep($key, keys %data);
13: print "$data{$key}\n";
14: print "done: '$data{$key}'\n";
15: exit;
And if you wanted to list line 5 again, type 'l 5', (note the space):
DB<4> l 5
5: my %data = (
In this case, there's not much to see, but of course normally there's pages of
stuff to wade through, and 'l' can be very useful. To reset your view to the
line we're about to execute, type a lone period '.':
DB<5> .
main::(./data_a:4): my $key = 'welcome';
The line shown is the one that is about to be executed next, it hasn't
happened yet. So while we can print a variable with the letter 'p', at
this point all we'd get is an empty (undefined) value back. What we need to
do is to step through the next executable statement with an 's':
DB<6> s
main::(./data_a:5): my %data = (
main::(./data_a:6): | 
