Open CeleritasCelery opened 6 years ago
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.
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.
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).
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.
break 20
(or any line number)y
to the set breakpoint anyways?
querycontinue
It will go to the breakpoint if I do the following steps.
break 20
y
to the set breakpoint anyways?
queryset trace print
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
.
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?
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.
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.
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):
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 builtI 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.
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
.
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?
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.
I am not sure if this is a limitation of
Enbugger
or not but when usingEnbugger
to launchtrepan.pl
I am not able to set breakpoints. When I try to set a breakpoint I get the following messageusing 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?