CODEWITHSUNDEEP
perldebuggingtestingcgi
Stefan Majewsky
Stefan Majewsky

Reputation: 5555

Is there a debugging tool like Firebug for server-side Perl/CGI?

I really enjoy using Firebug for debugging my JavaScript code, HTML DOM, and network loading, that is: everything client-side about web development.

The situation is not so bright on the server side. The application which I'm working on uses Perl with the obligatory standard modules like CGI and DBI. I know the standard troubleshooting techniques, but there seems to be no debugging tool that traces e.g. database queries or function calls and gives me nice output.

The output must especially not just be yanked on STDOUT (imagine Content-Type: application/json) or STDERR (grepping through error logs is quite uncomfortable), and the tool should not require me to manually monkey-patch stuff into core modules or sprinkle use Data::Dumper; print '<pre>',Dumper($foo),'</pre>' through-out the code.

Long story short: Is there a tool that makes debugging the server-side of Perl/CGI as fun as Firebug does on the client-side?

Upvotes: 2

Views: 834

Answers (3)

Lee Goddard
Lee Goddard

Reputation: 11173

In addition to the above, check Devel::LTrace, which can tell you when named subroutines are called, and Devel::CallTrace, which can tell what you what subroutines are called when and where.

Upvotes: 1

Schwern
Schwern

Reputation: 164929

Yes there are, but they rely on Plack. Plack is a layer which sits between web frameworks and web servers. Plack smooths over server differences and offers a place to plug in all sorts of debugging tools. These include database profile and trace information, and you can write your own debugging panels. There is also an interactive debugger, though I haven't used it myself.

Many Perl web frameworks these days (Catalyst and Dancer for example) use Plack, but if you're using straight Perl and CGI you're not going to get it. Fortunately, it's pretty easy to make a CGI application run on Plack. Either replace CGI with a subclass that uses Plack, or wrap your CGI code in an emulation layer.

Converting to Plack has a lot of advantages beyond the debugging tools, it's well worth the effort.

Upvotes: 7

amon
amon

Reputation: 57640

No, not really.

Things you can do are:

Sprinkle your code with debug code.

use constant DEBUG => 1;
...;
debug_function($var) if DEBUG;

Once you unset the DEBUG constant for deployment, you won't have any extra runtime costs (the statements are optimized away), and you can re-activate them whenever neccessary.

You can even say evil things like

BEGIN {require Data::Dumper if DEBUG}

to conditionally load debugging modules.

If you want to override Core functions, why not add debug handlers? That's not evil patching, thats augmenting…

BEGIN {
   if (DEBUG) {
      my $oldfunction = \&CORE::function;
      *CORE::function = sub {  # add prototypes if you like them
         debug_handler(@_);
         &$oldfunction;
      };
   }
}

Use this technique to log your calls to your database.

You can re-open STDERR to some special file (or pipe, or terminal, or…)

BEGIN {
   if (DEBUG) {
      close STDERR or die "STDERR hates me and doesn't want to be closed.";
      open STDERR, '>', "/path/to/my/error/log.file" or die "couldn't open error log";
   }
}

You can define your DIE and WARN handlers to do something you want:

$SIG{__WARN__} = sub {
    print MYERRORS "There was a warning: $!";
    # do additional error handling unless you're paranoid
}

The warnings pragma can help you to make important warnings fatal:

use warnings qw(FATAL importantWarning);

or to create your own warnings, just see the documentation

And to get call stack traces, look into the numerous possibilities of the caller function. Essentially, you might want to build your personal interpretation of the Carp module as CGI::Carp may not meet your needs.

Upvotes: 6

Related Questions