EPIC and Apache2/mod-perl

vetler wrote on Fri Mar 16 01:22:01 CET 2007:

Hi,

Has anyone successfully been able to debug Apache2/mod-perl modules with
EPIC?

I've been trying to hook things up, using Apache::DB and remote debugging,
combining the information from the EPIC user guide and this article about
mod-perl debugging: http://www.perl.com/pub/a/2006/02/09/debug_mod_perl.html


I have been semi-successful... I did manage to actually step through code,
but at the end I got some kind of I/O error, and now things just don't work
for some reason. Any ideas?

Getting this to work properly would be awsome. :)

vetler wrote on Fri Mar 16 01:37:50 CET 2007:

A little more info on what I've tried:

In the Apache configuration, I have something like:
PerlSetEnv PERLDB_OPTS "RemotePort=127.0.0.1:5000 DumpReused ReadLine=0"
                                                
    
  PerlFixupHandler Apache::DB
  SetHandler perl-script
  PerlResponseHandler Hello::World                                     
    


In startup.pl:
use APR::Pool ();
use Apache::DB ();
Apache::DB->init();  

In statup.pl, I also do "use lib ..." to set the path of the source for
the Hello::World module.

In my Hello::World module, I have:
sub handler {
	my $r = shift;
	
	$r->content_type('text/plain');
    print "Hello World3!\n";
  
    return Apache2::Const::OK;
}


When I trie to access http://localhost/hello-world, the debugger starts
and I can step through the code. However, the output I'm getting on the
web server is:
vetler@homer:/tmp$ dog http://localhost/hello-world
HTTP/1.1 200 OK
Date: Fri, 16 Mar 2007 00:34:20 GMT
Server: mod-xslt/1.3.8 Apache/2.0.55 (Ubuntu) mod_apreq2-20051231/2.5.7
mod_perl/2.0.2 Perl/v5.8.8
Connection: close
Content-Type: text/plain; charset=UTF-8

vetler@homer:/tmp$ 

That's it. Pretty strange. And yes, if I try without all the debugging things,
I actually do get the text printed.

The debugger spits out this message, that I don't really know what to do:
"Time out while waiting for IO redirect from the debugged process"

The apache process says:
!ENTRY org.epic.debug **Warning** 0 Mar 16, 2007 01:34:21.671
!MESSAGE Could not map remote path (eval 10) to a local path. Some breakpoints
may be ignored.


Any ideas?

jploski wrote on Fri Mar 16 20:29:16 CET 2007:

EPIC attempts to redirect STDOUT and STDERR of the debugged process while
in remote debugging mode. For this purpose, it opens a few ports on the
machine where EPIC is running and listens for a connection from the remote
debugger. I guess this is not what you want because it causes the script
not to write anything to the web server. What you would need is multiplexed
IO which goes both to the web server AND to EPIC. There might also be firewalls
problems involved (hence the "Time out" message) or maybe the redirection
simply does not work for some reason (I vaguely remember problems with using
IO::Socket in some contexts). You may be able to learn more about what is
going on by enabling the debugger console in EPIC preferences.

vetler wrote on Mon Mar 19 18:25:44 CET 2007:

Hm.... I enabled debugging and got the following:

 DB<14> .
Hello::World::handler(/home/vetler/workspace_perl/HelloWorld/Hello/World.pm:13):
13:	    my $r = shift;
  DB<14> c
print() on closed filehandle STDOUT at /home/vetler/workspace_perl/HelloWorld/Hello/World.pm
line 16.
 at /home/vetler/workspace_perl/HelloWorld/Hello/World.pm line 16
	Hello::World::handler('Apache2::RequestRec=SCALAR(0x85fab54)') called at
-e line 0
	eval {...} called at -e line 0
print() on closed filehandle STDOUT at /home/vetler/workspace_perl/HelloWorld/Hello/World.pm
line 17.
 at /home/vetler/workspace_perl/HelloWorld/Hello/World.pm line 17
	Hello::World::handler('Apache2::RequestRec=SCALAR(0x85fab54)') called at
-e line 0
	eval {...} called at -e line 0

vetler wrote on Mon Mar 19 20:09:24 CET 2007:

It works if I use $r->print() instead of just print... I'm guessing there's
a problem with redirecting STDOUT.

jploski wrote on Mon Mar 19 20:19:06 CET 2007:

If you want to have a look at the code, consult http://e-p-i-c.sf.net/devguide/devguide.html
Have a look at PerlDB.java, this is where the redirecting is done (the invocations
of redirectIO/redirectError in init).

vetler wrote on Tue Apr 24 00:46:18 MEST 2007:

Thanks ... Taken a while for me to get a chance to look more at this. ;)

So, EPIC attempts to connect to port + 1 (port configured in Perl Remote
debug setup). As far as I can tell nothing is listening to that port, so
no wonder it times out. A problem with Apache::DB, perhaps?

jploski wrote on Tue Apr 24 19:01:56 MEST 2007:

I think you got it wrong. EPIC does not connect to any port. It is the remote
debugger which connects to a port on the machine where the IDE is running.
EPIC should be listening on this port after you launch a run configuration
in debug mode.

vetler wrote on Tue Apr 24 20:52:03 MEST 2007:

Oh, right ... So, DebuggerInterface.redirectIO/Error generates Perl code
run in the debugger that attempts to connect to EPIC, right? My first guess
is that mod-perl handlers really don't want to do that, but continue writing
to mod-perl.

Perhaps IO could be multiplexed between mod-perl and EPIC somehow... But
still, doesn't explain why it won't connect at all.

jploski wrote on Tue Apr 24 21:03:20 MEST 2007:

Yes, the idea is to redirect stdout/stderr from Perl to EPIC, and the Perl
side makes the connection. You are correct that it's not appropriate for
CGIs and that multiplexing would be the best solution.

As to why it does not connect at all: it could be a firewall, or some weird
interaction of IO::Socket with mod_perl, such as the one described there:
http://www.perlmonks.org/?node_id=287237

vetler wrote on Tue Apr 24 21:14:50 MEST 2007:

Ah, thanks for the tip. I would guess it's the latter that is the problem
... Remote debugging works fine outside mod-perl.

vetler wrote on Sun Apr 29 19:59:14 MEST 2007:

The conclusion must be that if STDERR or STDIN is already redirected in
the Perl application, for meaningful purposes, you wouldn't want to redirect
them again. As the tests with mod-perl shows, this breaks the application.

An option for this would be good. A special mod-perl debugging mode would
be cooler, but I guess that's a bigger project. ;)

jploski wrote on Sun Apr 29 20:30:19 MEST 2007:

http://sourceforge.net/tracker/index.php?func=detail&aid=1709698&group_id=75859&atid=545277

jploski wrote on Mon Mar 19 20:13:03 CET 2007:

I'm afraid you are on your own with that one...