perl5
perl5 copied to clipboard
Perl
Debugger: Break gets set on wrong subroutine
From [email protected]
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.
Perl Info
Site configuration information for perl 5.00503:
Summary of my perl5 (5.0 patchlevel 5 subversion 03) configuration:
Platform:
osname=MSWin32, osvers=4.0, archname=MSWin32-x86-object
uname=''
hint=recommended, useposix=true, d_sigaction=undef
usethreads=undef useperlio=undef d_sfio=undef
Compiler:
cc='cl.exe', optimize='-Od -MD -DNDEBUG -TP -GX', gccversion=
cppflags='-DWIN32'
ccflags ='-Od -MD -DNDEBUG -TP -GX -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_OBJECT'
stdchar='char', d_stdstdio=define, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
alignbytes=8, usemymalloc=n, prototype=define
Linker and Libraries:
ld='link', ldflags ='-nologo -nodefaultlib -release -machine:x86'
libpth="g:\Apps\ActivePerl\lib\core" "G:\Apps\DevStudio\VC\LIB" "G:\Apps\DevStudio\VC\MFC\LIB" "" "D:\DevStudio\VC\LIB" "D:\DevStudio\VC\MFC\LIB"
libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib PerlCRT.lib
libc=g:\Apps\ActivePerl\lib\core\PerlCRT.lib, so=dll, useshrplib=yes, libperl=perlcore.lib
Dynamic Linking:
dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -release -machine:x86'
Locally applied patches:
ACTIVEPERL_LOCAL_PATCHES_ENTRY
@INC for perl 5.00503:
G:/Apps/ActivePerl/lib
G:/Apps/ActivePerl/site/lib
.
Environment for perl 5.00503:
HOME (unset)
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=G:\Apps\DevStudio\SharedIDE\BIN;G:\Apps\DevStudio\VC\BIN;G:\Apps\DevStudio\VC\BIN\WINNT;E:\Program Files\Microsoft Office\Office;G:\Apps\cygnus\bin;G:\Apps\Perl\bin;G:\Apps\ActivePerl\bin;G:\Apps\DosBin;G:\Apps\PlPt\Sonoma Tools;G:\Apps\PlPt\Sonoma Tools\Perl\bin;E:\WINNT\system32;E:\WINNT;G:\Apps\DDK\bin;g:\apps\Versant\5_0_8\NT\bin;g:\apps\Versant\5_0_8\PulsePoint
PERL_BADLANG (unset)
SHELL (unset)
From [Unknown Contact. See original ticket]
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
From [Unknown Contact. See original ticket]
------- 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
From @kevindawson
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 "<b problem> will set a break point
here.\n" };
8: warn "This line will run even if you enter <c problem>.\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
From [Unknown Contact. See original ticket]
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 "<b problem> will set a break point
here.\n" };
8: warn "This line will run even if you enter <c problem>.\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
From @cpansprout
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 "<b problem> will set a break point here.\n" }; 8: warn "This line will run even if you enter <c problem>.\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
From @rocky
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.)
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 😃
Yeah, but how to retain dates when importing, say, issues from GitLab to GitHub?
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: @.***>
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.
