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
Comments
The operative part of Enbugger is this:
which eventually is done here The message Did you try the suggestion given in the message: using the Also, Devel::Trepan has a Here is an example:
Note that line 11 has |
I installed 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 |
Hmm.... If you issue repeated "step"s do you get to line 20? Also try issuing a The first command, "set", will cause trepan.pl to show all the lines that it sees as it runs. And of course 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
I suspect is in error. You many mean |
Interestingly, I can get breakpoints to work by issuing the command
It will go to the breakpoint if I do the following steps.
I am not sure why using
no the stock perl debugger works fine with breakpoints and |
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 |
I ran
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.
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:
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 |
Moving to Scalar::Util 1.50 did not make a difference.
I will give that a try. 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?
The text was updated successfully, but these errors were encountered: