Debugger in 0.5.29

uhugenschmidt wrote on Thu Jan 11 23:09:08 CET 2007:

hello

Eclipse 3.2.1, Epic 0.5.29, Java 5.10, winxp

the debugger does not stop on breakpoints that are set in a module included
by the main.pl.

e.g. debug main.pl; main.pl uses some.pm; the debugger does not stop on
breakpoints set in some.pm

some.pm lives in the workspace-navigator under epic-links and on the filesystem
in the perl-compiler-installation-tree; some.pm is est readonly.

(I continue to use Epic, but with ptkdb as external tool.)
Thanks for the Conditional Breakpoints.

jploski wrote on Thu Jan 11 23:41:51 CET 2007:

Consult this thread to see what sort of information I need to fix the "breakpoints
ignored under Windows" sort of bugs:

https://sourceforge.net/forum/message.php?msg_id=4053402

uhugenschmidt wrote on Fri Jan 12 22:32:37 CET 2007:

sorry, but unfortunately the debug-session that produces the error does
not write into \.metadata\.log. (I shut down Eclipse to circumvent
an eventual cache problem.)
It too does not write into the \.metadata\.plugins\org.epic.debug\.log;
but this debug-session produced e.g. a new get_env.pl in this directory
(and dumpvar_epic.pm, autoflush_epic.pm).

I have entries in the .log-file from yesterday, they talk about communication
problems with the perl-debugger, but I cannot associate them with this debug
problem.

The setup to reproduce the problem is simple, and I could send the .pl and
.pm (< 1k) it comprehends in a separate mail. But to reproduce the error,
you would need Perl::Critic installed in the tree of your perl-installation
outside the eclipse workspace.

I have an Eclipse/Epic Workspace with a minimal script (testCritique.pl)
to test Perl::Critic, which I want to abuse to analyse an application of
several modules (~150'000 lines of perl). I have Perl::Critic installed
in my perl installation tree on windows. I have a .pm ListLibraries.pm -
a minimal subclass of  Perl::Critic::Policy. ListLibraries.pm lives also
in the workspace under .\Perl\Critic\Policy\MedocMap; it is pulled into
the testCritique.pl-script with "use lib":

use Perl::Critic;
use lib "Perl\\Critic\\Policy\\MedocMap";
use ListLibraries;

That's the setup; and in the Epic-Local-Debugger I set a breakpoint in a
package of the CPAN module Perl::Critic, let's say in Perl::Critic.pm at
line 91. And I press "Resume", the Debugger does not stop at the breakpoint,
but runs till the end.

Some times earlier, much before the debug-session, once I exeucted in an
Epic-Edit-Session the "Open Declaration"-function of the "Navigate"-menu,
Epic kindly linked the Perl::Critic.pm from it's home under the per-installation-tree
into the workspace under .\epic-links\1167832704328; not only Critic.pm
but the whole Perl::Critic-Module - a feature I appreciated very much.

Well - unfortunately no log-file, but only a lot of words.

But you could be easily able - hopefully - to reproduce the error, when
you setup in an Eclipse-Workspace a simple script, that uses a Module in
your perl-installation-tree. You bring Epic to link-in that Module into
the workspace (with "Open Declaration" while the cursor is e.g. on the "use
"-pragma). You setup a local debug-session and start the debugger.
You set a breakpoint in the a package of  and execute "Resume"
....

please let me know, how I can be of help

many thanks

jploski wrote on Fri Jan 12 22:51:30 CET 2007:

Please proceed as follows:
1. Go to EPIC Preferences and turn on the "debug console"
2. Start debugging your script, the one in which the module's breakpoints
are ignored
3. You will notice that there is a new item in the Debug view, the "perl
-d" item.
4. When you click on this item, the Console view shows the ongoing communication
between EPIC and the Perl debugger.
5. Press Resume to demonstrate that the breakpoint is ignored. The Console
view for "perl -d" will fill up with data.
6. Post the data here.

I'm afraid I cannot simply reproduce your problem on my machine because
I have no Windows. Also, I suspect it is not a general problem with EPIC
ignoring breakpoints in arbitrary modules installed as part of Perl under
Windows. If it were so, I'm pretty sure others would have also reported
this bug.

Anyway, the contents of the debug console should make it pretty clear why
breakpoints are ignored in your particular case.

uhugenschmidt wrote on Sat Jan 13 21:03:55 CET 2007:

Jan,

your advice to turn on the "debug console" brought me a step further.

Part of the PerlDB Console output:

  DB<1> printf $DB::OUT "%vd", $^V;
5.8.8
  DB<2> print $DB::OUT $^O;
MSWin32
  DB<3> f C:\P\perl\site\lib\Perl\Critic.pm
No file matching `C:\P\perl\site\lib\Perl\Critic.pm' is loaded.        
                <==
  DB<4> b load C:\P\perl\site\lib\Perl\Critic.pm
Will stop on load of `C:\P\perl\site\lib\Perl\Critic.pm'.              
                <==

PerlDB can not resolve the reference to the Module Perl::Critic as what
regards the loading and listing of the file Critic.pm in the debugger and
setting a breakpoint therein. The parser and compiler however resolve the
Module, there are no compile errors and the program runs correctly.

I repeated the steps of the Epic-Debugger as shown in the Console manually
in PerlDB in a Windows-command-shell. What PerlDB accepts is the reference
of the Module in the form 

f Perl/Critic
or
f Perl/Critic.pm

I verified the form: it has to be without quotes or double-quotes; with
slashes and NOT with backslashes (as it would be Windows like) and it has
to be relative to the lib-directory of the Perl-installation-tree. 
I tried any form of a fullPath to Critic.pm I could think of without success.

This form corresponds to the key of %INC as shown by the debugger command
"V %INC" (w/o the doublequotes). I was not able to let print $INC{Perl/Critic}
directly.

The setting of breakpoints in the Module Perl::Critic worked correctly thereafter
in my PerlDB-session (as we can assume that it will in the Epic-Debugger
too). 

In Linux (FC5) works

f Perl/Critic.pm
and
f //Perl/Critic.pm


So it should be easy to adapt based on the result of "print DB::OUT $^O".
To trap down evenutal future complaints, I have a CPAN installation of Perl
5.8.8 and not the one of ActiveState.

many thanks 

Ueli

jploski wrote on Sat Jan 13 22:42:22 CET 2007:

Thanks for the details.

I have concerns about switching from backslashes to slashes under Windows.
There has been a bug report fairly recently which got fixed by just the
opposite change:

https://sourceforge.net/forum/message.php?msg_id=4071641

I notice that the reporter's ActiveState Perl used backlashes in its messages,
but apparently other versions (?) of ActivePerl (or Windows?) use slashes.


Also, the idea of making paths relative to the "lib" directory of the Perl
installation would have to be somewhat refined. We can't simply assume that
all modules are installed there. Perhaps converting absolute paths into
paths relative to the local machine's @INC would do the trick. Maybe such
relative paths will always work with slashes - who knows?

Overall, it's a mess, as no documentation seems to exist whatsoever about
how ordinary paths must be specified for the debugger (not to mention paths
which contain funny characters or whitespace). A reliable solution should
therefore try different variants and choose the one which works, regardless
of the actual environment. Unfortunately, I don't see a way yet to figure
out what works and what doesn't because the output of "b load " does
not provide any sensible feedback.

uhugenschmidt wrote on Mon Jan 15 22:17:37 CET 2007:

I googled, poked around in ptkdb.pm, emacs cperl.el and gud.el but did not
find anything relevant until now.

It seems to be ok, to make a Module's filePath relative to the portion stored
in @INC - as far as I could test with the command-line perldb on Linux RH
FC5 Perl 5.8.8 and on WinXP, also Perl 5.8.8 (CPAN).

foo4source wrote on Thu Feb  1 19:33:28 CET 2007:

Has there been any progress on a solution to this?   I just upgraded to
escape the "Error Parsing Debugger Variables" bug, and now I can't get it
to stop on a breakpoint in an imcluded module either. 

Thanks in advance, 
Scott 

jploski wrote on Sun Feb  4 00:26:57 CET 2007:

Try 0.5.30 to see if the problem with ignored breakpoints is fixed.

foo4source wrote on Thu Feb  1 23:13:42 CET 2007:

I apologize.  I forgot to include details.   My problem is vasically the
same as Uhu's, in that the Perl debugger cannot deal with the path to my
included module.  

Specifics:  Eclipse 3.2.1_r321, Epic 0.5.29, PadWalker 1.5, Java 5.10, WinXP
SP2

The debug console shows me the following:

  DB<2> print $DB::OUT $^O;
MSWin32
  DB<3> f C:\Documents and Settings\home\workspace\BIGPERL\BIGIP.pm
No file matching `C:\Documents and Settings\home\workspace\BIGPERL\BIGIP.pm'
is loaded.    <<<<<<<
  DB<4> b load C:\Documents and Settings\home\workspace\BIGPERL\BIGIP.pm
Will stop on load of `C:\Documents and Settings\home\workspace\BIGPERL\BIGIP.pm'.
        <<<<<<<

I tried adding C:\Documents and Settings\home\Desktop\BIGPERL to my projects'
Perl Include Path (that's is where BIGIP.pm is located), but this didn't
help.

Are there any known workarounds to this?  Perhaps there is a way to programatically
force the debugger to look in the absolute path to the includes?  At http://search.cpan.org/~nwclark/perl-5.8.7/pod/perlfaq8.pod,
I found an answer to the question below, but I'm not sure that I understand
how (or whether) it should help.  In any case, adding these statements to
my .pl did not do anything, but I don't know if I added them correctly.


Q:How do I add the directory my program lives in to the module/library search
path?

A:  use FindBin;
    use lib "$FindBin::Bin";
    use your_own_modules;

I really like EPIC.  It's the absolute best Perl IDE that I have encountered.
 Period.  But, I can't really use it until I can get the debugging to show
my locally scoped variables at a breakpoint.  Please let me know if I can
help to resolve this in some way, and please accept my Thanks and Appreciation
for an excellent Perl IDE.

Sincerely, 
Scott H.

jploski wrote on Sat Feb  3 20:26:44 CET 2007:

Are you using the CygWin version of Perl or ActiveState Perl?

foo4source wrote on Sun Feb  4 06:06:18 CET 2007:

Thanks Jan, 

I am using ActiveState Perl, 5.8.4 b810.  I went back to 0.4.8 and found
that debugging works with the Yoxos distro (i.e..no "Error Parsing Debugger
Variables"), if I chose "only" the base distro and EPIC.  However, if I
downloaded the whole Callisto distro (and EPIC), the error still occured...so
I'm using the "stripped" Yoxos build for now (and I'm thoroughly enjoying
it, I might add).

If I get some time next week (since I'll be on the road), I'll try 0.5.30
and report on the skipped breakpoint issue.

Thanks again!

Take care, 
Scott H.

foo4source wrote on Tue Feb  6 05:30:54 CET 2007:

Hi Jan, 

I am currently running ActivePerl 5.8.8_b820 and EPIC_0.5.30 on Yoxos Eclipse
3.2.1_r321 with PadWalker 1.0 and Java v5.10 on WinXP_SP2.  Unfortunately,
breakpoints are still skipped.  :O(   Here is the debug console output:
___________________________________________________________________________________________________________________

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

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

main::(C:/Documents and Settings/Owner.Gateway_MX6446/workspace/BIGPERL/bigip.pl:41):
41:	my @results = qw();
  DB<1> printf $DB::OUT "%vd", $^V;
5.8.8
  DB<2> f C:/Documents and Settings/Owner.Gateway_MX6446/workspace/BIGPERL/BIGIP.pm
No file matching `C:/Documents and Settings/Owner.Gateway_MX6446/workspace/BIGPERL/BIGIP.pm'
is loaded.
  DB<3> b load C:/Documents and Settings/Owner.Gateway_MX6446/workspace/BIGPERL/BIGIP.pm
Will stop on load of `C:/Documents and Settings/Owner.Gateway_MX6446/workspace/BIGPERL/BIGIP.pm'.
  DB<4> .
main::(C:/Documents and Settings/Owner.Gateway_MX6446/workspace/BIGPERL/bigip.pl:41):
41:	my @results = qw();
  DB<5> T
  DB<6> .
main::(C:/Documents and Settings/Owner.Gateway_MX6446/workspace/BIGPERL/bigip.pl:41):
41:	my @results = qw();
  DB<7> .
main::(C:/Documents and Settings/Owner.Gateway_MX6446/workspace/BIGPERL/bigip.pl:41):
41:	my @results = qw();
  DB<8> c
Debugged program terminated.  Use q to quit or R to restart,
  use o inhibit_exit to avoid stopping after program termination,
  h q, h R or h o to get additional info.  
q
  DB<9> 

Thanks again for all your great work on this tool, 
Scott

jploski wrote on Tue Feb  6 21:21:37 CET 2007:

First of all, does the file C:/Documents and Settings/Owner.Gateway_MX6446/workspace/BIGPERL/BIGIP.pm
exist (is the path correct)?

Also, can you run the following test and post the debugger console's output
collected during it:

1. Set a breakpoint on a line in bigip.pl which invokes something from BIGIP.pm.
The debugger should stop at this breakpoint without problems.
2. Now click "Step Into". The file BIGIP.pm should open in an editor. Furthermore,
the debugger console should now show the current instruction pointer at
location like BIGIP::(C:/Documents and Settings/Owner.Gateway_MX6446/workspace/BIGPERL/BIGIP.pm:nn).
This is the output which I am interested in.

Furthermore, it would be helpful if you could replay EPIC's breakpoint setting
commands by directly invoking "perl -d C:/Documents and Settings/Owner.Gateway_MX6446/workspace/BIGPERL/bigip.pl"
(you may have to add -I options to reflect your include paths). In particular,
try the following variants of path specifications and test whether the debugger
stops upon loading BIGIP.pm in each case

C:/Documents and Settings/Owner.Gateway_MX6446/workspace/BIGPERL/BIGIP.pm
c:/Documents and Settings/Owner.Gateway_MX6446/workspace/BIGPERL/BIGIP.pm
C:\Documents and Settings\Owner.Gateway_MX6446\workspace\BIGPERL\BIGIP.pm
c:\Documents and Settings\Owner.Gateway_MX6446\workspace\BIGPERL\BIGIP.pm
BIGIP.pm

Another factor which may play a role are the blanks in "Documents and Settings".
Move your project to a simple location like "c:/workspace/BIGPERL" and see
if it changes anything.

foo4source wrote on Wed Feb  7 08:45:02 CET 2007:

Jan, 

Yes, the file C:/Documents and Settings/Owner.Gateway_MX6446/workspace/BIGPERL/BIGIP.pm
exist(ed), and its path is (was) correct. I went ahead and changed the project
to point to C:\BIGPERL (no spaces), which still skipped the breakpoint,
so I set a breakpoint in bigip.pl on line 78 and stepped into a method in
BIGIP.pm on line 534.  It appeared to successfully step into BIGIP.pm, but
threw an "error retrieving children" (there also seems to be a problem with
the PadWalker 1.0 integration). 

Here is the related debug console output: 
___________________________________________________________________________________________________________________

main::(C:/BIGPERL/bigip.pl:78):	    exit $box->errorcode();
  DB<15> s
BIGIP::errorcode(BIGIP.pm:534):	    my $self = shift;
  DB<16> .
BIGIP::errorcode(BIGIP.pm:534):	    my $self = shift;
  DB<17> .
BIGIP::errorcode(BIGIP.pm:534):	    my $self = shift;
  DB<18> T
$ = BIGIP::errorcode(ref(BIGIP)) called from file `C:/BIGPERL/bigip.pl'
line 78
  DB<19> .
BIGIP::errorcode(BIGIP.pm:534):	    my $self = shift;
  DB<20> ;{
    if (eval { require PadWalker; PadWalker->VERSION(0.08) })
    {
        do 'dumpvar_epic.pm' unless defined &dumpvar_epic::dumpvar_epic;

        defined &dumpvar_epic::dumpvar_epic
            or print $DB::OUT "dumpvar_epic.pm not available.\n";
    
        my $h = eval { PadWalker::peek_my(2) };
        my @vars = split(' ', '');
        $@ and $@ =~ s/ at .*//, print $DB::OUT ($@);
        my $savout = select($DB::OUT);
        dumpvar_epic::dumplex(
            $_,
            $h->{$_},
            defined $option{dumpDepth} ? $option{dumpDepth} : -1,
            @vars) for sort keys %$h;
        print "E";
        select($savout);
    }
    else
    {
        print $DB::OUT "PadWalker module not found - please install\n";
       
    }
};

NS00000008$NODEFMTS00000005undefNS00000008$SERVFMTS00000005undefNS0000000c%LBMethodMapS0000000e
 NS00000016%NodeAddressMonitorMapS0000000e  NS0000000d%NodeAvailMapS0000000e
 NS0000000d%NodeStateMapS0000000e  NS00000004%RGXS0000000e
 NS0000000a%StatusMapS0000000e  NS0000000d%TemplateTypeS0000000e
 E
  DB<21> ;{
    do 'dumpvar_epic.pm' unless defined &dumpvar_epic::dumpvar_epic;

    defined &dumpvar_epic::dumpvar_epic
        or print $DB::OUT "dumpvar_epic.pm not available.\n";
        
    my $savout = select($DB::OUT);
    dumpvar_epic::dumpvar_epic();
    select($savout);
};
___________________________________________________________________________________________________

If I try to directly invoke perl -d C:/BIGPERL/bigip.pl -I C:/BIGPERL/BIGIP.pm,
I get the following: 
____________________________________________________________________________________________________

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

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

Can't locate BIGIP.pm in @INC (@INC contains: . ../perlpm C:/Perl/site/lib
C:/Perl/lib) at C:\BIGPERL\bigip.pl line 39.
 at C:\BIGPERL\bigip.pl line 39
        main::BEGIN() called at BIGIP.pm line 39
        eval {...} called at BIGIP.pm line 39
BEGIN failed--compilation aborted at C:\BIGPERL\bigip.pl line 39.
 at C:\BIGPERL\bigip.pl line 39

C:\Documents and Settings\Owner.Gateway_MX6446>
_______________________________________________________________________________________________

However, any of the following commands appear to invoke the Perl debugger
correctly :

perl -d C:/BIGPERL/BIGIP.pm -I c:/BIGPERL/BIGIP.pm
perl -d C:/BIGPERL/BIGIP.pm -I C:\BIGPERL\BIGIP.pm
perl -d c:/BIGPERL/BIGIP.pm -I c:\BIGPERL\BIGIP.pm
________________________________________________________________________________________________

C:\Documents and Settings\Owner.Gateway_MX6446>perl -d C:/BIGPERL/BIGIP.pm
-I c:/BIGPERL/BIGIP.pm

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

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

BIGIP::(C:/BIGPERL/BIGIP.pm:50):        my %RGX = ( 'XIPADDR'   => '\b(25[0-5]|2
[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2
[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\b'
BIGIP::(C:/BIGPERL/BIGIP.pm:51):                  , 'XIPADDR1'  =>  '^(25[0-5]|2
[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2
[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)$'
BIGIP::(C:/BIGPERL/BIGIP.pm:52):                  , 'XIPPORT'   => '\b(25[0-5]|2
[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2
[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\:(\d{1,5})\
b'
BIGIP::(C:/BIGPERL/BIGIP.pm:53):                  , 'XIPPORT1'  =>  '^(25[0-5]|2
[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2
[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\:(\d{1,5})$
'
BIGIP::(C:/BIGPERL/BIGIP.pm:54):                  , 'XSERVICE'  =>  '^(\d{1,5})$
'
BIGIP::(C:/BIGPERL/BIGIP.pm:55):                  );

  DB<1>

Hope this helps to defray the problem.

Thanks again, 
Scott H.

jploski wrote on Wed Feb  7 22:05:51 CET 2007:

The problem lies in EPIC referring to BIGIP.pm by its full path, such as
C:/BIGPERL/BIGIP.pm, while perl -d expects it to be just "BIGIP.pm" in your
case.

Can you please add "C:/Documents and Settings/Owner.Gateway_MX6446/workspace/BIGPERL"
(or "C:/BIGPERL") to your project's include path (in Properties), then set
the breakpoint in BIGIP.pm and see if it stops? My hope is that having this
path in the @INC explicitly will force perl -d to refer to BIGIP.pm by its
full path. If this workaround works for you, I would change EPIC to always
pass the option -I 
to perl -d automatically.

foo4source wrote on Thu Feb  8 04:28:44 CET 2007:

No joy.  Oh well, we gave it a shot.   Thanks again for the help!!!

Take care, 
Scott H.