Home arrow Perl Programming arrow Page 6 - Using The Perl Debugger

Test Drive - Perl

One of Perl's better-kept secrets is its built-in debugger, a powerful utility that allows developers to rapidly track down errors in their Perl scripts. This article introduces you to the Perl debugger, explaining how to use it to step through scripts, set breakpoints, inspect variables and objects, watch expressions and perform stack traces.

TABLE OF CONTENTS:
  1. Using The Perl Debugger
  2. Step By Step
  3. Breaking Free
  4. A Watchful Eye
  5. Acts Of Madness
  6. Test Drive
By: icarus, (c) Melonfire
Rating: starstarstarstarstar / 39
June 25, 2003

print this article
SEARCH DEV SHED

TOOLS YOU CAN USE

advertisement

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!



 
 
>>> More Perl Programming Articles          >>> More By icarus, (c) Melonfire
 

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort
   

PERL PROGRAMMING ARTICLES

- Perl Turns 25
- Lists and Arguments in Perl
- Variables and Arguments in Perl
- Understanding Scope and Packages in Perl
- Arguments and Return Values in Perl
- Invoking Perl Subroutines and Functions
- Subroutines and Functions in Perl
- Perl Basics: Writing and Debugging Programs
- Structure and Statements in Perl
- First Steps in Perl
- Completing Regular Expression Basics
- Modifiers, Boundaries, and Regular Expressio...
- Quantifiers and Other Regular Expression Bas...
- Parsing and Regular Expression Basics
- Hash Functions

Developer Shed Affiliates

 


Dev Shed Tutorial Topics: