remote debugging and breakpoints

peterbrodt wrote on Thu Apr 10 14:40:36 MEST 2008:

I try to debug a remote script from an aix machine. I have transfered all
neccessary epic files to the remote machine (dumpvar_epic.pm, epic_breakpoints.pm,
autoflush_epic.pm and perl5db.pl). After I have started the debugger and
triggered the script on the remote machine a connection between the two
machines is established. The debugger stops on the first line, but if i
single step forward the current line is not highlighted although the correct
line number is displayed. Breakpoints are ignored whereas variables are
displayed correctly.

I enabled the debugger console and got the following error message:
Undefined subroutine &epic_breakpoints::add_breakpoint called at (eval 24)[/opt/local/lib/perl5/5.8.8/perl5db.pl:628]
line 11.

This is the location of our perl installation. I tried to include the epic
perl5db.pl with -i option. No effect. The module also resides in the folder
where I start my own script.

My current setup:

Eclipse 3.2 or 3.3.1 (behaviour is the same with both releases)
Perl 5.8.8
Epic_Perl 0.6.22
Windows XP
AIX 5.3
Padwalker 1.2

Any ideas?

Peter

peterbrodt wrote on Fri May 23 09:47:07 MEST 2008:

Has anyone got an idea regarding my problem. I had to switch bach to the
Active State Debugger, which really is a pitty.

Peter

jploski wrote on Sun May 25 02:07:35 MEST 2008:

Do a simple experiment on the AIX machine

perl -d -I . somescript.pl

while having a modified version of perl5db.pl in the current directory.
Does it then pick up the one from the current directory or the system-wide
one?

jploski wrote on Sun May 25 02:13:02 MEST 2008:

Another thing you might try on the AIX machine is

export PERL5DB="BEGIN { require '/path/to/EPICs/perl5db.pl'; }"
perl -d yourscript.pl

peterbrodt wrote on Wed Jul 23 12:18:15 MEST 2008:

Hi Jan,

your last suggestion did the trick. After implementing 
$ENV{PERL5DB}="BEGIN { require '/apps/harvest/epic_perl/peter/Skripte/perl5db.pl';
}";
into the start script the debugger works fine. The current line is highlighted,
all variables are displayed and breakpoints work as well.
I don't know what has changed on our machine, because I had worked with
remote debugging before without an extra require statement.

Anyway, thanks a lot for your help

peterbrodt wrote on Fri Jul 25 09:58:56 MEST 2008:

Hi Subba,

I don't quite understand your problem. I will try to explain how I can debug
Perl code with EPIC on a remote machine.
First of all our configuration

Development plattform:
Eclipse 3.3
EPIC_Perl 0.6.24
Perl 5.8.8

Remote plattform
AIX 5.3
Perl 5.8.2
Padwalker 1.2

While starting the debug process on my local machine I generate a debug
package which I than unpack and transfer to our aix machine. This I usually
perform once. After that I only transfer changed code.

On the remote machine I adapt the start script with the necessary parameters
for my perl script and with perl -d  you start the debug
dialogue.

My problem was that on our AIX machine we have got a perl installation with
perl5db.pl version 1.22 whereas the one delivered by EPIC is version 1.28.
I therefore additionally had to adapt the start script with the require
statement as suggested by Jan.
$ENV{PERLDB_OPTS}="RemotePort=:5000 DumpReused ReadLine=0";
if( ! -d "" ) {die("Target directory does not exist!")};
chdir();
$ENV{PERL5DB}="BEGIN { require '/epic_perl/peter/Skripte/perl5db.pl';
}";
system("perl -d mySrcipt.pl ");

That's it. If you have further questions you may contact me again.

Peter

msubbareddy wrote on Fri Jul 25 01:58:40 MEST 2008:

Peter,
I am inspired to use the remote debugging on seeing your post.
Mine, entire perl code resides on RedHat Linux machine and PERL 5.8.
Work station Win XP, Eclispe 3.4, EPIC 0.6.24. and I am able to access the
perl scripts from eclipse and able to advantage of EPIC for modifying and
storing back.
And then, going back to linux shell prompt for running and debugging (perl
-d).

Please, suggest the steps you followed. Meanwhile, I will also refer the
EPIC user guide.

I appreciate your response with details.
~ Subba

msubbareddy wrote on Sat Jul 26 01:02:13 MEST 2008:

Thanks Peter, for reply was helpful hint.

I was trying to start the remote debugging as per user guide steps.
But, "Debug package" *.zip file was not getting created. It is becasue,
I am accessing and working on remote files(scripts) directly. I don't have
local copy. 

Then, for testing I copied one script to local machine and was able to create
"Debug package" .zip file. 
And, then I copied that zip file over to linux box and extracted the files
to directory as specified in "Target Host Project Installation Path".
And, then started the start_epicDB.pl after activating the debug on eclipse.
Since, I dont have Padwalker on remote machine, I got the EPIC error: 
“Error displaying local variables
  Install PadWalker and restart Eclipse or disable displaying of local variables.â€

So, just ignored and proceeded and was able to complete simple script with
debug.

1. Do I need to copy all my scripts to local machine to do the remote debug?
2. Why not, it uses the Remote Systems Files based project, which I am able
to select the project and remote file in debug configuration?

And in another scenario its just got hang, when I tried existing live production
program/script which has SOAP::Lite based calls in it.
So, I have to use the kill -9 .

I really, want to make this remote debugging for existing huge scripts based
PERL project which interacts with lot of external entities (LDAP, Oracle,
ominimark process).

Please help me with any thoughts.

Regards,
~ Subba

jploski wrote on Sun Jul 27 17:16:08 MEST 2008:

There is a lot functionality in EPIC that won't work with RSE remote projects.
As of today, EPIC contains strong non-trivial assumptions that a project's
files - and the referenced module files - can be found in the local file
system. For example, the file validation is performed using the local Perl
interpreter. The paths entered in the "project include path" are assumed
to be local. During remote debugging, the local Perl interpreter is used
to look up source files by translating remote paths reported by the remote
interpreter into local ones. Breakpoints that you set on local files through
the special epic_links project are translated back to remote paths.

In short, if you want to use remote debugging in EPIC today, the best approach
would be to make sure that your local file system mirrors the remote one.
Mounting the remote file system on the OS level and playing around with
include paths may yield better results than RSE.

msubbareddy wrote on Mon Jul 28 20:47:32 MEST 2008:

Agreed, this is same case while working on remote script without having
local copies of the same and depended moudles,
when, I pressed F3 for a function lookup in the working script its to find
the .pm module for that method ends nowhere.
Since, that source of the module (.pm) is on remote machine.

In this case also, samba share might be helpful.

Thanks for your time and giving value suggstesions.

Regards,
~ Subba

peterbrodt wrote on Mon Jul 28 09:18:58 MEST 2008:

As Jan mentions you have to make sure that all scripts and modules you need
for debugging can be found by the local debugger and of course have to reside
on your remote machine as well. In our environment for example we have got
a local structure for development which looks like this:

...\myPerl\Server
...\myPerl\Common
...\myPerl\Client

In Epic I have defined an include path in projects Server and Client which
points to Common. When I than create a debug package all necessary files
from server and common are included in the zip file. As I said before I
usually create the debug package only once. After that I transfer only the
changed files.

Regarding Jan's recommendation to mount the remote file system for example
via a Samba share - that of course would only work as long as you don't
have to run any operating system specific commands, which is the case in
our environment.

Peter

jploski wrote on Mon Jul 28 18:34:52 MEST 2008:

When I mentioned the mounting of a remote file system, I had in mind making
it possible for EPIC to locate the remote system's modules during debugging
when you step into them or want to set breakpoints, not actually full-blown
work on a mounted project (this latter scenario might indeed be infeasible).