Perl Debuggers in Detail

In this second part of a two-part series on debugging Perl, we will go beyond the author’s favorite debugger and look at a number of alternative Perl debuggers. This article is excerpted from chapter four of the book Mastering Perl, written by Brian D Foy (O’Reilly; ISBN: 0596527241). Copyright © 2007 O’Reilly Media, Inc. All rights reserved. Used with permission from the publisher. Available from booksellers or direct from O’Reilly Media.

Wrapping Subroutines

I don’t have to copy a module file to change its behavior. I can override parts of it directly in my code. Damian Conway wrote a wonderful module called Hook::LexWrap to wrap a subroutine around another subroutine. That means that my wrapper subroutine can see the arguments coming in and the return values going out. I can inspect the values, or even change them if I like.

I’ll start with my simple example program that adds a couple of numbers. As before, it has some problems because I’m passing it the wrong arguments since I can’t tell the difference between $n and $m, and have used $n twice in my call to add. Just running the program gives me the wrong answer, but I don’t know where the problem is:

  #!/usr/bin/perl
 
# @ARGV = qw( 5 6 );

  my $n = shift @ARGV;
  my $m = $ARGV[0];

  print "The sum of $n and $m is " . add( $n, $n ) . "n";

  sub add
         
{
         
my( $n, $m ) = @_;

          my $sum = $n + $m;

          return $sum;
          }

I don’t want to change anything in the code, or, I should say, I want to look at what’s happening without affecting the statements that are already there. As before, I want everything back to normal when I’m finished debugging. Not editing the subroutine makes that easier.

The Hook::LexWrap gives me a chance to do something right after I make a subroutine call and right before the subroutine returns. As the name suggests, it wraps the subroutine with another one to provide the magic. The Hook::LexWrap::wrap function takes the name of the subroutine it will wrap, add in this case, and then anonymous subroutines as pre- and posthandlers:

  #!/usr/bin/perl

  use Hook::LexWrap qw(wrap);

  my $n = shift @ARGV;
  my $m = $ARGV[0];

  wrap add,
         
pre  => sub { print "I got the arguments: [@_]n" },
         
post => sub { print "The return value is going to be $_[-1]n" }
          ;

  # this line has the error
  print "The sum of $n and $m is " . add( $n, $n ) . "n";

  sub add
         
{
         
my( $n, $m ) = @_;

          my $sum = $n + $m;

          return $sum;
          }

The prehandler sees the same argument list as my call to add. In this case I just output the list so I can see what it is. The posthandler gets the same arguments, but Hook::Lex Wrap adds another element, the return value, on the end of @_. In the posthandler,
$_[-1] is always the return value. My program now outputs some useful debugging output, and I see that I’m passing the same argument twice:

  $ perl add_numbers.pl 5 6
  I got the arguments: [5 5 ]
  The return value is going to be 10
  The sum of 5 and 6 is 10

In that output, notice the space after the last 5. Since wrap added an element to @_, even though it’s undef, I get a space between it and the preceding 5 when I interpolate the array in the double-quoted string.

Hook::LexWrap has the magic to handle all the calling contexts too. It’s smart enough to handle scalar, list, and void contexts. In list context, that last element of @_ in the posthandler will be an array reference. In void context, it won’t be anything.

It gets even better than that, though. Hook::LexWrap actually adds that extra element to @_ before it does anything. Look at the last output carefully. After the second argument, there’s a space between the second 5 and the closing square bracket. That’s the space between 5 and the undef value of the extra element in @_.

In the prehandler, I can assign to that element, signaling to Hook::LexWrap that it should assume that it already has the return value, so it doesn’t need to actually run the original subroutine. If the subroutine isn’t doing what I need, I can force it to return the right value:

  #!/usr/bin/perl

  use Hook::LexWrap;

  my $n = shift @ARGV;
  my $m = $ARGV[0];

  {

  wrap add,
         
pre  => sub {
                  print "I got the arguments: [@_]n";
                  $_[-1] = "11";
                 
},
         
post => sub { print "The return value is going to be $_[-1]n" }
         
;
  print "The sum of $n and $m is " . add( $n, $m ) . "n";
  }

  sub add
         
{
          my( $n, $m ) = @_;

          my $sum = $n + $m;

          return $sum;
          }

Now that I’ve assigned to $_[-1] in my prehandler, the output is different. It doesn’t run the subroutine or the posthandler, and I get back 11:

  $ perl add_numbers.pl 5 6
  I got the arguments: [5 6 ]
  The sum of 5 and 6 is 11

With my fake return value, I can give myself the right answer and get on with the right program, and do it without changing the subroutine I want to investigate. This can be especially handy if I’m working on a big problem where other things are broken, too. I know what I need to return from the subroutine so I make it do that until I fix the other parts, or at least investigate the rest of the program while the subroutine returns what it should. Sometimes eliminating a source of error, even temporarily, makes it easier to fix other things.

{mospagebreak title=perl5db.pl}

We introduced the standard Perl debugger in Intermediate Perl so we could examine complex data structures. It’s well documented in the perldebug, and Richard Foley devoted an entire book, Pro Perl Debugging (Apress), to it, so I will only cover enough of the basics here so I can move on to the fancier debuggers.

I invoke the Perl debugger with Perl’s -d switch:

  perl -d add_number.pl 5 6

Perl compiles the program, but stops before running the statements, giving me a prompt. The debugger shows me the program name, line number, and the next statement it will execute:

  Loading DB routines from perl5db.pl version 1.25
  Editor support available.

  Enter h or `h h’ for help, or `man perldebug’ for more help.

  main::(Scripts/debugging/add_numbers.pl:3):
  3:     my $n = shift @ARGV;
    D<1>

From there I can do the usual debugging things, such as single-stepping through code, setting breakpoints, and examining the program state.

I can also run the debugger on a program I specify on the command line with the -e. I still get the debugger prompt, but it’s not very useful for debugging a program. Instead, I have access to the debugger prompt where I can try Perl statements:

  $ perl -d -e 0

  Loading DB routines from perl5db.pl version 1.25
  Editor support available.

  Enter h or `h h’ for help, or `man perldebug’ for more help.

  main::(-e:1): 0
    D<1> $n = 1 + 2;

    D<2> x $n
  0  3
    D<3>

We showed this debugger in Intermediate Perl, and it’s well documented in perldebug and many other tutorials, so I won’t spend time on it here. Check the references in the last section in this chapter, “Further Reading ,” for sources of more information.

{mospagebreak title=Alternative Debuggers}

Besides the standard perl5db.pl, there are several other sorts of debuggers that I can use, and there are several code analysis tools which use the debugging infrastructure. There’s a long list of Devel:: modules on CPAN, and one of them probably suits your needs.

Using a Different Debugger with -D

I can use an alternative debugger by giving the -d switch an argument. In this case, I want to run my program under the Devel::DProf module. The -d switch implies the Devel::, so I leave that off. I’ll cover profilers in depth in Chapter 5.

  $ perl -d:DProf program.pl

If I write my own debugging module, I can pass arguments to the module just like I can with the -M switch. I add the arguments as a comma-separated list after the module name and an equal sign. In this example, I load the Devel::MyDebugger with the arguments foo and bar:

  $ perl -d:MyDebugger=foo,bar

As normal Perl code, this is the same as loading Devel::MyDebugger with use.

  use Devel::MyDebugger qw( foo bar );

Devel::ptkdb

I can use a Tk-based debugger that provides a graphical interface to the same features I have from perl5db.pl. The Devel::ptkdb module does not come with Perl, so I have to install it myself.* I start ptkdb by specifying it as the debugger I want to use with the -d switch:

  $ perl -d:ptkdb program.pl


Figure 4-1.  The Devel::ptkdb provides a graphical debugger using Tk

It starts by creating an application window. In the left pane, I see the program lines around the current line, along with their line numbers (Figure 4-1). Buttons along the code pane allow me to search through the code. In the right pane, I have tabs to examine expressions, subroutines, and the list of current breakpoints.

The “Subs” tab gives me a hierarchal list of package names and the subroutines defined in them (Figure 4-2). These are all of the loaded modules, and I can immediately display the code for any of those functions by selecting the one I want to see. I can select one either by double-clicking or navigating with the arrow keys and hitting <RETURN> when I get to the one I want. It doesn’t change the state of my program, and I can use the “Subs” tab to decide to step into a subroutine to watch its execution, or step over it and continue with the execution of the program.

The “Exprs” tab is especially useful. It has two text entries at the top. “Quick Expr” allows me to enter a Perl expression, which it then replaces with its result, and affects the state of the program if my quick expression sets or changes variables. This is the equivalent of trying a one-off expression in the terminal debugger. That’s nice, but the “Enter Expr” is even better. I enter a Perl expression and it adds it to the list of expressions in the pane below the tabs (Figure 4-3). As I run my code, these expressions update their results based on the current state of the program. I can add the variables I want to track, for instance, and watch their values update.

I start with a simple program where I want to add two numbers. It’s not something that I need to debug (I hope), but I can use it to show the expressions tab doing its thing. At the start of the program, I’m at the start of the program and nothing has run yet. I single-step over the first line of code and can see the values for $m and $n, which I had previously entered as expressions. I could enter much more complex expressions, too, and ptkdb will update them as I move through the code.


Figure 4-2.  In the Subs tab, I can see the subroutine in any loaded package


Figure 4-3.  I can track variable values in the Exprs tab 

{mospagebreak title=Devel::ebug}

The Devel::ebug module by Léon Brocard provides an object-oriented interface to Perl’s debugger facility. It’s a work in progress, so what I say here might be different by the time you read this. The main features should still be there, though.

It comes with its own terminal-based debugger named ebug. It’s a bit of an odd name until you realize how you call it. The missing d in the name comes from Perl’s -d switch.

  $ perl -d:ebug program.pl

I don’t need to use the -d switch, though, since I can call it directly with the ebug program, but I have to call it by quoting the entire command line:

  $ ebug "add_numbers.pl 5 6"
 
* Welcome to Devel::ebug 0.46
  main(add_numbers.pl#3):
  my $n = shift @ARGV;
  ebug: x @ARGV
  — 5
  — 6

  main(add_numbers.pl#3):
  my $n = shift @ARGV;
  ebug: s
  main(add_numbers.pl#4):
  my $m = $ARGV[0];
  ebug: x $n
  — 5

The ebug program is really just a wrapper around Devel::ebug::Console, and I can call Devel::ebug in many different ways. At the core of its design is a detached process. The backend runs the program under the debugger, and the frontend communicates with it over TCP. This means, for instance, I can debug the program on a different machine than on the one it’s running.

The Devel::ebug::HTTP module uses the same Devel::ebug backend, but sets up a mini web server.I start the ebug_http the same way I did with the console version, but instead of giving me a prompt, it tells me the URL I need to access to see the debugger:§

  $ ebug_http "add_numbers.pl 4 5"
  You can connect to your server at http://albook.local:8321

The web page shows me a bare bones debugger interface (Figure 4-4). Remember, this is basically a proof of concept, but even as that it’s very impressive and can serve as the basis for your own tailor-made programs.


Figure 4-4.  The Devel::ebug::HTTP module lets me debug a program on a remote server through my browser

{mospagebreak title=Other Debuggers}

EPIC

Eclipse‖ is an open source development environment that runs on a variety of platforms. It’s a Java application, but don’t let that scare you off. It has a modular design so people can extend it to meet their needs. EPIC# is the Perl plug-in for Eclipse.

Eclipse is not just a debugger though, and that’s probably not even its most interesting features. From the source code of my Perl program I can inspect classes, call up parts of the Perl documentation, and do quite a bit more.

Komodo

ActiveState’s Komodo (Figure 4-5) started off as an integrated development environment for Perl on Microsoft Windows, although it’s now available on Solaris, Linux, and Mac OS X. It handles Perl as well as several other languages, including Tcl, Ruby, PHP, and Python.


Figure 4-5.  ActiveState’s Komodo is a complete development environment and even comes with a tutorial on its use

Affrus

Affrus is a Perl-only debugger from Late Night Software* for Mac OS X. Since I work almost exclusively on Mac, I really appreciate a debugger that’s quite Mac-like. Late Night Software started with Script Debugger for AppleScript, so they’re tuned into Macs. Besides that, Affrus has the usual debugging features.

One of the features I find especially useful is Affrus’s Arguments pane. I can add invocations of my program, and then select which one I want to run. In Figure 4-6, I’ve added two different command lines and selected the first one, which has the solid diamond next to it. When I run the program, @ARGV gets the elements 5 and 6. If I save this as an Affrus file, the next time I open the program with Affrus I still have access to those command lines.


Figure 4-6.  Affrus allows me to configure several different command lines to use with my program; it updates expressions as my program runs

Like other debuggers, Affrus has a window where I can track the values of expressions. Affrus uses a separate window to display those. I can also look in the Debugging pane to see a list of all of the variables at any time (Figure 4-7).

{mospagebreak title=Summary} 

I can debug my Perl program at almost any level I want, from inserting debugging code around that part I want to inspect, or tweaking it from the outside with an integrated development environment. I can even debug the program on a machine other than the one I run it on. I don’t have to stick with one approach, and might use many of them at the same time. If I’m not satisfied with the existing debuggers, I can even create my own and tailor it for my particular task.

Further Reading

Perl Debugged by Peter Scott and Ed Wright (Addison-Wesley) is one of the best books about actually programming with Perl. Not only do they show you how to effectively debug a Perl program, but they also show you how to not get yourself into some of the common traps that force you to debug a program. Sadly, this book appears to be out


Figure 4-7.  Affrus shows me the values of package variables in the Debugging pane

of print, but don’t let the $1.99 price for a used version on Amazon.com color your notion of its usefulness.

Pro Perl Debugging (Apress) by Richard Foley tells you everything you need to know about the perl5db.pl debugger, which comes with Perl. If you like Perl’s default debugger, this book will tell you everything you want to know about it.

My first ever piece of Perl writing was a little piece for The Perl Journal number 9 called “Die-ing on the Web.” It’s available at my personal web site: http://www.pair.com/ comdog/Articles/Die_and_the_Web.txt.

I talk more about Hook::LexWrap in “Wrapping Subroutines” in the July 2005 issue of The Perl Journal. The article originally appeared in The Perl Journal and now appears in the “Lightweight Languages” section on Dr. Dobb’s Journal Online: http:// www.ddj.com/dept/lightlang/184416218.

The Practice of Programming by Brian W. Kernighan and Rob Pike (Addison-Wesley) discusses their approach to debugging. Although this isn’t a Perl book, it really doesn’t need to be about any language. It’s practical advice for any sort of programming.  


 

* Larry Wall says that Laziness, Impatience, and Hubris are the principal virtues of a programmer, but those only work if the programmer is creating the code. Everyone else in the software development life cycle needs Tact, Humility, and Low Blood Pressure.

† In Chapter 10, I show how I do this with third-party modules, too: copy the source to a private directory I add to the front of @INC. I can edit that copy without worrying about breaking the original.

‡ I know I should wrap an eval around this, but I need an example where things go wrong. Even if I did wrap it in an eval, I still need to find the culprit passing the unexpected input.

§ It changes all of the calls, so if I’m using mod_perl I’ll end up changing it for every program since they share the same global variables. Oops.

‖ My __DIE__ handler can escape die’s further exception processing by using exit or another die, which won’t be special inside my handler. See perlvar’s discussion on %SIG for details.

#And I really mean mess. These functions both call Carp::longmess, and once you see the output, you’ll agree.

* This might mean that I have to install the Tk module too. Once installed, I also have to be able to display it in some sort of window manager. On my Powerbook, I use Apple’s X11 program (which is really XFree86
to the rest of the world). Windows users might want to use something such as ReflectionX.

† The run method to Devel::ebug::Console concatenates with an empty string everything in @ARGV, so calling this example without the quotes tries to run the program named add_numbers.pl56 with no arguments.

‡ Once you get everything installed, but sure that you copy the root/ directory from the Devel::ebug::HTTP distribution to the same directory as the Devel::ebug::HTTP modules. Find that directory with perldoc -l
Devel::ebug::HTTP. The root/ directory has the files that Catalyst needs to make the web pages.

§ I can also guess the URL, since I know the name of the machine and can figure out which port it will use.

‖ The Eclipse Foundation (http://www.eclipse.org.

#Eclipse Perl Integration (http://e-p-i-c.sourceforge.net).

* Late Night Software (http://www.latenightsw.com).  

[gp-comments width="770" linklove="off" ]

antalya escort bayan antalya escort bayan Antalya escort diyarbakir escort