Using The Perl Debugger - Test Drive (Page 6 of 6 )
Now that you've seen what the debugger can do, let's take it out for a quick test drive. Consider the following simple Perl program, which contains a deliberate error:
#!/usr/bin/perl
# multiply two numbers
sub multiply()
{
my $a, $b = @_;
return $a * $b;
}
# set range for multiplication table
@values = (1..10);
# get number from command-line
foreach $value (@values)
{
print "$ARGV[0] x $value = " . &multiply($ARGV[0], $value) . "\n";
}
This is pretty simple - it accepts a number as input and creates a multiplication table for it. If, for example, you invoked it with the number 4 as argument, you'd expect a multiplication table like this:
4 x 1 = 4
4 x 2 = 8
4 x 3 = 12
4 x 4 = 16
4 x 5 = 20
4 x 6 = 24
4 x 7 = 28
4 x 8 = 32
4 x 9 = 36
4 x 10 = 40
Instead, what you get is this:
4 x 1 = 0
4 x 2 = 0
4 x 3 = 0
4 x 4 = 0
4 x 5 = 0
4 x 6 = 0
4 x 7 = 0
4 x 8 = 0
4 x 9 = 0
4 x 10 = 0
If you're an experienced Perl programmer, you already know the problem. Don't say a word; instead, just follow along as I run this through the debugger.
$ perl -d multiply.pl 4
Loading DB routines from perl5db.pl version 1.19
Editor support available.
Enter h or `h h' for help, or `man perldebug' for more help.
main::(multiply.pl:11): @values = (1..10);
DB<1>
Now, since I'm having a problem with the product of the two numbers, and that product is being calculated by the multiply() subroutine, it makes sense to set a breakpoint at that subroutine with the "b" command.
DB<1> b multiply
I can now step through the script with the "r" command, which will display the return value from the subroutine every time it is invoked.
DB<2> r
main::multiply(multiply.pl:6): my $a, $b = @_;
DB<2> r
scalar context return from main::multiply: 0
4 x 1 = 0
main::(multiply.pl:14): foreach $value (@values)
main::(multiply.pl:15): {
DB<2> r
main::multiply(multiply.pl:6): my $a, $b = @_;
DB<2> r
scalar context return from main::multiply: 0
4 x 2 = 0
main::(multiply.pl:14): foreach $value (@values)
main::(multiply.pl:15): {
DB<2> r
main::multiply(multiply.pl:6): my $a, $b = @_;
DB<2> r
scalar context return from main::multiply: 0
4 x 3 = 0
main::(multiply.pl:14): foreach $value (@values)
main::(multiply.pl:15): {
Hmmm...a return value of zero at every stage is obviously an indication that something is going seriously wrong inside the subroutine. This is probably the reason for the long string of zeroes in the output of my script. Now, if only we could look inside to see what was really going on...
DB<3> s
main::(multiply.pl:16): print "$ARGV[0] x $value = " .
&multiply($ARGV[0], $value) . "\n";
DB<3> s
main::multiply(multiply.pl:6): my $a, $b = @_;
DB<3> s
main::multiply(multiply.pl:7): return $a * $b;
DB<3> x $a
0 undef
DB<4> x $b
0 2
Curiouser and curiouser. As the "x" command clearly shows, the multiply() subroutine is obviously not using correct parameters when performing the
calculation: $a is undefined, $b is 2, and both are wrong.
Now, there are two possible reasons for this: either the subroutine is being passed incorrect values correctly from the main script, or the subroutine is not reading them properly.
Luckily, the first theory is easy enough to test - all I need to do is run the "x" command on the @_ array:
DB<6> s
main::multiply(multiply.pl:7): return $a * $b;
DB<6> x @_
0 4
1 5
Perfect. So the main script is obviously passing the input arguments correctly to the multiply() subroutine, as evidenced by the fact that the @_ array contains the correct values. The problem is therefore related to the extraction of these values from the @_ array into regular scalars - specifically, with line 6 of the script:
DB<10> l 6
6: my $a, $b = @_;
And now the error should be fairly obvious. As any Perl coder knows, when retrieving subroutine arguments from the @_ array into scalars, the list of scalars should be enclosed in parentheses. Corrected, the statement above would read:
DB<10> l 6
6: my ($a, $b) = @_;
Now, when I re-run the script and step through it, the "x" command shows that the subroutine's $a and $b scalars are being populated with the correct values.
DB<1> s
main::multiply(multiply.pl:6): my ($a, $b) = @_;
DB<1> s
main::multiply(multiply.pl:7): return $a * $b;
DB<1> x $a
0 4
DB<2> x $b
0 4
And when I run the script, the output now makes sense:
4 x 1 = 4
4 x 2 = 8
4 x 3 = 12
4 x 4 = 16
4 x 5 = 20
4 x 6 = 24
4 x 7 = 28
4 x 8 = 32
4 x 9 = 36
4 x 10 = 40
Experienced Perl programmers will, of course, point out that I could have saved myself all this trouble either by placing the
use strict();
construct at the top of my script, or by adding the "-w" switch when running the script from the command line.
$ perl -w multiply.pl
Use of uninitialized value in concatenation (.) or string at multiply.pl line 16. Use of uninitialized value in multiplication (*) at multiply.pl line 7. x 1 = 0 Use of uninitialized value in concatenation (.) or string at multiply.pl line 16. Use of uninitialized value in multiplication (*) at multiply.pl line 7. x 2 = 0 ...
Both these methods would have brought the error to my notice without requiring me to use the debugger. However, in some cases, especially cases involving logical errors that a syntax checker will not catch, the debugger can be an invaluable tool in diagnosing problems with your code, since it allows you to step through each line of code and inspect (or change) the variables being used at every stage to catch potentially-serious bugs.
And that's about all for the moment. As you saw over the last few pages, the Perl debugger is a powerful utility, one that can substantially reduce your stress levels when dealing with recalcitrant Perl code. Go ahead, play with it a little...and, until next time, stay healthy!
Note: Examples in this article have been tested on Linux/i586 with Perl 5.8.0. Examples are illustrative only, and are not meant for a production environment. Melonfire provides no warranties or support for the source code described in this article. YMMV!
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
/ 21 
