Closed p5pRT closed 2 months ago
Requesting a break point on a subroutine can actually set a break point on a different subroutine. It appears that the debugger assumes that the first executable line of a subroutine will be the line that is executed first\, but this isn't always the case:
sub problem {
$SIG{__DIE__} = sub {
die "<b problem> will set a break point here.\n";
}; # The break point _should_ be set here.
warn "This line will run even if you enter <c problem>.\n";
}
&problem;
Perhaps the debugger can skip the first executable lines if they belong to a different subroutine? Or perhaps the parse tree gives a clue to the execution order? Or perhaps the parser can insert a no-op node at the start of subs compiled for the debugger?
Thanks.
Tye McQueen writes:
Requesting a break point on a subroutine can actually set a break point on a different subroutine. It appears that the debugger assumes that the first executable line of a subroutine will be the line that is executed first\, but this isn't always the case:
sub problem \{ $SIG\{\_\_DIE\_\_\}= sub \{ die "\<b problem> will set a break point here\.\\n"; \}; \# The break point \_should\_ be set here\. warn "This line will run even if you enter \<c problem>\.\\n"; \} &problem;
Perhaps the debugger can skip the first executable lines if they belong to a different subroutine? Or perhaps the parse tree gives a clue to the execution order? Or perhaps the parser can insert a no-op node at the start of subs compiled for the debugger?
There are many other related problems.
My solution would be to put breaks on *all* the OP_DBSTATEs (sp?) which appear on a given line. Currently the break is put on the *last* DBSTATE.
This will need to keep a linked list of DBSTATEs per line number\, instead of one stored DBSTATE per line number which we have now. Any takers?
Ilya
------- Forwarded Message
Subject: Re: Perlbud ID 19991029.007: Debugger: Break gets set on wrong subroutine Date: Wed\, 13 Dec 2000 14:37:56 -0600 (CST) From: "Tye McQueen" \tye@​metronet\.com
Excerpts from the mail message of Stephen P. Potter: ) ) What should be done with this report?
I recall Ilya having some suggestions (that I don't think I understood) when I originally submitted it. I'm not very knowledgeable on the parse tree\, etc. but I think my first attempt would be to answer this question:
) Or perhaps the parse tree gives a clue to the execution order?
and if the answer is "no"\, I'd try for this:
) Or perhaps the parser can insert a ) no-op node at the start of subs compiled for the debugger?
And set it to be at the line number of the opening "{" (or even of "sub").
I'm not sure what type of input you are requesting. I take it noone has stepped up with a patch. Worst case is that it stays open as a known bug. Second worst is that it also gets documented.
If you are asking if I can work it\, then the answer is that it would fall below several things that I'm much more qualified for but that I still haven't managed to get done. Sorry. - -- Tye McQueen Nothing is obvious unless you are overlooking something http://www.metronet.com/~tye/ (scripts\, links\, nothing fancy)
------- End of Forwarded Message
This problem still exists in 5.8.3.
This problem still exists in 5.8.6 and blead@24148
imho this is DWIM Perl issue
the following shows a hacked test file with debugger symbols after a breakpoint has been set against the sub problem ( b main::problem )
if you do just a ( c ) all works as expected\, so dose ( c problem )
/home/kevin/workspace/p5p/script/db-002.pl
1 #!perl
2
3: use strict;
4: use warnings;
5
6 sub problem {
7:b $SIG{__DIE__} = sub { die "\ will set a break point
here.\n" };
8: warn "This line will run even if you enter \
11 ==> problem();
12
13: exit(0);
nb : shows traceable lines
suggest we close this ticket as it is not an issue
ps try the above and original with trepan.pl\, is't even more illuminating
imho this is DWIM Perl issue
the following shows a hacked test file with debugger symbols after a breakpoint has been set against the sub problem ( b main::problem )
if you do just a ( c ) all works as expected\, so dose ( c problem )
/home/kevin/workspace/p5p/script/db-002.pl
1 #!perl
2
3: use strict;
4: use warnings;
5
6 sub problem {
7:b $SIG{__DIE__} = sub { die "\ will set a break point
here.\n" };
8: warn "This line will run even if you enter \
11 ==> problem();
12
13: exit(0);
nb : shows traceable lines
suggest we close this ticket as it is not an issue
ps try the above and original with trepan.pl\, is't even more illuminating
On Mon Aug 26 08:13:35 2013\, bowtie wrote:
imho this is DWIM Perl issue
the following shows a hacked test file with debugger symbols after a breakpoint has been set against the sub problem ( b main::problem )
if you do just a ( c ) all works as expected\, so dose ( c problem )
/home/kevin/workspace/p5p/script/db-002.pl 1 #!perl 2
3: use strict; 4: use warnings; 5
6 sub problem { 7:b $SIG{__DIE__} = sub { die "\ will set a break point here.\n" }; 8: warn "This line will run even if you enter \.\n"; 9 } 10
11 ==> problem(); 12
13: exit(0);nb : shows traceable lines
suggest we close this ticket as it is not an issue
ps try the above and original with trepan.pl\, is't even more illuminating
You put the anonymous sub on a single line. The original report had it on three lines. This is still a bug. This script prints out the numeric and string values of each element of @dbline\, showing what is happening:
#!perl -d:Peek
sub DB::DB {}
sub problem { $SIG{__DIE__} = sub { die "foo" }; warn "bar"; }
for (@{"_\<".__FILE__}) { printf "%20u %s"\, 0+$_\, $_; print "\n" unless /\n\z/; }
The result:
0
0 use Devel::Peek
;
0
0
140432449279712 sub DB::DB {}
0
0 sub problem {
0 $SIG{__DIE__} = sub {
140432449370824 die "foo"
140432453462216 };
140432453461816 warn "bar";
0 }
0
140432453720360 for (@{"_\<".__FILE__}) {
140432453634168 printf "%20u %s"\, 0+$_\, $_;
140432453721232 print "\n" unless /\n\z/;
0 }
Notice how the %SIG assignment is breakable on the last line ‘};’. That’s because the line number for that statement is the end of the statement\, not the beginning.
The debugger scans through the line range for the problem sub. The first breakable line is in the anonymous sub.
Whether this can be fixed in perl I don’t know. I think the debugger can work around it by breaking itself in DB::sub instead of depending on pp_dbstate to do it.
--
Father Chrysostomos
You are correct. And I think you are correct that the best fix is to invoke the debugger via DB::sub()\, rather than all that hoaky code in find_subline. But doing this probably will requires some extra care. I've created Issue #24 https://github.com/rocky/Perl-Devel-Trepan/issues/24 so I don't forget about this.
(Sorry for the delayed reply.)
This is currently the oldest issue still open on GitHub.
yes its very old
older then GitHub it's self
:rofl:
I'd really like to know how to import such old projects and keep all the issues. Is it still at all possible?
The dates were retained when importing from the original issue tracker, which was not GitHub 😃
nice! :)
Yeah, but how to retain dates when importing, say, issues from GitLab to GitHub?
old
Yea ikr
On May 27, 2022 at 12:55 PM, <Flowism @.***)> wrote:
old
— Reply to this email directly, view it on GitHub (https://github.com/Perl/perl5/issues/799#issuecomment-1139943728), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AR2DTG7V645NTOY6S4JCXJ3VMELAHANCNFSM47LWVCVQ). You are receiving this because you commented.Message ID: @.***>
Can this please fixed asap? This is currently blocking us.
hi
Someone should finally fix it...
most unsolved github issue
This is basically GitHub history
Context: Someone has figured out that you can list all open tickets across all of Github with https://github.com/issues?q=is%3Aopen+is%3Aissue+archived%3Afalse+sort%3Acreated-asc, and this is the oldest one.
Migrated from rt.perl.org#1726 (status was 'open')
Searchable as RT1726$