Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

breakpoints with Enbugger #48

Open
CeleritasCelery opened this issue Mar 10, 2018 · 11 comments
Open

breakpoints with Enbugger #48

CeleritasCelery opened this issue Mar 10, 2018 · 11 comments

Comments

@CeleritasCelery
Copy link

I am not sure if this is a limitation of Enbugger or not but when using Enbugger to launch trepan.pl I am not able to set breakpoints. When I try to set a breakpoint I get the following message

** Line 977 of /nfs/site/home/path/to/file not known to be a trace line.
Use 'info file /nfs/site/home/path/to/file brkpts' to see breakpoints I know about

using the suggested command to see breakpoints it know will sometimes list some numbers. But trying to break on those lines has no effect. Is this an inherit limitation of launching the debugger in a running program?

@rocky
Copy link
Owner

rocky commented Mar 10, 2018

The operative part of Enbugger is this:

Transform nextstate COP* nodes to dbstate COP* nodes as appropriate

which eventually is done here

The message ** Line xx of yy not known to be a trace line. means that there isn't a COP node with the dbstate for that line.

Did you try the suggestion given in the message: using the info file command? Did it give back any line numbers?

Also, Devel::Trepan has a disassemble command if you install Devel::Trepan::Disassemble. Use disassemble to see what's up with the specific file you are interested in.

Here is an example:

$ trepan.pl trepan.pl
-- main::(/home/rocky/perl5/perlbrew/perls/perl-5.20.3/bin/trepan.pl:11 @0x14fbf58)
my $dirname = dirname(__FILE__);
set auto eval is on.
(trepanpl): disasm
Package Main
------------
    #11: my $dirname = dirname(__FILE__);
        COP (0x3766df0) dbstate 
        BINOP (0x3766e50) sassign 
            UNOP (0x14fbf00) entersub [2] 
                UNOP (0x14fbf90) null [149] 
=>                  OP (0x14fbf58) pushmark 

Note that line 11 has COP (0x3766df0) dbstate which means that you should be able to breakpoint on it. If you can't, that's a Devel::Trepan bug. However if the flag is not dbstate but I guess nextstate, then Enbugger somehow didn't work which could still be a Devel::Trepan bug if it somehow failed to enlist Enbugger's help. But if there are some COP's in the file with dbstate and some without then more likely it is either your error (in asking to break on a line for which there is no associated COP) or possibly an Enbugger misfeature, which might be fixable or not.

@CeleritasCelery
Copy link
Author

I installed Devel::Trepan::Disassemble and tried to the disassemble command from within the debugger. This is my output.

Package Main
------------
    #18: srand 1;
        COP (0x82a220) dbstate 
        UNOP (0x82a300) srand [19] 
=>          SVOP (0x631fc0) const  IV (0x84e8e0) 1 
    #19: my @vaslues = map { int rand 2 } (1..839);
        COP (0x82a170) dbstate 
        BINOP (0x82e550) aassign [26] 
            UNOP (0x82e590) null [146] 
                OP (0x82a500) pushmark 
                LOGOP (0x841c90) mapwhile [25] 
                    LISTOP (0x841c50) mapstart 
                        OP (0x82a4d0) pushmark 
                        UNOP (0x841cd0) null 
                            UNOP (0x841c10) null 
                                LISTOP (0x82a570) scope 
                                    OP (0x6b73b0) null [181] 
                                    UNOP (0x82a340) int [22] 
                                        UNOP (0x82a530) rand [21] 
                                            SVOP (0x82a280) const  IV (0x84e988) 2 
                        UNOP (0x841bd0) rv2av 
                            SVOP (0x82a710) const  AV (0x855e48) 
            UNOP (0x841b90) null [146] 
                OP (0x82e5d0) pushmark 
                OP (0x6b7710) padav [20] 
    #20: my $pads = '0' x 15;
        COP (0x720840) dbstate 
        BINOP (0x6be600) sassign 
            BINOP (0x6b7410) repeat [28] 
                SVOP (0x631aa0) const  PV (0x85c858) "0" 
                SVOP (0x82e510) const  IV (0x85c840) 15 
            OP (0x6b74d0) padsv [27] 
    #21: my $dataschain = join q{}, @values;
        COP (0x70e120) dbstate 
        BINOP (0x70e0e0) sassign 
            LISTOP (0x633dd0) join [30] 
                OP (0x633e10) pushmark 
                SVOP (0x841d10) const  PV (0x85c8d0) "" 
                OP (0x633da0) padav [2] 
            OP (0x841d50) padsv [29] 

I am stopped on line 18. As can be seen, all the following lines have the COP dbstate. But I still can't break on them. When I try I get the same message ** Line 20 of /nfs/site/home/scripts/perl_test.pl not known to be a trace line. Forcing the breakpoint has no effect.

@rocky
Copy link
Owner

rocky commented Mar 11, 2018

Hmm....

If you issue repeated "step"s do you get to line 20? Also try issuing a set trace print followed by continue.

The first command, "set", will cause trepan.pl to show all the lines that it sees as it runs. And of course continue continues execution. I am guessing that these two methods will agree. If you see 20 in stepping, you'll see 20 in the "set trace print"; and if not , then not. But just to be sure....

Also, does the stock perl debugger have the same problem?

If you create a very simple test case that I can use to replicate the problem on my end, I'll look into this. If you go that route I think I'd need to know what version of Perl you are using.

BTW

my @vaslues = map { int rand 2 } (1..839);

I suspect is in error. You many mean @values since that is what seems to be used in line 21 (which use strict might have have caught).

@CeleritasCelery
Copy link
Author

Interestingly, I can get breakpoints to work by issuing the command set trace print. I modified the script to make it clearer for debugging purposes here.

Trepan.pl will ignore the the breakpoint if I do the following steps.

  1. break 20 (or any line number)
  2. answer y to the set breakpoint anyways? query
  3. continue

It will go to the breakpoint if I do the following steps.

  1. break 20
  2. answer y to the set breakpoint anyways? query
  3. set trace print
  4. continue

I am not sure why using set trace print is making the difference. It's like a heisenbug.

Also, does the stock perl debugger have the same problem?

no the stock perl debugger works fine with breakpoints and Enbugger.

@rocky
Copy link
Owner

rocky commented Mar 12, 2018

Ok. I'm convinced this is a Devel::Trepan bug. Now there is just the problem of being able to reproduce the behavior. The gist seems to suggest you were using 5.14.1 (which is way old and I had trouble installing that from CPAN as it is too old for many of the libraries). However after doing that, I did run perl on that gist Perl program and worked for me.

Was there something you need to do other than run just a simple perl *gist-program* that you did?

@CeleritasCelery
Copy link
Author

Was there something you need to do than run just a simple perl gist-program that you did?

I ran *gist-program* directly as an executable.

The gist seems to suggest you were using 5.14.1 which is way old

Yes, unfortunately our development stack is all built on Perl 5.14.1. I don't have the libraries to try running this script with a more recent version of Perl.

@rocky
Copy link
Owner

rocky commented Mar 12, 2018

Still, I'm not able to reproduce this problem.

$  tmp/bug.pl
Subroutine run redefined at /home/rocky/perl5/perlbrew/perls/perl-5.14.1/lib/site_perl/5.14.1/Devel/Trepan/CmdProcessor/Command/Shell.pm line 85.
** Call stack depth recorded in DB module is short. We've adjusted it.
:o main::(/tmp/bug.pl:19 @0x559866da48d0)
srand 1;
(trepanpl): b 20
Breakpoint 1 set in /tmp/bug.pl at line 20
(trepanpl): list
/tmp/bug.pl [15-24]
-------------------
 15    	
 16    	#!/home/rocky/perl5/perlbrew/perls/perl-5.14.1/bin/perl
 17    	Enbugger->stop;
 18    	
 19  ->	srand 1;
 20 B01	my @values = (1, 2, 3, 4 ,5);
 21    	my $pad = '0' x 15;
 22    	my $datachain = join q{}, @values;
 23    	my $flush = '0' x (length($pad) + length($datachain));
 24    	
(trepanpl): c
xx main::(/tmp/bug.pl:20 @0x559866ec6350)
my @values = (1, 2, 3, 4 ,5);
(trepanpl): 

If you are up for it though, Uncomment this line https://github.com/rocky/Perl-Devel-Trepan/blob/master/lib/Devel/Trepan/DB.pm#L130 which is a poor-man's "set trace print" and see if your line appears there with the sequence of commands that fails.

I am guessing it will not.

Here's a partial explanation of why "set trace print" works. It is setting Perl to step the program rather than continue to the next breakpoint. When the debugger hook is entered via stepping realizes this is a line it needs breakpoint handling.

@CeleritasCelery
Copy link
Author

I uncommented that line and I can see the print statements in the debugger output. However as you suspected it does not print out the line with the breakpoint on it.

Command: ~/scripts/perl_test.pl
++++ main /nfs/site/home/tjhinckl/scripts/perl_test.pl, 18
** Call stack depth recorded in DB module is short. We've adjusted it.
:o main::(/nfs/site/home/tjhinckl/scripts/perl_test.pl:18 @0x631780)
srand 1;
(trepanpl): break 20
** Line 20 of /nfs/site/home/tjhinckl/scripts/perl_test.pl not known to be a trace line
Use 'info file /nfs/site/home/tjhinckl/scripts/perl_test.pl brkpts' to see breakpoints I know about
Set breakpoint anyway? (N/y) y
Breakpoint 1 set in /nfs/sc/disks/sdg74_1185/tjhinckl/personal/custom/dotfiles/scripts/perl_test.pl at line 20
(trepanpl): list
/nfs/sc/disks/sdg74_1185/tjhinckl/personal/custom/dotfiles/scripts/perl_test.pl [14-23]
---------------------------------------------------------------------------------------
 14    	
 15    	
 16    	Enbugger->stop;
 17    	
 18  ->	srand 1;
 19    	my @values = (1, 2, 3, 4, 5);
 20 B01	my $pad = '0' x 15;
 21    	my $datachain = join q{}, @values;
 22    	my $flush = '0' x (length($pad) + length($datachain));
 23    	
(trepanpl): c
--00000000000000000000--
--00000000000000012345--
++++ Devel::Trepan::Terminated /nfs/sc/disks/sdg74_1185/tjhinckl/personal/custom/perl5/lib/perl5/Devel/Trepan/DB/../../../Devel/Trepan/Terminated.pm, 16
Debugged program terminated.  Use 'q' to quit or 'R' to restart.
----------------------------------------------------------------
(trepanpl): 

@rocky
Copy link
Owner

rocky commented Mar 13, 2018

Without being able to reproduce this problem, it is going to be difficult to fix it.

For me to try to reproduce the problem the following output is useful:

  • perl -V to how Perl was built
  • The version of Scalar::Util you are using (I have 1.48 although 1.50 is the latest)
  • The version of Devel::Trepan and Enbugger

I am curious if you build some other Perl either the same version or a different one with Perlbrew whether you would have this problem.

To finish, here are the gory details as I understand it so far. There is a discrepancy in what the underlying Perl interpreter sees as breakpoints and what Devel::Trepan sees as breakpoints. The fact that the list command shows that there is a breakpoint set on line 20 means that in the shared structure with the Perl interpreter *DB::dbline, Devel::Trepan sees the breakpoint. (It uses its own mechanism to figure get breakpoint properties other than the number is, but uses DB:dbline to determine whether there is a breakpoint and what number.) On the other hand, the Perl interpreter doesn't recognize what's set in DB:dbline to trigger a callback to the debugger. I suppose they could somehow be looking at different underlying variables. Scalar::Util is used to do some magic to treat DB::dbline as a "dual var" which allows values be accessed in either of two ways.

@CeleritasCelery
Copy link
Author

Summary of my perl5 (revision 5 version 14 subversion 1) configuration:
   
  Platform:
    osname=linux, osvers=2.6.32.23-0.3-default, archname=x86_64-linux
    uname='linux plxc8979 2.6.32.23-0.3-default #1 smp 2010-10-07 14:57:45 +0200 x86_64 x86_64 x86_64 gnulinux '
    config_args='-ds -e -Dprefix=/usr/intel/pkgs/perl/5.14.1 -Dprivlib=/usr/intel/pkgs/perl/5.14.1/lib64/5.14.1 -Dsitelib=/usr/intel/pkgs/perl/5.14.1/lib64/site_perl -Dotherlibdirs=/usr/intel/pkgs/perl/5.14.1/lib64/module/default -Dlibs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -Dfull_csh=/usr/intel/bin/tcsh -Dfull_sed=/usr/intel/bin/gsed -Dlocincpth=/include /include -Dloclibpth=  -Duseshrplib -Dcc=/usr/intel/pkgs/gcc/4.5.2/bin/gcc -Dccflags= -O2 -fPIC -I/usr/intel/pkgs/perl/5.14.1/include -L/usr/intel/pkgs/perl/5.14.1/lib64  -Wl,-rpath=/usr/intel/pkgs/perl/5.14.1/lib64 -Dldflags= -L/usr/intel/pkgs/perl/5.14.1/lib64 -Wl,-rpath=/usr/intel/pkgs/perl/5.14.1/lib64'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=undef, usemultiplicity=undef
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='/usr/intel/pkgs/gcc/4.5.2/bin/gcc', ccflags ='-O2 -fPIC -I/usr/intel/pkgs/perl/5.14.1/include -L/usr/intel/pkgs/perl/5.14.1/lib64 -Wl,-rpath=/usr/intel/pkgs/perl/5.14.1/lib64 -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2',
    cppflags='-O2 -fPIC -I/usr/intel/pkgs/perl/5.14.1/include -L/usr/intel/pkgs/perl/5.14.1/lib64 -Wl,-rpath=/usr/intel/pkgs/perl/5.14.1/lib64 -fno-strict-aliasing -pipe -fstack-protector'
    ccversion='', gccversion='4.5.2', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='/usr/intel/pkgs/gcc/4.5.2/bin/gcc', ldflags =' -L/usr/intel/pkgs/perl/5.14.1/lib64 -Wl,-rpath=/usr/intel/pkgs/perl/5.14.1/lib64 -fstack-protector'
    libpth=/lib/../lib64 /usr/lib/../lib64 /lib /usr/lib /usr/local/lib /lib64 /usr/lib64 /usr/local/lib64
    libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
    libc=/lib/libc-2.11.1.so, so=so, useshrplib=true, libperl=libperl.so
    gnulibc_version='2.11.1'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/intel/pkgs/perl/5.14.1/lib64/5.14.1/x86_64-linux/CORE'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/intel/pkgs/perl/5.14.1/lib64 -fstack-protector'


Characteristics of this binary (from libperl): 
  Compile-time options: PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP
                        PERL_PRESERVE_IVUV USE_64_BIT_ALL USE_64_BIT_INT
                        USE_LARGE_FILES USE_PERLIO USE_PERL_ATOF
  Built under linux
  Compiled at Nov 10 2011 10:01:27
  %ENV:
    PERL_LOCAL_LIB_ROOT="/nfs/site/home/tjhinckl/perl5"
    PERL_MB_OPT="--install_base "/nfs/site/home/tjhinckl/perl5""
    PERL_MM_OPT="INSTALL_BASE=/nfs/site/home/tjhinckl/perl5"
  @INC:
    /usr/intel/pkgs/perl/5.14.1/lib64/site_perl/x86_64-linux
    /usr/intel/pkgs/perl/5.14.1/lib64/site_perl
    /usr/intel/pkgs/perl/5.14.1/lib64/5.14.1/x86_64-linux
    /usr/intel/pkgs/perl/5.14.1/lib64/5.14.1
    /usr/intel/pkgs/perl/5.14.1/lib64/module/default/x86_64-linux
    /usr/intel/pkgs/perl/5.14.1/lib64/module/default
    .
  • Scalar::Util version : 1.23
  • Devel::Trepan version : 0.74
  • Enbugger version : 2.013

Moving to Scalar::Util 1.50 did not make a difference.

I am curious if you build some other Perl either the same version or a different one with Perlbrew whether you would have this problem.

I will give that a try. Any particular version you would recommend?

@rocky
Copy link
Owner

rocky commented Mar 13, 2018

Any particular version you would recommend?

perl-5.18.4 which is stable and close to 5.14. And I installed Devel::Trepan and Enbugger on that version without problem, and then it tested fine too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants