perldebug - Perl debugging
First of all, have you tried using the -w switch?
If you're new to the Perl debugger, you may prefer to read perldebtut, which is a tutorial
introduction to the debugger .
If you invoke Perl with the -d switch, your script runs under the Perl source
debugger. This works like an interactive Perl environment, prompting for debugger commands that
let you examine source code, set breakpoints, get stack backtraces, change the values of
variables, etc. This is so convenient that you often fire up the debugger all by itself just to
test out Perl constructs interactively to see what they do. For example:
In Perl, the debugger is not a separate program the way it usually is in the typical compiled
environment. Instead, the -d flag tells the compiler to insert source information into
the parse trees it's about to hand off to the interpreter. That means your code must first
compile correctly for the debugger to work on it. Then when the interpreter starts up, it
preloads a special Perl library file containing the debugger.
The program will halt right before the first run-time executable statement (but see
below regarding compile-time statements) and ask you to enter a debugger command. Contrary to
popular expectations, whenever the debugger halts and shows you a line of code, it always
displays the line it's about to execute, rather than the one it has just executed.
Any command not recognized by the debugger is directly executed (eval'd) as Perl
code in the current package. (The debugger uses the DB package for keeping its own state
information.)
For any text entered at the debugger prompt, leading and trailing whitespace is first
stripped before further processing. If a debugger command coincides with some function in your
own program, merely precede the function with something that doesn't look like a debugger
command, such as a leading ; or perhaps a +, or by wrapping it with
parentheses or braces.
As shipped, the only command-line history supplied is a simplistic one that checks for
leading exclamation points. However, if you install the Term::ReadKey and Term::ReadLine modules
from CPAN, you will have full editing capabilities much like GNU readline(3) provides.
Look for these in the modules/by-module/Term directory on CPAN. These do not support
normal vi command-line editing, however.
A rudimentary command-line completion is also available. Unfortunately, the names of lexical
variables are not available for completion.
If you have the FSF's version of emacs installed on your system, it can interact with
the Perl debugger to provide an integrated software development environment reminiscent of its
interactions with C debuggers.
Perl comes with a start file for making emacs act like a syntax-directed editor that
understands (some of) Perl's syntax. Look in the emacs directory of the Perl source
distribution.
A similar setup by Tom Christiansen for interacting with any vendor-shipped vi and the
X11 window system is also available. This works similarly to the integrated multiwindow support
that emacs provides, where the debugger drives the editor. At the time of this writing,
however, that tool's eventual location in the Perl distribution was uncertain.
Users of vi should also look into vim and gvim, the mousey and windy
version, for coloring of Perl keywords.
Note that only perl can truly parse Perl, so all such CASE tools fall somewhat short of the
mark, especially if you don't program your Perl as a C programmer might.
If you wish to supply an alternative debugger for Perl to run, just invoke your script with a
colon and a package argument given to the -d flag. The most popular alternative debuggers
for Perl is the Perl profiler. Devel::DProf is now included with the standard Perl distribution.
To profile your Perl program in the file mycode.pl, just type:
$ perl -d:DProf mycode.pl
|
|
When the script terminates the profiler will dump the profile information to a file called tmon.out.
A tool like dprofpp, also supplied with the standard Perl distribution, can be used to
interpret the information in that profile.
use re 'debug' enables you to see the gory details of how the Perl regular
expression engine works. In order to understand this typically voluminous output, one must not
only have some idea about how regular expression matching works in general, but also know how
Perl's regular expressions are internally compiled into an automaton. These matters are explored
in some detail in perldebguts/"Debugging
regular expressions".
Perl contains internal support for reporting its own memory usage, but this is a fairly
advanced concept that requires some understanding of how memory allocation works. See perldebguts/"Debugging
Perl memory usage" for the details.
You did try the -w switch, didn't you?
perldebtut, perldebguts, re, DB, Devel::DProf, dprofpp, Dumpvalue, and perlrun.
You cannot get stack frame information or in any fashion debug functions that were not
compiled by Perl, such as those from C or C++ extensions.
If you alter your @_ arguments in a subroutine (such as with shift or pop),
the stack backtrace will not show the original values.
The debugger does not currently work in conjunction with the -W command-line switch,
because it itself is not free of warnings.
If you're in a slow syscall (like waiting, accepting, or reading
from your keyboard or a socket) and haven't set up your own $SIG{INT} handler, then
you won't be able to CTRL-C your way back to the debugger, because the debugger's own $SIG{INT}
handler doesn't understand that it needs to raise an exception to longjmp(3) out of slow
syscalls.
|
