Debugger: Break gets set on wrong subroutine #799

p5pRT · 1999-10-29T11:38:24Z

Migrated from rt.perl.org#1726 (status was 'open')

Searchable as RT1726$

p5pRT · 1999-10-29T11:38:24Z

From tye@metronet.com

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)

p5pRT · 1999-10-29T14:45:18Z

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

p5pRT · 2000-12-14T11:31:19Z

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

p5pRT · 2004-06-25T21:45:19Z

From @schwern

This problem still exists in 5.8.3.

p5pRT · 2005-07-12T21:51:19Z

From @schwern

This problem still exists in 5.8.6 and blead@24148

p5pRT · 2013-08-26T15:13:35Z

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

p5pRT · 2013-08-26T15:13:35Z

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

p5pRT · 2013-08-26T16:01:07Z

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

p5pRT · 2013-09-08T01:45:42Z

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 rocky/Perl-Devel-Trepan#24 so I
don't forget about this.

(Sorry for the delayed reply.)

piotr-yuxuan · 2021-07-01T17:00:41Z

This is currently the oldest issue still open on GitHub.

ThePeeps191 · 2022-01-23T05:30:19Z

yes its very old

qballer · 2022-02-09T12:06:27Z

older then GitHub it's self

ThePeeps191 · 2022-02-09T16:06:40Z

🤣

piotr-yuxuan · 2022-02-09T21:55:46Z

I'd really like to know how to import such old projects and keep all the issues. Is it still at all possible?

Grinnz · 2022-02-09T22:07:33Z

The dates were retained when importing from the original issue tracker, which was not GitHub 😃

ThePeeps191 · 2022-02-09T23:14:58Z

nice! :)

piotr-yuxuan · 2022-02-10T10:10:34Z

Yeah, but how to retain dates when importing, say, issues from GitLab to GitHub?

FlowismG · 2022-05-27T18:54:48Z

old

ThePeeps191 · 2022-05-28T00:24:17Z

Yea ikr

…

On May 27, 2022 at 12:55 PM, <Flowism ***@***.***)> wrote: old — Reply to this email directly, view it on GitHub (#799 (comment)), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AR2DTG7V645NTOY6S4JCXJ3VMELAHANCNFSM47LWVCVQ). You are receiving this because you commented.Message ID: ***@***.***>

Uzlopak · 2022-11-04T13:20:32Z

Can this please fixed asap? This is currently blocking us.

p5pRT added Severity Medium distro-unknown type-core type-debugger labels Oct 18, 2019

p5pRT mentioned this issue Oct 19, 2019

Program terminated with signal 11, Segmentation fault. #12469

Closed

toddr added affects-5.30 and removed distro-unknown labels Feb 14, 2020

toddr pinned this issue May 22, 2020

jkeenan unpinned this issue May 23, 2020

xenu removed affects-5.8 labels Nov 19, 2021

xenu removed the Severity Medium label Dec 15, 2021

Debugger: Break gets set on wrong subroutine #799

Debugger: Break gets set on wrong subroutine #799

p5pRT commented Oct 29, 1999

p5pRT commented Oct 29, 1999 •

edited by toddr

p5pRT commented Oct 29, 1999

p5pRT commented Dec 14, 2000

p5pRT commented Jun 25, 2004

p5pRT commented Jul 12, 2005

p5pRT commented Aug 26, 2013

p5pRT commented Aug 26, 2013

p5pRT commented Aug 26, 2013

p5pRT commented Sep 8, 2013 •

edited by toddr

piotr-yuxuan commented Jul 1, 2021

ThePeeps191 commented Jan 23, 2022

qballer commented Feb 9, 2022

ThePeeps191 commented Feb 9, 2022

piotr-yuxuan commented Feb 9, 2022

Grinnz commented Feb 9, 2022

ThePeeps191 commented Feb 9, 2022

piotr-yuxuan commented Feb 10, 2022

FlowismG commented May 27, 2022

ThePeeps191 commented May 28, 2022 via email

Uzlopak commented Nov 4, 2022

Debugger: Break gets set on wrong subroutine #799

Debugger: Break gets set on wrong subroutine #799

Comments

p5pRT commented Oct 29, 1999

p5pRT commented Oct 29, 1999 • edited by toddr

From tye@metronet.com

p5pRT commented Oct 29, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Dec 14, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Jun 25, 2004

From @schwern

p5pRT commented Jul 12, 2005

From @schwern

p5pRT commented Aug 26, 2013

From @kevindawson

p5pRT commented Aug 26, 2013

From [Unknown Contact. See original ticket]

p5pRT commented Aug 26, 2013

From @cpansprout

p5pRT commented Sep 8, 2013 • edited by toddr

From @rocky

piotr-yuxuan commented Jul 1, 2021

ThePeeps191 commented Jan 23, 2022

qballer commented Feb 9, 2022

ThePeeps191 commented Feb 9, 2022

piotr-yuxuan commented Feb 9, 2022

Grinnz commented Feb 9, 2022

ThePeeps191 commented Feb 9, 2022

piotr-yuxuan commented Feb 10, 2022

FlowismG commented May 27, 2022

ThePeeps191 commented May 28, 2022 via email

Uzlopak commented Nov 4, 2022

p5pRT commented Oct 29, 1999 •

edited by toddr

p5pRT commented Sep 8, 2013 •

edited by toddr