Debugger works 1st time then port in use err

forkdeath wrote on Thu Jul 26 21:06:27 MEST 2007:
I have tried both the stable and test versions but get same error when debugging
with Perl CGI.  The first time I run the debugger everything seems to work
fine, the browser executes the page and stops at the break point, etc. 
Once the page completes I am unable to run the debugger again unless I restart
eclipse.  I get a 'Could not connect to debug port!' dialog box error. 
I am really not sure the proper procedure to run the debugger again I have
tried to various relaunch options in the debug window and re-executing debug
from the eclipse tool bar.

Another question, say I have a page I need to debug but it requires http
params to be passed to it.  How do I pass these parameters.  Sorry, newbie

Thanks for any help
John Hayles

jploski wrote on Thu Jul 26 23:37:42 MEST 2007:
When debugging CGI scripts, you don't have to relaunch the debugger for
each script. Just point the browser started by the debugger to another address
and the page will be loaded withing the currently active debugging session.
Or refresh the current page (it will run in the debugger again).

If you wish to restart the debugger for some reason (like having changed
launch configuration parameters such as environment variables), the correct
procedure is to terminate the debugging session by selecting it in the Debug
view and clicking on Terminate, then start another one from the Debug...

Regarding the HTTP parameters, if your page accepts them using the GET method,
just append the parameters you need to the page's URL in the browser. On
the other hand, if they are passed via POST, you will have to write an entry
page with a form which points to the target page and submit the form in
the browser.
tom_green wrote on Fri Sep  7 10:00:39 MEST 2007:
Hello *,

I experience the same difficulties, I only can start the debugger once too.

>If you wish to restart the debugger for some reason (like having changed
launch configuration parameters such as environment >variables), the correct
procedure is to terminate the debugging session by selecting it in the Debug
view and clicking on Terminate, >then start another one from the Debug...

Following the above instructions doesn't work out unfortunately. After the
debugger has been terminated I did a netstat on the used port, in my case
5004. All I got was:

tcp6       0      0 localhost.localdo:35704 localhost.localdom:5004 TIME_WAIT

After relaunching the debugger I got "Could not connect to debug port!"
I got no other error messages apart from this. Not even on the console where
I'm running eclipse.

What irritates me too is that the "Terminate" Button, where the console
output from Eclipse is given, is still active. Clicking on it leads to no

A complete relaunch of eclipse does the job though. 

Apart from this annoyance is debugging with EPIC a great help!

forkdeath wrote on Fri Jul 27 18:15:23 MEST 2007:
Thanks for the info.  Your description is just as I would expect the debugger
to work.

I did discover why the debugger was quitting on me.  The page had a redirect
in it to another web site which caused the debugger quit functioning.  I
will go the the browser and return to the application but break point no
longer work.   If I remove the redirect the debugging session works fine.

The other issue still exists.  I am unable to restart the debugger without
restarting eclipse.  I can see in the console the debugger uses port 5004
on the 1st debugger start.  If I terminate the session by selection it in
the Debug View and clicking Terminate Eclipse appears to terminate the session.
 When I attempt to restart from the Debug dialog I get the 'Could not connect
to debug port!' error.  I see that it attempts on a different port 5005
and the console stops at starting handler: file.

2nd attempt to start debugger console data...

    Found default config file
    Server started on 5005
    LOG: 5 5005-server: main.: starting handler: cgi
    LOG: 5 5005-server: main.: starting handler: file

Thanks for any help
John Hayles
jploski wrote on Fri Jul 27 20:25:38 MEST 2007:
Redirects should not affect the debugger in any way, as long as the pages
to-be-debugged are loaded through EPIC's internal web server.

Each CGI debugging session uses several ports above 5000. You can see it
listening on these ports when you run 'netstat' in the DOS box. It would
be interesting to know whether they are released when you terminate the
session (their state should no longer be 'LISTEN' after that). It could
be that the TCP implementation under Windows keeps closed ports reserved
for a while even though nothing is listening on them any more.
emlynoregan wrote on Mon Oct  1 08:40:48 MEST 2007:
I'm having similar issues.

I have freshly installed Eclipse v3.3.1 + EPIC 0.6.15, on Windows 2003 Server.
I've got "stop at first statement" turned on.

I have a project with one cgi file, called "index.cgi":
use strict;

print "Content-type: text/html\n\n";
print "

Hello World

\n"; --- I set up a Perl CGI configuration, which points to index.cgi, and uses the external browser (I can't make the internal one work). Then I run that from the toolbar. My browser starts up (I've used both Firefox and IE6, no difference). Console output: Found default config file Server started on 5004 LOG: 5 5004-server: main.: starting handler: cgi LOG: 5 5004-server: main.: starting handler: file LOG: 4 5004-server: new connection LOG: 3 5004- Request 24 GET /ScratchWS/index.cgi HTTP/1.1 LOG: 5 5004- main.: invoking handler: cgi LOG: 5 5004- suffix=.cgi,.pl root=X:/svn/Perl url: /ScratchWS/index.cgi LOG: 5 5004- Checking for suffix: .cgi LOG: 5 5004- looking for: X:\svn\Perl\ScratchWS\index.cgi LOG: 5 5004- found: X:\svn\Perl\ScratchWS\index.cgi Debug stack: index.cgi [Perl CGI] CGI Perl Debugger Main Thread index.cgi[line: 4] Web Server CGI Process netstat -a -b (only eclipse related stuff): TCP EmlynGADev:5001 EmlynGADev:2663 ESTABLISHED 4788 [eclipse.exe] TCP EmlynGADev:5002 EmlynGADev:2664 ESTABLISHED 4788 [eclipse.exe] TCP EmlynGADev:5003 EmlynGADev:2665 ESTABLISHED 4788 [eclipse.exe] TCP EmlynGADev:5004 EmlynGADev:2666 ESTABLISHED 4416 [java.exe] TCP EmlynGADev:2667 EmlynGADev:5000 ESTABLISHED 3904 [perl.exe] TCP EmlynGADev:5000 EmlynGADev:2667 ESTABLISHED 4788 [eclipse.exe] Eclipse breaks on the first line of my file (well, line 4 in fact), and I can step-through debug. Now if I step through using F5 or F6, everything will work and I'll see the output correctly in the browser once I finish stepping through the file. I can hit refresh in the browser, and I'll be stepping through the file again, great! Also, before refreshing the browser, I can modify the source as desired, save it, and the new source will be stepped through after refresh. Awesome! However... If I hit Resume at a point where it'll run off the end of the file without hitting a breakpoint, I get a debug stack that says Web Server Main Thread CGI Process Now, I typed that in myself there, because I can't copy. If I try to do Ctrl-C on "index.cgi[Perl CGI]" in the debug window, I consistently get "Copy" did not complete normally. Please see the log for more information. null argument: which doesn't seem too healthy. At this point, I'm dead as far as debugging is concerned. I can click the "Terminate" button on "index.cgi[Perl CGI]", and it seems to mostly work (the red square greys out, java.exe stops in the process manager), but I can never click the X button to really get rid of everything from the debug display. I can run "netstat -a -b" and I get the following line related to EPIC: TCP EmlynGADev:5000 EmlynGADev:0 LISTENING 5432 [eclipse.exe] That's Eclipse (EPIC I presume) hanging on to port 5000, so that if I try to restart debugging on index.cgi from the toobar I get this on the console: Found default config file Server started on 5005 LOG: 5 5005-server: main.: starting handler: cgi LOG: 5 5005-server: main.: starting handler: file And I get the now famous message "Could not connect to debug port!". ----- Also, if I step off the end of my program using F5 or F6, as detailed above, I can restart debugging via refresh as I've said, but if I try to terminate (using the "Terminate" red square button), I get into the same trouble with hanging onto port 5000, and have to restart Eclipse. ----- Here is another scenario, that does work for me: Begin debugging, While still stepping through the program, I can click on "index.cgi [Perl CGI]" and terminate it. Then, I can press the XX button (Remove all Terminated Launches). Then, with Windows Task Manager open, I'll see "perl.exe" going nuts, taking all cpu. So I kill that. Finally, I start debugging again from the eclipse toolbar, and that works. ----- So, here's a Perl CGI debugging workaround I use, which might work for someone else who's having similar problems: - Start your debugging configuration - Step through as required. NEVER PRESS CONTINUE, unless you know a breakpoint will stop the run before the end. - If you want to prematurely abort and restart debugging, do the following: - Select " [Perl CGI]" in the debugging window - Terminate it - do "Remove all Terminated Launches" - in Windows Task Manager, kill perl.exe - in Eclipse, Restart debugging configuration (or, instead of restarting, note that this is a good place to go back to the Perl Perspective and keep coding). - If you have stepped off the end of your file, do the following: - Refresh the browser - You should find debugging has restarted If you need to use "Continue" (hey, it's useful!) try putting a stub line at the end of your file (maybe print ""), and put a breakpoint on it. Once you've done this, it's easiest to do debugging by stepping through the bit you care about, "continue"ing to the last line, stepping off the end with F6, and then pressing refresh in your browser.
jploski wrote on Mon Oct  1 22:34:16 MEST 2007:
Thanks for the elaborate description of the problem. I was able to reproduce
the invalid behavior you describe using Eclipse 3.3.0 on Linux (Eclipse
3.2/Windows worked correctly). A fix is committed to CVS, so the bug should
disappear in the next release of 'testing'.
emlynoregan wrote on Mon Oct 15 13:56:34 MEST 2007:
Just for completeness's sake, I wanted to let you know that the problem
is now resolved in my environment as of release 0.6.15 . Thanks very much,
it's a great plugin!
emlynoregan wrote on Mon Oct 15 14:01:29 MEST 2007:
no, excuse me, I mean it's fixed in 0.6.16

Note: The above is an archived snapshot of a forum thread. Use the original thread at to post comments.