#719 Debugger: Unable to connect to remote host / multiple host addresses

[Walter]

On my new laptop the debugger works fine, until I start the VPN.
Then it tries to bind to an address which I can't use anymore when the VPN is running (the local address provided by my router).

Unable to connect to remote host: 192.168.2.56:5000
Compilation failed in require.

I see EPIC is using InetAddress.getLocalHost().getHostAddress() to find the address it should start the debugger with.
https://github.com/jploski/epic-ide/blob/stable/org.epic.debug/src/org/epic/debug/PerlDebugPlugin.java#L467

I couldn't find how to influence which address is returned by this call (at least not under Windows). The address that would work for me would be simply 127.0.0.1 or 127.0.1.1, or the IP address of the VPN interface.

I'm sure that worked before, so maybe in the past, when multiple addresses were present, java libraries raised the UnknownHostException... So, what would be necessary to make debugging possible under VPN in my case?

• check if there are multiple addresses, and in that case use 127.0.0.1 (like in the UnknownHostException case)
• add an option to start the debugger with 127.0.0.1 (i.e. bypass the InetAddress calls)
• add an option to specify which address to use
• retrieve all IP addresses and ask the user which one to use

[Jan Ploski]

Have you tried adding an entry which maps your hostname to 127.0.0.1 to the Windows hosts file?

[Walter]

yes, unfortunately that's ignored

[Jan Ploski]

Maybe the hostname changes when you connect to VPN? What does "hostname" report at command prompt before/after connecting?

[Walter]

The hostname doesn't change by starting the VPN.
I have tested that new entries added to the hosts file are working fine, except for the hostname which is always resolved differently (i.e. any hosts file entry with the hostname is ignored)

[Jan Ploski]

You can work around this issue by introducing a custom perl5db.pl which overrides the PERLDB_OPTS environment variable passed down from EPIC (e.g. replacing the ip address by 127.0.0.1).

Whenever you start EPIC in debug mode, it copies the perl5db.pl file from your local Perl installation, patches it up and copies the resulting file to $ECLIPSE_WORKSPACE/.metadata/.plugins/org.epic.debug/perl5db.pl. This version is then normally used to run the debugger. But if you copy this patched up perl5db.pl file to some other folder and then add this folder to your project's Perl Include Path (in project properties), it will take precedence, giving you full control of how the "perl -d" side of the debugging session behaves.

[Walter]

Thank you for this, with a custom perl5db.pl the EPIC debugger seems to work...
I can step into the code and over subroutines but... my breakpoints are ignored :(
Any idea why that would happen?

The PERLDB_OPTS line looks like this:
$ENV{PERLDB_OPTS} = "RemotePort=127.0.1.1:5000 DumpReused ReadLine=0 PrintRet=0";

I have is perl 5, version 32, subversion 1 (v5.32.1)

[Jan Ploski]

Do you experience the "breakpoints ignored" issue in "Hello world" or in some more complex situation.

The "breakpoint ignored" issue usually comes down to paths of files as expected by EPIC (and as set up for breakpoints when perl -d is launched) and the paths of files as reported by "perl -d" not matching (despite normalization attempts).

How Perl reports appears seems to depend on how the modules are included (e.g. use/require with absolute/relative paths or using @INC with module names). You can understand this problem better if you enable "Perl debug console (experimental)" in your debug launch configuration. Then another item will be added to the Debug view, which will enable you to see how EPIC communicates with the perl5db.pl process - what paths it sets for breakpoints in and also what paths are actually reported by Perl (while stepping through).

Also note that breakpoints in eval'ed code (i.e. string executed as code) are not supported at all.

[Walter]

Once again, thank you for the hint.

Since I am now using a custom perl5db.pl instead of the one patched by EPIC, I had to add the patch line:

{ use epic_breakpoints; ...

Now it seems the workaround is functional !

Thanks!