view release on metacpan or  search on metacpan

lib/POD2/RU/perldebug.pod  view on Meta::CPAN

Here's an example of what a stack backtrace via C<T> command might
look like:

    $ = main::infested called from file 'Ambulation.pm' line 10
    @ = Ambulation::legs(1, 2, 3, 4) called from file 'camel_flea' line 7
    $ = main::pests('bactrian', 4) called from file 'camel_flea' line 4

The left-hand character up there indicates the context in which the
function was called, with C<$> and C<@> meaning scalar or list
contexts respectively, and C<.> meaning void context (which is
actually a sort of scalar context).  The display above says
that you were in the function C<main::infested> when you ran the
stack dump, and that it was called in scalar context from line
10 of the file I<Ambulation.pm>, but without any arguments at all,
meaning it was called as C<&infested>.  The next stack frame shows
that the function C<Ambulation::legs> was called in list context
from the I<camel_flea> file with four arguments.  The last stack
frame shows that C<main::pests> was called in scalar context,
also from I<camel_flea>, but from line 4.

If you execute the C<T> command from inside an active C<use>
statement, the backtrace will contain both a C<require> frame and
an C<eval> frame.

=item Line Listing Format

This shows the sorts of output the C<l> command can produce:

    DB<<13>> l
  101:                @i{@i} = ();
  102:b               @isa{@i,$pack} = ()
  103                     if(exists $i{$prevpack} || exists $isa{$pack});
  104             }
  105
  106             next
  107==>              if(exists $isa{$pack});
  108
  109:a           if ($extra-- > 0) {
  110:                %isa = ($pack,1);

Breakable lines are marked with C<:>.  Lines with breakpoints are
marked by C<b> and those with actions by C<a>.  The line that's
about to be executed is marked by C<< ==> >>.

Please be aware that code in debugger listings may not look the same
as your original source code.  Line directives and external source
filters can alter the code before Perl sees it, causing code to move
from its original positions or take on entirely different forms.

=item Frame listing

When the C<frame> option is set, the debugger would print entered (and
optionally exited) subroutines in different styles.  See L<perldebguts>
for incredibly long examples of these.

=back

=head2 Debugging Compile-Time Statements

If you have compile-time executable statements (such as code within
BEGIN, UNITCHECK and CHECK blocks or C<use> statements), these will
I<not> be stopped by debugger, although C<require>s and INIT blocks
will, and compile-time statements can be traced with the C<AutoTrace>
option set in C<PERLDB_OPTS>).  From your own Perl code, however, you
can transfer control back to the debugger using the following
statement, which is harmless if the debugger is not running:

    $DB::single = 1;

If you set C<$DB::single> to 2, it's equivalent to having
just typed the C<n> command, whereas a value of 1 means the C<s>
command.  The C<$DB::trace>  variable should be set to 1 to simulate
having typed the C<t> command.

Another way to debug compile-time code is to start the debugger, set a
breakpoint on the I<load> of some module:

    DB<7> b load f:/perllib/lib/Carp.pm
  Will stop on load of 'f:/perllib/lib/Carp.pm'.

and then restart the debugger using the C<R> command (if possible).  One can use C<b
compile subname> for the same purpose.

=head2 Debugger Customization

The debugger probably contains enough configuration hooks that you
won't ever have to modify it yourself.  You may change the behaviour
of the debugger from within the debugger using its C<o> command, from
the command line via the C<PERLDB_OPTS> environment variable, and
from customization files.

You can do some customization by setting up a F<.perldb> file, which
contains initialization code.  For instance, you could make aliases
like these (the last one is one people expect to be there):

    $DB::alias{'len'}  = 's/^len(.*)/p length($1)/';
    $DB::alias{'stop'} = 's/^stop (at|in)/b/';
    $DB::alias{'ps'}   = 's/^ps\b/p scalar /';
    $DB::alias{'quit'} = 's/^quit(\s*)/exit/';

You can change options from F<.perldb> by using calls like this one;

    parse_options("NonStop=1 LineInfo=db.out AutoTrace=1 frame=2");

The code is executed in the package C<DB>.  Note that F<.perldb> is
processed before processing C<PERLDB_OPTS>.  If F<.perldb> defines the
subroutine C<afterinit>, that function is called after debugger
initialization ends.  F<.perldb> may be contained in the current
directory, or in the home directory.  Because this file is sourced
in by Perl and may contain arbitrary commands, for security reasons,
it must be owned by the superuser or the current user, and writable
by no one but its owner.

You can mock TTY input to debugger by adding arbitrary commands to
@DB::typeahead. For example, your F<.perldb> file might contain:

    sub afterinit { push @DB::typeahead, "b 4", "b 6"; }

Which would attempt to set breakpoints on lines 4 and 6 immediately
after debugger initialization. Note that @DB::typeahead is not a supported
interface and is subject to change in future releases.