Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number

Re: Debugging a program

by hexcoder (Deacon)
on Aug 06, 2008 at 16:42 UTC ( #702678=note: print w/replies, xml ) Need Help??

in reply to Debugging a program

Here is my debugger tip.

When I do rapid prototyping, I often want the debugger to stop whenever a warning is issued from the Perl interpreter (for example about an undefined scalar). The warning contains a line number which is fine, but when executed in a loop, this is not enough. I need the current context. Only then I can examine the state of the program in the context that produced the problem.

So what to do? In the program I replace the signal handler for SIGWARN with my own handler that checks for the typical format of a Perl warning. I do that because I am interested only in warnings from the Perl interpreter. If this format has been detected, the code branches into a special path where I can set a breakpoint. After that the warning message is printed as before the modification.

Update: thanks to perrin the breakpoint setting is not necessary anymore. Also the BEGIN block can be shifted in the .perldb initialization file (see Re^3: Debugging a program), so the original file remains unchanged.


use strict; use warnings; BEGIN { $SIG{__WARN__} = sub { my $warning = shift; if ( $warning =~ m{\s at \s \S+ \s line \s \d+ \. $}xms ) { $DB::single = 1; # debugger stops here automatically } warn $warning; }; return; } my $undefined_scalar; print "Scalar has this value: $undefined_scalar, \n"; print "end\n";
When I run the program under the debugger, it stops in the signal handler when the commented line is reached. I give the (r) command to return to the calling subroutine and investigate the context.

Replies are listed 'Best First'.
Re^2: Debugging a program
by perrin (Chancellor) on Aug 06, 2008 at 16:52 UTC
    You could just run your code in the debugger and do this when you find a warning you want to stop on:
    $DB::single = 1;
      Thanks, that saves the action of setting a breakpoint.

      But even better, I could shift the signal handler code into the debugger initialization file .perldb. Then I do not have to modify the original source code. Works great!

      This is the content of file .perldb (place it in the current or in the home directory):

      sub afterinit { $::SIG{'__WARN__'} = sub { my $warning = shift; if ( $warning =~ m{\s at \s \S+ \s line \s \d+ \. $}xms ) { $DB::single = 1; # debugger stops here automatically } warn $warning; }; print "sigwarn handler installed!\n"; return; }
        ... and under Windows save it to file perldb.ini in your %HOMEDRIVE%%HOMEPATH% directory.

        Then make sure to set the file attributes to read-only. That way it is safe and the debugger is happy.

Re^2: Debugging a program
by Anonymous Monk on Mar 20, 2009 at 14:09 UTC
    This is exactly what I've been looking for. Great tip.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://702678]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (5)
As of 2019-05-22 16:37 GMT
Find Nodes?
    Voting Booth?
    Do you enjoy 3D movies?

    Results (140 votes). Check out past polls.

    • (Sep 10, 2018 at 22:53 UTC) Welcome new users!