What are some good Perl debugging methods?

Devel::Trace - print every line that executes
Carp::REPL - drop into a REPL* when the code throws a warning
Devel::ebug - a debugger you can control from Perl code
Enbugger - use a debugger at runtime regardless of whether your process was started with debugging

edited Nov 19 '20 at 00:55

Peter Mortensen

30,738
21
105
131

answered Jun 24 '09 at 14:56

Chas. Owens

64,182
22
135
226

1

* REPL = Read, Eval, Print Loop (== interactive interpreter) – j_random_hacker Jun 24 '09 at 15:22

score 9 · Answer 3 · edited Nov 19 '20 at 00:47

9

I like Devel::Trace. Basically it gives you an execution dump, showing you the code paths.

On another side, test-driven development is all the rage now, so you could also be interested in profiling tools like Devel::NYTProf for highly advanced testing. See this Tim Bunce's blog post for an interesting overview.

edited Nov 19 '20 at 00:47

Peter Mortensen

30,738
21
105
131

answered Jun 24 '09 at 11:58

wazoox

1,384
16
27

score 8 · Answer 4 · edited Oct 11 '09 at 00:00

8

I use ActiveState Komodo for step-by-step debugging.

Eclipse has a step by step debugger for its EPIC plugin.

Personally I prefer the ActiveState version. It just seems more solid and stable, but it does cost (and work is paying for me). If it was my money then I would use Eclipse and EPIC as these are free.

edited Oct 11 '09 at 00:00

Peter Mortensen

30,738
21
105
131

answered Jun 24 '09 at 12:00

Xetius

44,755
24
88
123

score 6 · Answer 5 · answered Jun 24 '09 at 17:58

6

The best debugging aids are small routines, short scopes, limited side effects, and lots of tests. Stop bugs before they hatch.

answered Jun 24 '09 at 17:58

brian d foy

129,424
31
207
592

score 5 · Answer 6 · edited Apr 07 '14 at 16:43

5

My usual range of tools is:

print statements and Data::Dumper for simple cases
perl -d

That's usually enough. There is ddd; I heard it's quite nice, but never played with it.

For some tasks (which are not really debugging, but close to it) I use Devel::NYTProf.

edited Apr 07 '14 at 16:43

titanofold

2,852
1
15
21

answered Jun 24 '09 at 10:59

2

Suggestion: s/Data::Dumper/Data::Dump/. It's way more nutritious. – j_random_hacker Jun 24 '09 at 15:21

score 4 · Answer 7 · edited Nov 19 '20 at 00:45

4

Some people use print statements in order to see what's going on in sections of a program that aren't doing what they thought the code would do. (I.e., as a way of checking what is actually contained in a variable at a given point of execution.)

edited Nov 19 '20 at 00:45

Peter Mortensen

30,738
21
105
131

answered Jun 24 '09 at 10:43

Telemachus

19,459
7
57
79

2

I like to use "warn" instead of "print" so it goes to stderr and not stdout. "print STDERR" works too but needs more typing. – laalto Jun 24 '09 at 11:01

score 4 · Answer 8 · edited Nov 19 '20 at 00:59

Depending on what you're doing, Log::Log4perl provides an easy way to manage the 'print' style of debugging particularly in bigger applications:

provides various logging levels (Debug, Info, Error, Warning, and Fatal)
controlled from configuration files (easy to have debugging on development box, only errors on production box, for example)
configurable by sections of your application (e.g., web application in one log file at one level, cron scripts in another at a different log level)
configurable by class - easy to quieten noisy modules, or add detailed debugging to somewhere deep within an application

Most people use Log::Log4perl when Log::Message (a core module) would do. — MkV, Sep 29 '10 at 01:59

score 3 · Answer 9 · edited Nov 19 '20 at 00:53

3

Test::More for writing basic tests, Hook::LexWrap, Test::MockObject, Test::Deep, Test::MockTime, Test::WWW::Mechanize and many others for advanced tests.

Attribute::Signature for checking sub parameters. Carp::Assert for contract-based programming.

Devel::Ebug::Wx or Devel::ptkdb (and soon better support in Padre) can be used for easier debugging.

edited Nov 19 '20 at 00:53

Peter Mortensen

30,738
21
105
131

answered Jun 24 '09 at 14:49

Alexandr Ciornii

7,346
1
25
29

score 3 · Answer 10 · edited Nov 05 '20 at 01:41

3

Emacs, hands down:

emacs my_script.pl
M-x perldb

Emacs will prompt you:

Run perldb (like this): perl my_script.pl
Hit enter (or add command line switches)

Now use the debugger as usual.

Type 'c' to continue executing the code, which will now follow your code as you execute through it.

Emacs is fully integrated with its debuggers and will make debugging Perl code nearly trivial.

edited Nov 05 '20 at 01:41

Peter Mortensen

30,738
21
105
131

answered Sep 28 '10 at 22:56

Felix

1
1

score 2 · Answer 11 · edited Nov 19 '20 at 01:03

2

Use Devel::SimpleTrace for the most elegant seamless stateless-debugging.

perl -MDevel::SimpleTrace -we'warn "main"; sub foo{ warn "outer"; sub { warn "inner" } }; foo()->()'

edited Nov 19 '20 at 01:03

Peter Mortensen

30,738
21
105
131

answered Aug 26 '09 at 20:27

Evan Carroll

78,363
46
261
468

score 2 · Answer 12 · answered Oct 10 '09 at 21:16

During development, I like to embed printf statements in strategic places (not too many) which are enabled with a debug flag like this:

printf("h='$h', j='$j', ... (%d)\n", __LINE__) if $debug;

where the debug flag is defined at the top of the script:

my $debug = $ENV{DEBUG} || 0;

Now instead of having to remember to comment out all of the printf lines, I just run the script as follows:

DEBUG=1 ./script.pl

After testing when everything is ready for production, the debug lines can be removed:

cat script.pl | grep -v 'if $debug;'

score 2 · Answer 13 · edited Apr 07 '14 at 16:33

2

If you don't like perl -d then Devel::REPL and Carp::REPL are both nice alternatives.

edited Apr 07 '14 at 16:33

titanofold

2,852
1
15
21

answered Oct 10 '09 at 23:36

singingfish

3,136
22
25

pity Devel::REPL requires the 400 pound Moose (and various MooseX modules), and Carp::REPL depends on Devel::REPL – MkV Sep 29 '10 at 02:02
And this is a problem because...? – singingfish Oct 01 '10 at 21:22

score 2 · Answer 14 · edited Nov 19 '20 at 01:07

Personally, I'm a big fan of Smart::Comments. It makes tracing dead simple, and there isn't any need to strip it out again, either.

use Smart::Comments -ENV;
...
sub myroutine {
    my ($self, @args) = @_ ;
    ### args: @args
    ...
}

If Smart_Comments has been set in the environment, the lines commencing with ### are converted to debug output, with Dumper() used automagically. If the environment variable isn't set, the debug stuff is completely inert.

It has heaps of features and will produce progress bars, warnings, abort conditions as well as plain old debug output.

Appropriate tests are all good, and I'm not dismissing a good test-driven development (TDD) development methodology, but when trying to get to the bottom of an existing bug, Smart::Comments is the go.

And it is a source filter, hence fragile. – MkV Sep 29 '10 at 02:00 — MkV, Sep 29 '10 at 02:00

score 1 · Answer 15 · edited Nov 05 '20 at 01:35

1

Generally I use

perl -d

for debugging.

You can also use the Eclipse Perl Integration (EPIC) plug-in for Eclipse. It offers a rich debugging environment available and integrated with the EPIC Perl development environment. You can use it, and it is generally helpful.

edited Nov 05 '20 at 01:35

Peter Mortensen

30,738
21
105
131

answered Sep 04 '09 at 06:05

PJ.

625
3
12
24

score 0 · Answer 16 · answered Jun 24 '09 at 10:48

0

Writing tests can mostly decrease debugging time, I think.

answered Jun 24 '09 at 10:48

Alan Haggai Alavi

72,802
19
102
127

score 0 · Answer 17 · answered Jul 08 '09 at 15:35

0

Some Other methods

CGI::Dump

Benchmark

Command-line options 

__DATA__ & <DATA> 

$.

__FILE__ & __LINE__ 

warn() & die()

answered Jul 08 '09 at 15:35

joe

34,529
29
100
137

score 0 · Answer 18 · edited Nov 05 '20 at 01:47

Debug::Statements provides an easy way to insert and enable/disable print statements for debugging.

The d() function prints the name of your variable, its value, and your subroutine name. The implementation been optimized to minimize programmer keystrokes.

Here is sample code to get you started:

my $myvar = 'some value';
my @list = ('zero', 1, 'two', "3");
my %hash = ('one' => 2, 'three' => 4);

use Debug::Statements;
my $d = 1;
d "Hello, World!";
d '$myvar';
d '@list %hash';

Output:

DEBUG sub mysub:  Hello, World!
DEBUG sub mysub:  $myvar = 'some value'
DEBUG sub mysub:  @list = [
  'zero',
  1,
  'two',
  '3'
]
DEBUG sub mysub:  %hash = {
  'one' => 2,
  'three' => 4
}

Many options are available to customize the output. Full documentation can be found on CPAN.

What are some good Perl debugging methods?

18 Answers18

Linked