Debugger: Break gets set on wrong subroutine

[p5pRT]

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

Searchable as RT1726$

[p5pRT]

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)

[p5pRT]

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]

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]

From @schwern

This problem still exists in 5.8.3.

[p5pRT]

From @schwern

This problem still exists in 5.8.6 and blead@​24148

[p5pRT]

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]

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]

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]

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

(Sorry for the delayed reply.)

[piotr-yuxuan]

This is currently the oldest issue still open on GitHub.

[piotr-yuxuan]

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

[Grinnz]

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

[piotr-yuxuan]

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

[Uzlopak]

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

[mauke]

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.