Debugger: Unable to connect to remote host

imperfecttommy wrote on Sun Oct  7 17:26:28 MEST 2007:

I am running:

Eclipse SDK 3.3.1
Active Perl 5.8.8
EPIC 0.6.16
PadWalker 0.10
Windows XP

I can run Perl scripts successfully, but not debug. When I try to debug,
I see:

Unable to connect to remote host: 10.10.1.170:5000
Compilation failed in require.
 at C:/cvs/db_admin/db_admin/create_locales.pl line 0
	main::BEGIN() called at C:/cvs/db_admin/.metadata/.plugins/org.epic.debug/perl5db.pl
line 0
	eval {...} called at C:/cvs/db_admin/.metadata/.plugins/org.epic.debug/perl5db.pl
line 0
BEGIN failed--compilation aborted.
 at C:/cvs/db_admin/db_admin/create_locales.pl line 0

Then, I see a dialog box with the text, "Timed out while waiting for Perl
debugger connection."

Anyone know what is happening?

Thanks in advance!

jploski wrote on Sun Oct  7 17:33:59 MEST 2007:

EPIC starts listening on port 5000, then starts the Perl interpreter which
tries to connect to that port. In your case, it doesn't work - maybe a firewall
issue? Or maybe you have multiple IP addresses and the one being listened
on is different from the one Perl tries to connect to (you could find out
with netstat).

imperfecttommy wrote on Sun Oct  7 18:09:09 MEST 2007:

Thanks for the insights - it helps.

There is no firewall. (I'm a Windows network programmer, so hopefully I
know this.) Cywin's netstat does not reveal any port that looks like it
should be associated with EPIC, either.

Perhaps EPIC could not create the socket or the port number bound is not
5000? Are there any Eclipse error logs which might give me more clues? (I
am new to Eclipse and EPIC.)

Looking through Perl5db.pl, I see RemotePort is the method to set the port,
but it is not clear from where this is called. In all the plug-ins, it's
only referenced in Perl5db.pl. So, I assume it's called directly from Eclipse.
Is it possible you have to set the port and host somewhere in the UI?

jploski wrote on Sun Oct  7 18:22:30 MEST 2007:

The error log is in workspace/.metadata/.log. Unfortunately, I see that
the old code responsible for creating ServerSockets in RemotePort.java is
masking exceptions instead of logging them. The port numbers are not set
in the UI, the 5000 is hardcoded. The Perl interpreter is invoked by Runtime.exec
(with the -d option) and the port information is passed down in the environment
variable PERLDB_OPTS. I wonder why you use Cygwin's netstat when there is
also a native version in Windows.

If you wish to resolve the problem for yourself, http://e-p-i-c.sf.net/devguide/devguide.html
contains instructions on setting up a development environment for troubleshooting
EPIC.

imperfecttommy wrote on Mon Oct  8 01:33:25 MEST 2007:

It works under Mac OS X and under Ubuntu Linux for me, but not Windows.
Since my dual monitor setup is on the Windows box, I wanted to develop there.

I tried the "Hacking EPIC in 15 Minutes" instructions and after step 7 (Choose
Project->Clean) a subsequent build revealed 147 errors and 586 warnings.
Perhaps j2sdk 1.4.2 is not the right version? Most of the errors appear
to be configuration issues, e.g. assert cannot be resolved to a type & duplicate
local variable attributes, but I'm not a Java programmer and it looks like
more effort than I want to put in. However, if you know of any quick fixes
to get the development environment working, I'll give it another try. (I'd
really like to work on my Windows box, if possible.) For now, though, I'll
just work on my Linux box.

Thanks again for the help, it is appreciated.

jploski wrote on Mon Oct  8 08:33:13 MEST 2007:

Seems like you either skipped the step "3. Set the default compiler compliance
level to 1.4, both for the source code and for class files (Window->Preferences...,
then Java->Compiler)." or it did not have the expected effect. Set it higher
if 1.4 is not enough. Note that one can also define compiler compliance
at the individual project level - if it is defined there then it overrides
the global workbench setting. So make sure that the Java projects have "use
workbench defaults" in their properties.

imperfecttommy wrote on Mon Oct  8 17:19:05 MEST 2007:

Thanks for the tip. The problem was that the compliance level was set to
1.4 (as the the instructions said), but setting it higher (5.0 or 6.) did
remove the error messages (though the number of warnings went to 1,436 at
either level).

I'll have to read the docs and figure out why my break point in startDebugTarget()
is not working and then I should be able to figure out why the debugger
fails on my PC. I appreciate all the help, I'm a bit more comfortable with
Eclipse than I was and I'm looking forward to debugging Perl with an IDE.

Thanks again!

jploski wrote on Mon Oct  8 19:38:00 MEST 2007:

If breakpoints you set in EPIC code seem to be ignored altogether (not just
the one you mention; a good test is to set a breakpoint in PerlDebugPlugin.start
and then launch some Perl script in the hosted workbench), then it might
be caused by the hosted workbench picking up code from the platform (where
the original version of EPIC is installed) instead of from the workspace
(to where you have imported the source code). Should this be the case, you
can edit the launch configuration and specify in one tab which plugins the
hosted workbench should be started with, as well as where they come from
(workspace vs. platform).