Switch to viewing a different file or <A HREF="../../lib/Pod/perlfunc.html#item_eval"><CODE>eval</CODE></A> statement. If <EM>filename</EM>
is not a full pathname found in the values of %INC, it is considered
a regex.
<P><A HREF="../../lib/Pod/perlfunc.html#item_eval"><CODE>eval</CODE></A>ed strings (when accessible) are considered to be filenames:
<CODE>f (eval 7)</CODE> and <CODE>f eval 7\b</CODE> access the body of the 7th <A HREF="../../lib/Pod/perlfunc.html#item_eval"><CODE>eval</CODE></A>ed string
(in the order of execution). The bodies of the currently executed <A HREF="../../lib/Pod/perlfunc.html#item_eval"><CODE>eval</CODE></A>
and of <A HREF="../../lib/Pod/perlfunc.html#item_eval"><CODE>eval</CODE></A>ed strings that define subroutines are saved and thus
Same as <A HREF="#item_%7Cdbcmd"><CODE>|dbcmd</CODE></A> but DB::OUT is temporarily <A HREF="../../lib/Pod/perlfunc.html#item_select"><CODE>select</CODE></A>ed as well.
Affects the printing of messages upon entry and exit from subroutines. If
<A HREF="#item_frame"><CODE>frame & 2</CODE></A> is false, messages are printed on entry only. (Printing
on exit might be useful if interspersed with other messages.)
<P>If <A HREF="#item_frame"><CODE>frame & 4</CODE></A>, arguments to functions are printed, plus context
and caller info. If <A HREF="#item_frame"><CODE>frame & 8</CODE></A>, overloaded <CODE>stringify</CODE> and
<A HREF="../../lib/Pod/perlfunc.html#item_tie"><CODE>tie</CODE></A>d <CODE>FETCH</CODE> is enabled on the printed arguments. If <A HREF="#item_frame"><CODE>frame
& 16</CODE></A>, the return value from the subroutine is printed.</P>
<P>The length at which the argument list is truncated is governed by the
Here's an example of what a stack backtrace via <A HREF="#item_T"><CODE>T</CODE></A> command might
look like:
<PRE>
$ = 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</PRE>
<P>The left-hand character up there indicates the context in which the
function was called, with <CODE>$</CODE> and <CODE>@</CODE> meaning scalar or list
contexts respectively, and <A HREF="#item_%2E"><CODE>.</CODE></A> meaning void context (which is
actually a sort of scalar context). The display above says
that you were in the function <CODE>main::infested</CODE> when you ran the
stack dump, and that it was called in scalar context from line
10 of the file <EM>Ambulation.pm</EM>, but without any arguments at all,
meaning it was called as <CODE>&infested</CODE>. The next stack frame shows
that the function <CODE>Ambulation::legs</CODE> was called in list context
from the <EM>camel_flea</EM> file with four arguments. The last stack
frame shows that <CODE>main::pests</CODE> was called in scalar context,
also from <EM>camel_flea</EM>, but from line 4.</P>
<P>If you execute the <A HREF="#item_T"><CODE>T</CODE></A> command from inside an active <A HREF="../../lib/Pod/perlfunc.html#item_use"><CODE>use</CODE></A>
statement, the backtrace will contain both a <A HREF="../../lib/Pod/perlfunc.html#item_require"><CODE>require</CODE></A> frame and
an <A HREF="../../lib/Pod/perlfunc.html#item_eval"><CODE>eval</CODE></A>) frame.</P>
<P>If you have compile-time executable statements (such as code within
BEGIN and CHECK blocks or <A HREF="../../lib/Pod/perlfunc.html#item_use"><CODE>use</CODE></A> statements), these will <EM>not</EM> be
stopped by debugger, although <A HREF="../../lib/Pod/perlfunc.html#item_require"><CODE>require</CODE></A>s and INIT blocks will, and
compile-time statements can be traced with <A HREF="#item_AutoTrace"><CODE>AutoTrace</CODE></A> option set
in <CODE>PERLDB_OPTS</CODE>). 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:</P>
<PRE>
$DB::single = 1;</PRE>
<P>If you set <CODE>$DB::single</CODE> to 2, it's equivalent to having
just typed the <CODE>n</CODE> command, whereas a value of 1 means the <A HREF="../../lib/Pod/perlfunc.html#item_s"><CODE>s</CODE></A>
command. The <CODE>$DB::trace</CODE> variable should be set to 1 to simulate
having typed the <A HREF="#item_t"><CODE>t</CODE></A> command.</P>
<P>Another way to debug compile-time code is to start the debugger, set a
breakpoint on the <EM>load</EM> of some module:</P>
<PRE>
DB<7> b load f:/perllib/lib/Carp.pm
Will stop on load of `f:/perllib/lib/Carp.pm'.</PRE>
<P>and then restart the debugger using the <A HREF="#item_R"><CODE>R</CODE></A> command (if possible). One can use <A HREF="#item_b_compile_subname"><CODE>b
compile subname</CODE></A> for the same purpose.</P>
<P>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 <A HREF="../../lib/Pod/perldebguts.html#debugging perl memory usage">Debugging Perl memory usage in the perldebguts manpage</A> for the details.</P>
<P>
<HR>
<H1><A NAME="see also">SEE ALSO</A></H1>
<P>You did try the <STRONG>-w</STRONG> switch, didn't you?</P>
<P>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.</P>
<P>If you alter your @_ arguments in a subroutine (such as with <A HREF="../../lib/Pod/perlfunc.html#item_shift"><CODE>shift</CODE></A>
or <A HREF="../../lib/Pod/perlfunc.html#item_pop"><CODE>pop</CODE></A>, the stack backtrace will not show the original values.</P>
<P>The debugger does not currently work in conjunction with the <STRONG>-W</STRONG>
command-line switch, because it itself is not free of warnings.</P>
<P>If you're in a slow syscall (like <A HREF="../../lib/Pod/perlfunc.html#item_wait"><CODE>wait</CODE></A>ing, <A HREF="../../lib/Pod/perlfunc.html#item_accept"><CODE>accept</CODE></A>ing, or <A HREF="../../lib/Pod/perlfunc.html#item_read"><CODE>read</CODE></A>ing
from your keyboard or a socket) and haven't set up your own <CODE>$SIG{INT}</CODE>
handler, then you won't be able to CTRL-C your way back to the debugger,
because the debugger's own <CODE>$SIG{INT}</CODE> handler doesn't understand that
it needs to raise an exception to <CODE>longjmp(3)</CODE> out of slow syscalls.</P>
