ActiveState Community
Navigation
RSS Feeds
Local "remote" perl debugging
Is it possible to do local "remote" debugging of perl CGI apps? That is, with Komodo running on the same Windows box as an IIS CGI app?
I got regular local perl debugging working with Komodo, without changing the PERL5LIB path. Then attempted to do the local "remote" thing. Followed all the instructions regarding environment variables and IIS config. But as soon as I enable -d for perl CGI in IIS, I get "page not found".
If I try a normal "perl -d script.pl" at the command line using the Komodo DB lib, it just hangs, with or without having RemotePort and/or idekey set, and with or without Komodo listening on 9000.
If I leave PERLDB_OPTS RemotePort set to 127.0.0.1:9000 and do a command line session, I can see the Total Sessions in Komodo rack up a connection, but that's about it.
All perl sessions I start when PERL5LIB points to the Komodo DB lib, either from IIS or CLI, have to be killed off in the task manager.
So as far as I can tell, nothing works with the Komodo version of the DB lib.
I'm running IIS6 and ActivePerl 5.8.7 (815).
As usual, TIA for any help!
-- hugh
- Login to post comments
If you can't get Komodo debugging working from the command-line, it won't
happen in IIS/CGI either.
Here's the procedure:
1. Start a DOS/command window
2. Set these environment variables:
set PERLDB_OPTS=RemotePort=localhost:9000 LogFile=c:\tmp\perldb.log
set PERL5DB=BEGIN { require q(C:/Progra~1/ACTIVE~2.1/lib/support/dbgp/perllib/perl5db.pl) }
set PERL5LIB=C:/Progra~1/ACTIVE~2.1/lib/support/dbgp/perllib/
I use short names to avoid spaces (disclaimer: while I normally install my applications
in a top-level directory called "c:\apps", I test Komodo in the standard c:\Program Files
dir). I also avoid using double-quotes, because the DOS shell passes them verbatim
to Perl, which then ends up looking for a directory called '"foo"' instead of 'foo'.
The LogFile part of the PERLDB_OPTS is optional, but will let you know
that the debugger is working. You could also set LogFile to stderr
or stdout, to avoid creating another file.
3. Switch to the directory containing the file foo.pl to debug.
4. perl -d foo.pl [args for foo.pl]
At this point Komodo should come to life (assuming it's listening for
debug connections on port 9000). And you should see a ton of output in
the log file. If not, you'll need to contact support.
5. Assuming (4.) worked, you'll now need to get that environment into
IIS, and repeat the debugger. For CGI, you'll definitely want the LogFile
to point to a file, not stdout or stderr.
I will try this right away!
The biggest difference I see in your instructions is the PERL5DB setting. There is no instructions for setting that in the K4 debugging help section - the doc only references PERL5LIB, PERLDB_OPTS and DBGP_IDEKEY. I did see something about that in a DOS script for switching from PDK to CLI debuggin in the Perl Dev Kit, but didn't think to try that with Komodo.
Thanks for the help.
More News When There Is News,
-- hugh
but I'm not sure if this is needed or not for IIS.
It works!!! And there was Much Rejoicing!
As soon as I added that PERL5DB to my shell environment, regular CLI debugging started working.
Took a bit of futzing around with IIS to get CGI dubgging working, mostly because I had to create another virtual hostname and virtual sever to invoke perl from with -d, as I'm working on a live server. But after a few times round the usual "google edit test" cycle, it worked from IIS as well. And yes, I had to include that PERL5DB line.
It's now working great, except for a few scripts that give me the old "The specified CGI application misbehaved by not returning a complete set of HTTP headers" ... until I debug them, then they work fine. Probably some sort of unbuffered versus buffered output problem.
Anyway, thanks a ZILLION for the help. I can't tell you how happy I am being able to debug this stuff in Komodo!
-- hugh