Perl Debugging Tips

While a good debugger greatly increases the value of the language, the debugger is just a part of Perl Programming Environment. It does not replace a good editor, database of typical Perl errors, lint, prettyprinter and other important part of Perl programming environment. In a way this is a the "last resort" to find a particular bug in the program.

The problem with command line debuggers is that you need to remember set of commands to use it productively. It is not an easy task especially if you do not use debugger daily. One obligatory thing to do is to print a cheat-sheet and put it above your monitor. I for example noticed that from one debugging session to another I forget even some essential commands.

If you think that because I wrote this page I use all the commends discussed you are deeply mistaken. I use a very primitive subset close to the minimal set described below. And what is interesting any my attempts to use a richer subset fail -- from one episode during which I can benefit from this additional functionality to another I completely forget how to use it.

A typical person probably is not able to remember more then seven Perl debugger commands. In this sense I am a typical person although it is more correctly to say not seven commands but seven groups of similar command as brain works in hierarchical chunks.  I typically use just the following seven commands:

1. n -- single step without stepping into subroutines. You need to enter it only the first time. After that pressing Enter will repeat the command.
    
2. s -- single step with stepping into subroutines. This is an alternative command to n and it is useful if you need to look how a particular subroutine behaves on the text data.
    
3. c -- continue processing until a break of some sort.  In the simplest (and most useful) case a line number can serve as one time (temporary) breakpoint, for example:

   c 200

4. l min+incr -- displays  "window" of the program's code of incr lines. Without parameters defaults to 10 lines window from the last executed line. Repeat of command without parameters bring the next ten lines and so on.  With two parameters shown lists incr+1 lines of the script starting at min.
    
5. p -- a regular Perl print command, so you can use the normal Perl syntax there, for example:

   p "$ARGV[0]\n$_";

6. ! number  -- Redo a previous command (without number defaults to the previous command). Perl debugger numbers debugger commands in its prompt so scrolling back you can see what command that you entered needs to be repeated.
    
7. H -- lists the debugger commands history. First of all it can serve as an alternative to scrolling back. This way you will see commands that you already entered in this session. You can limit output by providing a number prefixed with a minus sign. For example:

   H -5

   it will displays the last 5 commands. Only commands longer than one character are stored in the history. (s or n, are omitted from history).

See more at Debugging Perl Scripts. A good free introduction to Perl debugger can be found in perldebtut - perldoc.perl.org

Best Perl debugger tips

You can execute any external command in the debugger using !! command

This debugger command runs the external command in a subprocess, which will read from DB::IN and write to DB::OUT. Shell used is the shell defined in $ENV{SHELL} external variable

To look at a "window" of source code around the breakpoint, use the w command:

DB<2> w
5     }
6
7       sub infested {
8==>b       my $bugs = int rand(3);
9:          our $Master;
10:         contaminate($Master);
11:         warn "needs wash"
12              if $Master && $Master->isa("Human");
13
14:         print "got $bugs\n";

DB<2>

As you see by the ==> marker, your current line is line 8, and by the b there, you know it has a breakpoint on it. If you'` had set an action, there also would also have been an a there. The line numbers with colons are breakable; the rest are not.

Command c can be used with line number.

In this case the debugger will run the script to this temporary breakpoint and switch to interactive mode. For example c 200 will run script till the line 200 or to the end if the line 200 is not executed on particular data.

Switching to step-by-step execution dynamically from within the program

You can switch to step-by-step execution using Perl debugger from within your Perl program itself. to transfer control back to the debugger use the following statement, which is harmless if the debugger is not running:

$DB::single = 1;

If you set $DB::single to 2, it's equivalent to the n command, whereas a value of 1 emulates the s command.

The $DB::trace variable should be set to 1 to simulate the t command.

To enter Perl debugger without supplying a program and use execution "on the fly"

To enter the debugger without supplying a program, supply the -e option with the -d option:

perl -de 1

This line starts the debugger with a "program" consisting of the single statement

1;

(which is just a dummy statement). Starting the debugger this way enables you to try small tests interactively and examine the system variables resulting from their execution. Very useful for debugging regular expressions.

Any debugger command output can be piped via external program using pipe symbol like in shell.

Write down watches for the program in a special file that you can preload staring the debugger or load any time with the source statement. You can also define an aliases for useful but long command (especially p commands) in the same file so that the next session you do not need to retype them.

If the output of a debugger built-in command scrolls past your screen, just precede the command with a leading pipe symbol so it's run through your pager. For example:

 |h

NEWS CONTENTS

• 190910 : Debugging Tips ( Debugging Tips, )

Old News ;-)

Debugging Tips

The goal is pretty simple: you want your code to work. The current state of affairs is also pretty simple: it ain't working. This note is all about how to get from where you are to where you want to be. In PHENIX, we have all sorts of code. There are interpreted scripts in shell, perl and ROOT macros. There are programs compiled from C, C++ and Fortran source code. There are standalone programs. There are shared libraries. And there are dynamically loaded shared libraries. It's quite a zoo and figuring out what you should do to diagnose the source of a problem when something isn't working properly can be a bit daunting.

I recently gave a presentation about debugging in PHENIX.

Before I start describing specific techniques for debugging code, here is some more general advice.

• Suspect the obvious. Before you convince yourself that omicron rays from Alpha Centauri are responsible for your latest seg fault, investigate a few of the more likely causes. See if your environment is set up properly. See if you've made a typo. It may sound like silly advice, but I get a lot of people dropping into my office swearing that the most unlikely things are at fault.
• Localize the error. Often the most productive goal to have when debugging is to find out precisely where the error is happening. Check the state of the running program at that point and more likely than not you'll see the cause of the problem.
• Make simple test cases. Your code will often be part of a much bigger, much more complex system. Try making a simple standalone program to exercise your code in relative isolation.
  
• Check your facts. Take care to be sure you know what you think you know. I frequently see people launch themselves down long slow dead-ends because they thought (based on pretty sloppy evidence) that something couldn't be at fault.
• Learn a bit about what's under the hood. If you don't have even the vaguest idea of what a compiler does or how shared libraries are used or how a Makefile works, many simple things will confuse you and debugging your code will be much more difficult.
• The usual suspects. Check your use of pointers. See if you are overstepping the bounds of some array. There, you've probably investigated the cause of 50% of all bugs.
  

The long-time favored refuge of those who don't know how to use better techniques. I hope this note will help you learn a few of these better techniques and make the practice of embedding print statements in your code a thing of the past. Is there a place for the print statement in the armamentarium of the serious debugger? Well, yes, but those places are few and far between. Depending on the environment in which you're working, a print statement may be the most sophisticated option at your disposal for debugging distributed programs like those built on top of MPI (message passing interface). It might be your only option if you're debugging code running on stripped down embedded processors.

You're not debugging code under those conditions. Stop using print statements to debug your code.

Script tracing

What's a script? Roughly speaking, it's a piece of code that gets fed to an interpreter whenever you want to use it. It's not quite that simple in real life, but that'll do for now. We have lots of scripting languages. Shell scripts, perl scripts, and ROOT macros are all scripts. There are a few good techniques for debugging scripts. One of the easiest is tracing.

Tracing means telling the interpreter that's handling the script to print out each line of the script before it executes it. The output of the script also gets printed, so you end up with a log of source lines intertwined with script output. It's a bit like embedding a print statement before each and every line of your script. It can result in a lot of undigested information, and sometimes that's enough to track down the reason your script isn't working the way you thought it was supposed to. Tracing, like embedding pring statements, has the downside that it's not very flexible; you're just a passive observer as your script runs and spews its output to the screen. You can't control your program. You can't change the values of any variables. You can' do much of anything excpet watch. But sometimes that's enough.

Tracing shell scripts

Shell scripts are very useful. They must be useful since they come in such a variety of flavors. Among the choices you have are sh, csh, tcsh, ksh, zsh and ash scripts. They're all similar, yet quirkily different. Most of the scripts you'll encounter (or write) will be sh or tcsh scripts. You can turn on tracing for these type of scripts (and for some of the others also) by adding the command option "-xv" to the command line of the appropriate interpreter. For instance, suppose you have a tcsh script called dpm.csh that contains the following lines:

foreach n (5 2 1 0)
 @ i = 10 / $n   
 echo $i
end

If you run this straight away, you should see this:

% tcsh dpm.csh
2
5
10
Division by 0.

OK, there's a bug in the code (but then you knew that). Let's turn on tracing and see if it helps us narrow things down. Do it like this:

% tcsh -xv dpm.csh
foreach n ( 5 2 1 0 )
@ i = 10 / 5
echo 2
2
end
@ i = 10 / 2
echo 5
5
end
@ i = 10 / 1
echo 10
10
end
@ i = 10 / 0
Division by 0.

At least you can see what the script was planning on doing before it actually did it. You can see the line where the division by zero is being performed, followed by the line which prints an error message to the screen. This is such a simple example that the tracing doesn't really add much, but you should know how to do it. It can help for much more complicated scripts.

Tracing perl scripts

There are similar techniques available for tracing a perl script. Suppose you had a similarly simple perl script called dpm.pl that contained the following lines:

foreach $n (5, 2, 1, 0)
  {
    $i = 10 / $n;
    print "$i\n";
  }

Pretty much the same thing as the shell script above. Run it and it produces pretty much the same output too.

% perl dpm.pl
2
5
10
Illegal division by zero at dpm.pl line 2. 

To trace this script, run it under the perl debugger (by adding the "-d" command line option). At the debugger prompt, type the command "t" to turn on tracing. Follow that with "r" to run the script and you'll get the tracing output you're looking for. Type "q" to quit the debugger. Like this:

% perl -d dpm.pl
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::(dpm.pl:1):	foreach $n (5,2,1,0) {
  DB<1> t
Trace = on
  DB<1> r
main::(dpm.pl:2):	 $i = 10 / $n;
main::(dpm.pl:3):	 print "$i\n";
2
main::(dpm.pl:1):	foreach $n (5,2,1,0) {
main::(dpm.pl:2):	 $i = 10 / $n;
main::(dpm.pl:3):	 print "$i\n";
5
main::(dpm.pl:1):	foreach $n (5,2,1,0) {
main::(dpm.pl:2):	 $i = 10 / $n;
main::(dpm.pl:3):	 print "$i\n";
10
main::(dpm.pl:1):	foreach $n (5,2,1,0) {
main::(dpm.pl:2):	 $i = 10 / $n;
Illegal division by zero at dpm.pl line 2, <IN> line 2.
Debugged program terminated.  Use q to quit or R to restart,
  use O inhibit_exit to avoid stopping after program termination,
  h q, h R or h O to get additional info.  
  DB<1> q

It may look a bit wordy, but it's very much the same thing as you could see when you traced the shell script. It helps you localize the error (it's got something to do with line 2) and that can be very useful in tracking down the cause of the problem.

Recommended Links

Softpanorama Recommended

Top articles

Sites

Perl Debugger Tutorial 10 Easy Steps to Debug Perl Program

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March, 12, 2019