Apache Remote Debugging ALMOST working

bensoft wrote on Tue Nov 20 17:24:23 CET 2007:

I have had some success using EPIC remote debugging with Apache, however,
 the
debugging session mysterisouly terminates.  I am using Apache on the local
machine
pointed into my projects directory so the source files are identical.

In my apache virtual host I have set:

  SetEnv PERLDB_OPTS "RemotePort=127.0.0.1:4000 DumpReused ReadLine=0"

  (this was taken from an EPIC debug package zip)

I am using the Cygwin perl 5.8.8 and using the debug shebang. 

  #!/usr/bin/perl -d

  use CGI;

  my $q = new CGI;
  print $q->header();

  foreach my $key (sort(keys %ENV)) {
      print "$key = $ENV{$key}
\n";
  }


  my $num1=$q->param('num1');
  my $num2=$q->param('num2');
  my $sum=$num1 + $num2;

  print "$num1 + $num2 = $sum";

I can successfully debug at the command line using netcat
listening on port 4000 (line continuations added for readability)
The first three lines (printf and two require lines) are taken
from the EPIC debug startup:

  $ nc -l -p 4000

  Loading DB routines from perl5db.pl version 1.28
  Editor support available.

  Enter h or `h h' for help, or `man perldebug' for more help.

  main::(C:/projects/testcgi/add.cgi:5):
  5:      my $q = new CGI;
    DB<1> printf $DB::OUT "%vd", $^V;
  5.8.8
  DB<2> require IO::Socket; {my $OUT;$OUT = new IO::Socket::INET(Timeout
 => '10',  \
            PeerAddr => '127.0.0.1:5000',Proto    => 'tcp',); \
            STDOUT->fdopen($OUT,"w");STDIN->fdopen($OUT,"r");}
  DB<3> require IO::Socket; {my $OUT;$OUT = new IO::Socket::INET(Timeout
 => '10', \
            PeerAddr => '127.0.0.1:5001',Proto    => 'tcp',);STDERR->fdopen($OUT,"w");}
  DB<4> l
  5==>    my $q = new CGI;
  6:      print $q->header();     
  7
  8:      foreach my $key (sort(keys %ENV)) {
  9:          print "$key = $ENV{$key}
\n";
  10      }
  11
  12
  13:     my $num1=$q->param('num1');
  14:     my $num2=$q->param('num2');
    DB<4> c 13
  main::(C:/projects/testcgi/add.cgi:13):
  13:     my $num1=$q->param('num1');
    DB<5> w $num1
    DB<8> c
  Watchpoint 0:   $num1 changed:
      old value:  ''
      new value:  '1'
  main::(C:/projects/testcgi/add.cgi:14):
  14:     my $num2=$q->param('num2');
  DB<8>

The EPIC remote debug parameters are as follows:

  Project: testcgi
  File to execute: add.cgi
  Local Host IP: 127.0.0.1
  Installation path: C:/projects/testcgi
  Port: 4000
  (not creating a debug package)

I have isolated the problem to a connection failure in the EPIC
debug communication.  The EPIC debug session mysteriously quits 
issuing a 'q' after setting the sockets.

  Loading DB routines from perl5db.pl version 1.28
  Editor support available.

  Enter h or `h h' for help, or `man perldebug' for more help.

  main::(C:/projects/testcgi/add.cgi:5):
  5:	my $q = new CGI;
    DB<1> printf $DB::OUT "%vd", $^V;
  5.8.8
  DB<2> require IO::Socket; {my $OUT;$OUT = new IO::Socket::INET(Timeout
 => '10',PeerAddr => '127.0.0.1:5000',Proto    => 'tcp',);STDOUT->fdopen($OUT,"w");STDIN->fdopen($OUT,"r");}

  DB<3> require IO::Socket; {my $OUT;$OUT = new IO::Socket::INET(Timeout
 => '10',PeerAddr => '127.0.0.1:5001',Proto    => 'tcp',);STDERR->fdopen($OUT,"w");}
  q

Any ideas?
--Dave

jploski wrote on Tue Nov 20 19:01:24 CET 2007:

Have you tried unchecking "Capture Output" in the remote launch configuration
dialog in Eclipse?

bensoft wrote on Thu Nov 22 20:39:24 CET 2007:

There appears to be no difference with capture checked or unchecked.  Occasionally,
the debug process gets a little farther but I haven't been able to reliably
replicate that condition.  The final 'q' show in my original posting appears
in red.  Does this mean that the termination of the debugging session is
being initiated by EPIC?

jploski wrote on Thu Nov 22 20:50:01 CET 2007:

Regarding the lack of effect in 'capture': Are you using the latest version
of testing? I expected clearing the checkbox to eliminate the IO::Socket
lines from the debugging output.

Regarding 'q' in red, yes, it means that it's issued by EPIC. But so are
all the other commands to the debugger.

Did you check the error log (in $WORKSPACE/.metadata/.log)? It might provide
extra clues to what is going on.