Learning the perl debugger: Lesson 5


This post follows on from lesson 4 in this series of posts.

Hopefully you’re no longer fearful of the debugger, and are curious to learn more debugging techniques.

In this lesson you’ll learn more about the use of breakpoints to help you reach points of interest more quickly.

05. Working with breakpoints

This lesson shows you how to stop the debugger in places of your choosing.

No breakpoints

Run the script in the debugger

perl -d break.pl

Let the script run through naturally with c. You should see the ‘Debugged
program terminated’ message.

Stopping to investigate

Let’s assume that some educated intuition has made us interested in the
random_int() sub.

b random_int

This time we stopped somewhere different. Using v quickly reveals we
stopped execution as soon as we entered the function we said we were
interested in.

The breakpoint persists over restarts:


will stop as we enter the function again.

There can be more than one

Hopefully it’s not surprising to know that you aren’t limited to just one
breakpoint. Set two more breakpoints:

b some_sub
b 13

What’s that second one? We’ve inspected the source file and decided that we’re
interested in line 13, b 13 adds a breakpoint at line 13.


When the debugger stops execution, look at the prompt and use your view
commands to see where you are. Make sure you understand why you stopped at
each location.

What do we have?

You can use L to list breakpoints that you have set.

Curiously, the breakpoints are listed as:

break if (1):

Breakpoints can have conditions attached to them; if not specified they
default to ‘always’, which is expressed as if (1).

First, clear all the current breakpoints:

B *

Restart the script and add a conditional breakpoint:

b 13 $val == 12

If we c to progress through the script we do not stop at line 13.

B *
b 13 $val == 13

This time we do stop at our breakpoint. This technique can be useful when you
expect to enter a function multiple times but only care about debugging it
when a specific value is used in it.

Finally, let’s remove one breakpoint:

B 13

We could have used B * to delete all breakpoints, but this is an easy
way to wind down this lesson.

Lesson Summary

  • b – set a breakpoint (current line)
  • b [sub] – set a breakpoint (specified function)
  • b [line] – set a breakpoint (specified line)
  • B [line] – clear a breakpoint for line
  • B * – clear all breakpoints
  • L – list break/watch/actions
Print Friendly
This entry was posted in Perl, Tutorial and tagged , , , , , , by Chisel. Bookmark the permalink.

About Chisel

I've been interested in technology since my childhood (my Acorn Electron era). Commercially I've worked with C and VBA (Access) [but we don't talk about that]. In 2000 I secured my first role as a Perl Programmer and that's been my primary language since then. I dabble in bash, puppet, and a few other skills that help me dip my toe in the DevOps water, or provide a conduit beween the dev and ops worlds. I joined Net-A-Porter in November 2006 and have been happily evolving with the business since then.

One thought on “Learning the perl debugger: Lesson 5

  1. (Shameless plug alert)

    Please consider using,describing, or comparing the debugger Devel::Trepan (https://metacpan.org/pod/Devel::Trepan) .

    Why? Well, if you want to not have to learn to use another debugger, then I recommend this one.

    Why? Well, if you know gdb, then this is similar. And it is similar to the other debuggers I wrote for bash, python and Ruby. That is a design goal: stick to a common command set. (Even if like the QWERTY keyboard it might not be totally optimal.)

    Another design goal is to have extensive documentation both in POD format and available right inside the debugger (still using that POD format). For example, see this help on the eval command (which is roughly like perl5db’ s “x”): https://metacpan.org/pod/Devel::Trepanhttps://metacpan.org/pod/Devel::Trepan::CmdProcessor::Command::Eval . Don’t remember the debugger commands? Well there is command completion if you run inside a terminal. Want a list of commands? Type “help *”.

    And with this debugger you’ll also get syntax highlighting.

    But the other totally independent reason I wrote this was not just from the user side, but from the standpoint of trying to reassess the underlying runtime support and rewrite what I think is unarguably, unmodular, hard-to-maintain, and anacronistic Perl code of an era long gone. It is debatababout how successful I was and whether my style meets your expectation, but all I can say is it’s better.

    The wiki for the project discusses some of this https://github.com/rocky/Perl-Devel-Trepan/wiki and in particular see the links to the blog posts under that.

    Also worth looking at and comparing is the debugger Devel::Hdb which also uses a more modular and modern style and provides a debugger as a RESTful web service.

    In sum, perl5db has seen it’s day. Rather than promote its use, please let’s help it get its much-needed retirement. Thanks.

Leave a Reply