You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Perrin Harkins <pe...@primenet.com> on 2000/12/07 20:30:36 UTC
debuggers
On Thu, 7 Dec 2000, martin langhoff wrote:
> [1] Having grown up in a cushioned, fancy VB 3.0 IDE, I still
> find both vi, emacs and textmode debug too harsh for me.
You could try ptkdb or DDD for GUI debugging.
- Perrin
Re: debuggers
Posted by Jeremy Howard <jh...@fastmail.fm>.
martin langhoff wrote:
> I wonder how do those hardcore guys that develop using handlers debug.
> Mhhh. They must write 'perlfect' code, I guess, and/or understand those
> cryptic debuggers ...
>
Actually, debugging handlers is pretty easy. Just run httpd with the -X flag
to make it single process, and use Apache::DB to get mod_perl to run under
the debugger. Get Apache::DB from CPAN
perl -MCPAN -e 'install Apache::DB'
and read its docs
perldoc Apache::DB
When Apache hits your Perl code, you are dropped into the standard Perl
debugger. Although typing '?' at the debug prompt shows a bewildering array
of options, you can do a lot by knowing:
n - Step over
s - Step into
x <expr> - Print the value of <expr>
w - Show a few lines either side of the current one
b <sub> - break at <sub>
c - continue (stop debugging)
c <line#> - continue, and break at <line#>
HTH,
Jeremy
Re: debuggers
Posted by Stas Bekman <st...@stason.org>.
On Fri, 8 Dec 2000, Bruce W. Hoylman wrote:
> >>>>> "Stas" == Stas Bekman <st...@stason.org> writes:
>
> >> Plus, I *always* use '-w' and '-T' and get them cleanly working
> >> during development phases, although I shut them off for actual
> >> deployment.
>
> Stas> 1. You cannot use -T under mod_perl, you should use
> Stas> PerlTaintCheck
> Stas> instead: http://perl.apache.org/guide/porting.html#Taint_Mode
>
> This is what I was referring to actually. However, there are many
> modules, such as Date::Manip, for example, that just will not load with
> taint checking turned on. In an intranet, it's not as big a deal as it
> certainly is in the 'real world'.
You should contact the author of the module and ask him to fix it. It's
possible that he doesn't aware of the taint issues. Usually for modules
that execute shell/fork but don't pass any tainted args, the fix is as
trivial as adding:
$ENV{'PATH'} = '/bin:/usr/bin';
delete @ENV{'IFS', 'CDPATH', 'ENV', 'BASH_ENV'};
(taken from perlsec manpage)
Hmm, may be we should find a way for modules to be taint checked before
these are allowed to CPAN? What do you think? sort of:
eval {`perl -cwT $_` for (<*.pm>) };
> But what can I do, short of rewritting the parts of the module that
> don't function in with checking on
>
> Stas> 2. 'PerlTaintCheck On' is a must in production!!! not
> Stas> development:
> Stas> * http://www.gunther.web66.com/FAQS/taintmode.html
> Stas> * perldoc perlsec
>
> Thanks for the input.
You are very welcome :)
> Peace.
Sex, drugs and rock-n-roll!
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: debuggers
Posted by "Bruce W. Hoylman" <bh...@qwest.com>.
>>>>> "Stas" == Stas Bekman <st...@stason.org> writes:
>> Plus, I *always* use '-w' and '-T' and get them cleanly working
>> during development phases, although I shut them off for actual
>> deployment.
Stas> 1. You cannot use -T under mod_perl, you should use
Stas> PerlTaintCheck
Stas> instead: http://perl.apache.org/guide/porting.html#Taint_Mode
This is what I was referring to actually. However, there are many
modules, such as Date::Manip, for example, that just will not load with
taint checking turned on. In an intranet, it's not as big a deal as it
certainly is in the 'real world'.
But what can I do, short of rewritting the parts of the module that
don't function in with checking on
Stas> 2. 'PerlTaintCheck On' is a must in production!!! not
Stas> development:
Stas> * http://www.gunther.web66.com/FAQS/taintmode.html
Stas> * perldoc perlsec
Thanks for the input.
Peace.
Re: debuggers
Posted by Stas Bekman <st...@stason.org>.
> >>>>> "SB" == Stas Bekman <st...@stason.org> writes:
>
> SB> 2. 'PerlTaintCheck On' is a must in production!!! not development:
>
> Huh?!?!?!? It is a must always. You can't develop without it and
> then expect it to work with taint checking on at a later time.
Of course, sorry for being unclear. What I meant is that if your code runs
cleanly under PerlTaintCheck On on development server, you should still
keep in 'On' in production.
If you aware of all taint issues, you may skip PerlTaintCheck on dev, but
why doing so :)
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: debuggers
Posted by Vivek Khera <kh...@kciLink.com>.
>>>>> "SB" == Stas Bekman <st...@stason.org> writes:
SB> 2. 'PerlTaintCheck On' is a must in production!!! not development:
Huh?!?!?!? It is a must always. You can't develop without it and
then expect it to work with taint checking on at a later time.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera@kciLink.com Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: debuggers
Posted by Dave Rolsky <au...@urth.org>.
On Fri, 8 Dec 2000, Matt Sergeant wrote:
> fatalsToBrowser installs a $SIG{__DIE__} handler, and so prevents you from
> properly using eval{} blocks, or nice modules like Error.pm or
> Class::Exception (or whichever way around Dave has it this week :-)
That's Exception::Class. phhhbbtt!
-dave
/*==================
www.urth.org
We await the New Sun
==================*/
Re: debuggers
Posted by Matt Sergeant <ma...@sergeant.org>.
On Fri, 8 Dec 2000, Bruce W. Hoylman wrote:
> >>>>> "Matt" == Matt Sergeant <ma...@sergeant.org> writes:
>
> Matt> On Fri, 8 Dec 2000, Bruce W. Hoylman wrote:
> >>
> >> use IO::File;
> >> use CGI::Carp qw(carpout fatalsToBrowser carp);
> Matt> Bye bye exception handling.
>
> You mean eval{} block exception handling, or something else? What are
> the technical specifics around this assertion?
fatalsToBrowser installs a $SIG{__DIE__} handler, and so prevents you from
properly using eval{} blocks, or nice modules like Error.pm or
Class::Exception (or whichever way around Dave has it this week :-)
See my rant, erm, section in the guide on exception handling.
--
<Matt/>
/|| ** Director and CTO **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
Re: debuggers
Posted by Stas Bekman <st...@stason.org>.
On Fri, 8 Dec 2000, Bruce W. Hoylman wrote:
> >>>>> "Matt" == Matt Sergeant <ma...@sergeant.org> writes:
>
> Matt> On Fri, 8 Dec 2000, Bruce W. Hoylman wrote:
> >>
> >> use IO::File;
> >> use CGI::Carp qw(carpout fatalsToBrowser carp);
> Matt> Bye bye exception handling.
>
> You mean eval{} block exception handling, or something else? What are
> the technical specifics around this assertion?
>
> Thanks! Maybe I'll learn something here, which is why I posted it in
> the first place.
http://perl.apache.org/guide/perl.html#Exception_Handling_for_mod_perl
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: debuggers
Posted by "Bruce W. Hoylman" <bh...@qwest.com>.
>>>>> "Matt" == Matt Sergeant <ma...@sergeant.org> writes:
Matt> On Fri, 8 Dec 2000, Bruce W. Hoylman wrote:
>>
>> use IO::File;
>> use CGI::Carp qw(carpout fatalsToBrowser carp);
Matt> Bye bye exception handling.
You mean eval{} block exception handling, or something else? What are
the technical specifics around this assertion?
Thanks! Maybe I'll learn something here, which is why I posted it in
the first place.
Peace.
Re: debuggers
Posted by Stas Bekman <st...@stason.org>.
> Plus, I *always* use '-w' and '-T' and get them cleanly working during
> development phases, although I shut them off for actual deployment.
1. You cannot use -T under mod_perl, you should use PerlTaintCheck
instead: http://perl.apache.org/guide/porting.html#Taint_Mode
2. 'PerlTaintCheck On' is a must in production!!! not development:
* http://www.gunther.web66.com/FAQS/taintmode.html
* perldoc perlsec
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: debuggers
Posted by Matt Sergeant <ma...@sergeant.org>.
On Fri, 8 Dec 2000, Bruce W. Hoylman wrote:
> >>>>> "Dave" == Dave Rolsky <au...@urth.org> writes:
>
> Dave> On Thu, 7 Dec 2000, martin langhoff wrote:
> >> I wonder how do those hardcore guys that develop using handlers
> >> debug. Mhhh. They must write 'perlfect' code, I guess, and/or
> >> understand those cryptic debuggers ...
>
> Dave> I just do a lot of debugging via warn statements and looking
> Dave> at the error logs.
>
> My BEGIN block looks like this. I realize IO is rather bulky, but I
> like it and the environment I'm in isn't *that* busy where it makes a
> significant impact.
>
> BEGIN {
>
> # Wash the PATH.
> $ENV{'PATH'} = '/opt/gnu/bin:/usr/local/bin:/usr/bin';
> $ENV{'CDPATH'} = '';
> $ENV{'ENV'} = '';
>
> use IO::File;
> use CGI::Carp qw(carpout fatalsToBrowser carp);
^^^^^^^^^^^^^^^
Bye bye exception handling.
--
<Matt/>
/|| ** Director and CTO **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
Re: debuggers
Posted by "Bruce W. Hoylman" <bh...@qwest.com>.
>>>>> "Dave" == Dave Rolsky <au...@urth.org> writes:
Dave> On Thu, 7 Dec 2000, martin langhoff wrote:
>> I wonder how do those hardcore guys that develop using handlers
>> debug. Mhhh. They must write 'perlfect' code, I guess, and/or
>> understand those cryptic debuggers ...
Dave> I just do a lot of debugging via warn statements and looking
Dave> at the error logs.
My BEGIN block looks like this. I realize IO is rather bulky, but I
like it and the environment I'm in isn't *that* busy where it makes a
significant impact.
BEGIN {
# Wash the PATH.
$ENV{'PATH'} = '/opt/gnu/bin:/usr/local/bin:/usr/bin';
$ENV{'CDPATH'} = '';
$ENV{'ENV'} = '';
use IO::File;
use CGI::Carp qw(carpout fatalsToBrowser carp);
use Savvy::Conf qw(:WWWBasic);
my $log = 1;
my $logfile = "/www/cgi-logs/cgi-log";
if ($log) {
my $LOG = IO::File->new(">> $logfile") or
Savvy::Conf::cab("Unable to open $logfile for writing: $!\n");
# Dupe STDERR. Original is SAVEERR.
carpout($LOG);
}
}
Then I 'tail -f' the $logfile, the Apache server error_log, and watch
watever comes to the broswer due to the fatalsToBrowser. Works well for
me.
The '$r->log_reason' finds a home in my code as well.
Plus, I *always* use '-w' and '-T' and get them cleanly working during
development phases, although I shut them off for actual deployment.
Peace.
Re: debuggers
Posted by Dave Rolsky <au...@urth.org>.
On Thu, 7 Dec 2000, martin langhoff wrote:
> I wonder how do those hardcore guys that develop using handlers debug.
> Mhhh. They must write 'perlfect' code, I guess, and/or understand those
> cryptic debuggers ...
I just do a lot of debugging via warn statements and looking at the error
logs.
-dave
/*==================
www.urth.org
We await the New Sun
==================*/
Re: debuggers
Posted by clayton cottingham <cl...@marketingchallenge.com>.
Perrin Harkins wrote:
>
> On Thu, 7 Dec 2000, martin langhoff wrote:
> > I've always considered mod_perl to be completely debugger-unfriendly.
> > That's why I write modules that I can test from a standard script, and
> > then call those modules from Embperl pages or Registry scripts.
>
> Apache::Debug works. It's almost exactly the same as debugging a standard
> script.
>
>
i got it running once on our dev box and then no go ever since then
but yes it is sweet!
> I wonder how do those hardcore guys that develop using handlers debug.
> > Mhhh. They must write 'perlfect' code, I guess, and/or understand those
> > cryptic debuggers ...
>
> Do not be afraid of the command line...
>
> The Perl debugging shell is really not so hard if you give it a chance.
> I've taught a number of people here how to use it. I'm always amazed that
> more people don't use tools like the debugger and the profiler. They're
> life savers.
>
> - Perrin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: modperl-unsubscribe@apache.org
> For additional commands, e-mail: modperl-help@apache.org
Re: debuggers
Posted by Perrin Harkins <pe...@primenet.com>.
On Thu, 7 Dec 2000, martin langhoff wrote:
> I've always considered mod_perl to be completely debugger-unfriendly.
> That's why I write modules that I can test from a standard script, and
> then call those modules from Embperl pages or Registry scripts.
Apache::Debug works. It's almost exactly the same as debugging a standard
script.
> I wonder how do those hardcore guys that develop using handlers debug.
> Mhhh. They must write 'perlfect' code, I guess, and/or understand those
> cryptic debuggers ...
Do not be afraid of the command line...
The Perl debugging shell is really not so hard if you give it a chance.
I've taught a number of people here how to use it. I'm always amazed that
more people don't use tools like the debugger and the profiler. They're
life savers.
- Perrin
Re: debuggers
Posted by Matt Sergeant <ma...@sergeant.org>.
On Thu, 7 Dec 2000, martin langhoff wrote:
> Perrin Harkins wrote:
> >
> > I don't know how easy it is to make it play with
> > mod_perl though. Apache::Debug normally just dumps you into the shell
> > debugger. Maybe setting an environment variable would do it.
> >
>
> I've always considered mod_perl to be completely debugger-unfriendly.
> That's why I write modules that I can test from a standard script, and
> then call those modules from Embperl pages or Registry scripts.
>
> I wonder how do those hardcore guys that develop using handlers debug.
> Mhhh. They must write 'perlfect' code, I guess, and/or understand those
> cryptic debuggers ...
Personally I've always relied on sending debug messages to the log, and
then staring at the code for a few minutes/months.
--
<Matt/>
/|| ** Director and CTO **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
Re: debuggers
Posted by martin langhoff <ma...@scim.net>.
Perrin Harkins wrote:
>
> I don't know how easy it is to make it play with
> mod_perl though. Apache::Debug normally just dumps you into the shell
> debugger. Maybe setting an environment variable would do it.
>
I've always considered mod_perl to be completely debugger-unfriendly.
That's why I write modules that I can test from a standard script, and
then call those modules from Embperl pages or Registry scripts.
I wonder how do those hardcore guys that develop using handlers debug.
Mhhh. They must write 'perlfect' code, I guess, and/or understand those
cryptic debuggers ...
martin
Re: debuggers
Posted by Perrin Harkins <pe...@primenet.com>.
On Thu, 7 Dec 2000, martin langhoff wrote:
> All this talk about DDD is making me wonder if there is a suitable
> (graphical) Perl IDE that I can run on Gnome.
Last time I tried them, I found ptkdb a bit nicer than DDD, mostly because
DDD was kind of slow. I don't know how easy it is to make it play with
mod_perl though. Apache::Debug normally just dumps you into the shell
debugger. Maybe setting an environment variable would do it.
- Perrin
Re: debuggers
Posted by martin langhoff <ma...@scim.net>.
Perrin,
In fact, I've always been coding from NT machines -- for my *nix
servers, of course. Now the ActiveState people are building a
cross-platform and cross-language IDE that integrates with perldebug
nicely -- or so it seems. I'm actually starting to like it -- it's built
on top of mozilla, so its a bit bloated and slow -- but I like it, just
like mozilla ;)
And, on top of that, it's called Komodo, and that means 'comfort' -- in
Spanish, that is.
All this talk about DDD is making me wonder if there is a suitable
(graphical) Perl IDE that I can run on Gnome. If there's one, maybe I'll
change my dev workstation from an NT box to RHLinux 6.1 ...
Well, there's Komodo, for instance ;)
martin
pd: of course, in Spanish you'd say cómodo -- with a stress on the first
o.