Breakpoints stop in wrong place (wrong file)

[gstead]

perl-debug is great and a main reason I switched to vscode. But I can't get breakpoints to break at the right place.

To reproduce:

1. unzip vscode-perl-debug-breaks-wrong-place.zip in a folder somewhere (zip includes:

$ ls -al vscode-perl-debug-breaks-wrong-place
total 24
drwx------     6 gstead  staff   192B Sep 22 14:27 ./
drwx------+ 4633 gstead  staff   145K Sep 22 14:27 ../
drwxr-xr-x     3 gstead  staff    96B Sep 22 14:27 .vscode/
-rw-------     1 gstead  staff   580B Sep 22 14:27 .vstags
-rw-r--r--     1 gstead  staff   198B Sep 22 12:36 TestPackage.pl
-rw-r--r--     1 gstead  staff   532B Sep 22 12:32 TestPackage.pm

2. cd to that folder
3. run code .
4. set a breakpoint in TestPackage.pm. I suggest somewhere in sub a or sub b
5. start debugging. After the initial pause, press > to continue (or c in console)
6. the debugger breaks in TestPackage.pl instead of the breakpoints in TestPackage.pm

If I had to guess, I'd day the debugger breaks on the correct line in TestPackage.pm. But perhaps vscode loads the wrong file and displays the break in the wrong place.

My environment

Mac OS/X Mojave; perl 5.16.3; perlbrew; Perl Debug 0.6.3

vscode details:

Version: 1.38.1
Commit: b37e54c98e1a74ba89e03073e5a3761284e3ffb0
Date: 2019-09-11T13:31:32.854Z
Electron: 4.2.10
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-electron.0
OS: Darwin x64 18.7.0

Things I debugged/checked:

Check 1) confirm the cli debugger works correctly (no vscode):

MacBook-Pro-2:vscode gstead$ perl -d TestPackage.pl

Loading DB routines from perl5db.pl version 1.37
Editor support available.

Enter h or 'h h' for help, or 'man perldebug' for more help.

main::(TestPackage.pl:3):	$\ = "\n";
  DB<1> f TestPackage.pm
1 	package TestPackage;
2:	use strict;
3:	use warnings;
4:	use Moose;
5
6:	has max => ( is => 'rw', isa => 'Int', default => 100 );
7
8:	has a => ( is => 'rw', isa => 'Int', lazy_build => 1 );
9
10 	sub _build_a {
  DB<4> l 13
13:	    return $num;
  DB<5> b 13
  DB<6> f TestPackage.pl
1:	use strict;
2:	use warnings;
3==>	$\ = "\n";
4
5:	use lib '.';
6:	use TestPackage;
7
8:	my $obj = TestPackage->new;
9:	print '$obj->a: ' . $obj->a;
10:	print '$obj->b: ' . $obj->b;
  DB<7> c
TestPackage::_build_a(TestPackage.pm:13):
13:	    return $num;
  DB<7> p $num
3

  DB<8> c
$obj->a: 3
$obj->b: 0
3=3
Debugged program terminated.  Use q to quit or R to restart,

Check 2) in launch.json I activated "debugRaw": true and "debugLog": true and then monitored the OUTPUT console while debugging. The commands there look correct

1. I see f TestPackage.pm,
2. b <line> to set breakpoints, and
3. when breakpoints trigger I see y 0 and y 1

This is exactly as one would expect.

Check 3) read DEBUGGING.md and then confirmed all debugger tests pass:

MacBook-Pro-2:vscode-perl-debug gstead$ npm test

> perl-debug@0.2.4 test /Users/gstead/wm/vscode-perl-debug
> jest --testTimeout=60000

 PASS  src/tests/filePath.test.ts
 PASS  src/tests/breakpointParser.test.ts
 PASS  src/tests/variableParser.test.ts
 PASS  src/tests/perlversion.test.ts
 PASS  src/tests/remote.test.ts
 PASS  src/tests/multisession.test.ts (6.352s)
 PASS  src/tests/connection.test.ts (7.621s)
 PASS  src/tests/adapter.test.ts (15.641s)

Test Suites: 8 passed, 8 total
Tests:       7 skipped, 55 passed, 62 total
Snapshots:   0 total
Time:        16.994s
Ran all test suites.

[hoehrmann]

@gstead: Try replacing the relative path in use lib '.' with an absolute path, like

use FindBin;
use lib "$FindBin::Bin";

Some months ago I changed all the test scripts to use that, and if this makes a difference, it would explain why the test suite passes on your system.

[gstead]

Many thanks for the suggestion. I changed those lines to switch to an absolute path, but the behavior stayed the same.

Included an animated gif below in case it helps.

I believe the debugger may have stopped in the right place...vscode just displays the wrong place (wrong file?). In the gif I type the y and v commands, and they behave as it the debugger stopped in the correct spot. Not sure if that helps...

[MrSilco]

I guess I have the same issue as yours but on Windows. Your code debugging works correctly on my macOS 10.14.6 with internal Perl 5.18.4 (that came with the OS) & PadWalker 2.3. But on my Windows it behaves as the gif shows. I think this problem somehow connected with the "Variable, Watch, Step by Step not working" issue. The '.' path cannot be resolved for an unknown reason so the debugger doesn't know where to stop or put the yellow cursor. If we can find out how we can fix it on your plarform maybe we can get closer resolving the other issue too.

[hoehrmann]

As I recall it, when the debugger stops, we send a StoppedEvent. vscode will then make a StackTrace request, and we respond with StackFrames that indicate their Source. The published version of the debug extension generates the StackTrace with the perl5db.pl T command. The command behaves differently between versions of Perl / perl5db.pl, e.g.

 bjoern@hpx360  ~  perlbrew use hpx360perl-5.28.1
 bjoern@hpx360  ~  perl -d -e '
print 123;
print 456;
'

Loading DB routines from perl5db.pl version 1.53
Editor support available.

Enter h or 'h h' for help, or 'man perldebug' for more help.

main::(-e:2):	print 123;
  DB<1> b 2 
  DB<2> b 3
  DB<3> s
main::(-e:3):	print 456;
  DB<3> T
@ = DB::DB called from -e line 3
  DB<3> 

versus

 bjoern@hpx360  ~  perlbrew use hpx360perl-5.16.3
 bjoern@hpx360  ~  perl -d -e '
print 123;
print 456;
'

Loading DB routines from perl5db.pl version 1.37
Editor support available.

Enter h or 'h h' for help, or 'man perldebug' for more help.

main::(-e:2):	print 123;
  DB<1> b 2
  DB<2> b 3
  DB<3> s
main::(-e:3):	print 456;
  DB<3> 123T
  DB<3> q

The older version of the debugger produces empty output. There may be other such issues. In any case, checking what Sources we report would probably be the biggest clue. I would also suspect that #91 fixes this problem.