Skip to content
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

Debugger: Break gets set on wrong subroutine #799

Open
p5pRT opened this issue Oct 29, 1999 · 11 comments
Open

Debugger: Break gets set on wrong subroutine #799

p5pRT opened this issue Oct 29, 1999 · 11 comments

Comments

@p5pRT
Copy link

@p5pRT p5pRT commented Oct 29, 1999

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

Searchable as RT1726$

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Oct 29, 1999

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
Copy link
Author

@p5pRT p5pRT commented Oct 29, 1999

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
Copy link
Author

@p5pRT p5pRT commented Dec 14, 2000

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
Copy link
Author

@p5pRT p5pRT commented Jun 25, 2004

From @schwern

This problem still exists in 5.8.3.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jul 12, 2005

From @schwern

This problem still exists in 5.8.6 and blead@​24148

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Aug 26, 2013

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
Copy link
Author

@p5pRT p5pRT commented Aug 26, 2013

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
Copy link
Author

@p5pRT p5pRT commented Aug 26, 2013

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
Copy link
Author

@p5pRT p5pRT commented Sep 8, 2013

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
Copy link

@piotr-yuxuan piotr-yuxuan commented Jul 1, 2021

This is currently the oldest issue still open on GitHub.

@ThePeeps191
Copy link

@ThePeeps191 ThePeeps191 commented Jan 23, 2022

yes its very old

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants