Nihilus118 / perl-debug-adapter

MIT License
11 stars 2 forks source link

Debugger hangs after first breakpoint #2

Closed didster closed 1 year ago

didster commented 1 year ago

VSCode: 1.80.2 Perl: Strawberry 5.36.1.1 (Windows) Extension: 1.0.3

Hi,

I have used this extension for many months with great success doing Perl debugging on Windows. It's really the only option for Windows Perl dev as the other Perl debugger VSCode extension requires installation of Perl::LanguageServer which doesn't work on Windows.

I don't do much Perl development these days and haven't used the extension for maybe 3 months.

Unfortunately, something has changed in my setup which is causing the extension to lock up after the first breakpoint is hit. On this simple program:

use strict;
use warnings;
print("1\n");
print("2\n");
print("3\n");

With a break point on print 1 and print 3.

Running under VSCode the breakpoint on line 1 is hit. Then if you step over, nothing happens. Likewise if you do F5 for continue. In task manager you can see the perl -d process running - but there is no response to any commands from that point and the only option is terminate.

Enabling trace gives

CWD: C:\f
Script: C:\f\foo.pl
Perl executable: perl
Command: f c:/f/foo.pl
Starting debugging
Command: package DB; $DB::preview = 0;
Could not change file context: No file matching 'c:/f/foo.pl' is loaded.
Command: f foo.pl
Command: notrace
Successfully changed file context to foo.pl: Choosing C:\f\foo.pl matching 'foo.pl':
Command: b 4 undefined
Command: o PrintRet=0
Command: b 8 undefined
Command: package DB; *DB::postponed = sub { return sub { if ( 'GLOB' eq ref(\$_[0]) && $_[0] =~ /<(.*)\s*$/s) { if ($DB::single == 0) { print STDERR "continue "; } $DB::single = 1; print STDERR "loaded source $1\n"; } } ; }->(\\&DB::postponed)
Command: use PadWalker qw/peek_our peek_my/; use Data::Dumper;
Command: print STDERR threads->self()->tid()
StopOnEntry: true
Command: print STDERR threads->self()->tid()
Command: T
Command: c
12Command: print STDERR threads->self()->tid()
Command: T

You can see the 1 and 2 printed, but not the 3.

Clearly something has changed somewhere as as I say I have used the extension with no issue for many months on Windows. Unfortunately though I paid no attention to what version of VSCode or Perl I was using when it worked. I have tried rolling back both Perl and the extension to no avail, so I can only assume its a VSCode update breaking things. I have also tried a complete fresh installation a different PC - same result.

Any help appricated

Nihilus118 commented 1 year ago

Hi,

I think I have some good news. I was able to reproduce the error and it seems like there is a bug with the newest version of VSCode that causes the builtin debug client to send two stack trace requests at once, which causes the debug session to hang indefinitely. After improving the logging and enabling trace:

StopOnEntry: true
Event sent: {"seq":28,"type":"event","event":"stopped","body":{"reason":"entry","threadId":1}}
Response sent: {"seq":30,"type":"response","request_seq":2,"command":"launch","success":true}
Response sent: {"seq":32,"type":"response","request_seq":7,"command":"threads","success":true,"body":{"threads":[{"id":1,"name":"thread 0"}]}}
Command: print STDERR threads->self()->tid()
Response sent: {"seq":35,"type":"response","request_seq":8,"command":"threads","success":true,"body":{"threads":[{"id":1,"name":"thread 0"}]}}
Command: foreach my $INCKEY (keys %INC) { print STDERR $INCKEY . "||" . %INC{$INCKEY} . "\n" }
Response sent: {"seq":38,"type":"response","request_seq":9,"command":"loadedSources","success":true,"body":{"sources":[{"name":"Config.pm","path":"C:/Strawberry/perl/lib/Config.pm","sourceReference":0},{"name":"SelectSaver.pm","path":"C:/Strawberry/perl/lib/SelectSaver.pm","sourceReference":0},{"name":"SelfLoader.pm","path":"C:/Strawberry/perl/lib/SelfLoader.pm","sourceReference":0},{"name":"feature.pm","path":"C:/Strawberry/perl/lib/feature.pm","sourceReference":0},{"name":"Term/Cap.pm","path":"C:/Strawberry/perl/lib/Term/Cap.pm","sourceReference":0},{"name":"Cwd.pm","path":"C:/Strawberry/perl/lib/Cwd.pm","sourceReference":0},{"name":"DynaLoader.pm","path":"C:/Strawberry/perl/lib/DynaLoader.pm","sourceReference":0},{"name":"Symbol.pm","path":"C:/Strawberry/perl/lib/Symbol.pm","sourceReference":0},{"name":"strict.pm","path":"C:/Strawberry/perl/lib/strict.pm","sourceReference":0},{"name":"bytes.pm","path":"C:/Strawberry/perl/lib/bytes.pm","sourceReference":0},{"name":"Carp.pm","path":"C:/Strawberry/perl/lib/Carp.pm","sourceReference":0},{"name":"Config_git.pl","path":"C:/Strawberry/perl/lib/Config_git.pl","sourceReference":0},{"name":"IO/Handle.pm","path":"C:/Strawberry/perl/lib/IO/Handle.pm","sourceReference":0},{"name":"warnings.pm","path":"C:/Strawberry/perl/lib/warnings.pm","sourceReference":0},{"name":"constant.pm","path":"C:/Strawberry/perl/lib/constant.pm","sourceReference":0},{"name":"Term/ReadLine/readline.pm","path":"C:/Strawberry/perl/vendor/lib/Term/ReadLine/readli[...]
Command: T
Response sent: {"seq":41,"type":"response","request_seq":10,"command":"stackTrace","success":true,"body":{"stackFrames":[{"id":0,"source":{"name":"issue_2.pl","path":"C:\\...\\issue_2.pl","sourceReference":0},"line":3,"column":0,"name":"DB::DB"}],"totalFrames":1}}
Command: T
Response sent: {"seq":44,"type":"response","request_seq":11,"command":"stackTrace","success":true,"body":{"stackFrames":[{"id":0,"source":{"name":"issue_2.pl","path":"C:\\...\\issue_2.pl","sourceReference":0},"line":3,"column":0,"name":"DB::DB"}],"totalFrames":1}}
Event sent: {"seq":46,"type":"event","event":"continued","body":{"threadId":1}}
Command: c
1
2
Event sent: {"seq":49,"type":"event","event":"output","body":{"category":"stdout","output":"1\r\n2\r\n"}}
Event sent: {"seq":51,"type":"event","event":"stopped","body":{"reason":"breakpoint","threadId":1}}
Response sent: {"seq":53,"type":"response","request_seq":12,"command":"continue","success":true}
Command: print STDERR threads->self()->tid()
Response sent: {"seq":56,"type":"response","request_seq":13,"command":"threads","success":true,"body":{"threads":[{"id":1,"name":"thread 0"}]}}
Command: T
Response sent: {"seq":59,"type":"response","request_seq":14,"command":"stackTrace","success":true,"body":{"stackFrames":[{"id":0,"source":{"name":"issue_2.pl","path":"C:\\...\\issue_2.pl","sourceReference":0},"line":5,"column":0,"name":"DB::DB"}],"totalFrames":1}}
Command: T
Response sent: {"seq":62,"type":"response","request_seq":15,"command":"stackTrace","success":true,"body":{"stackFrames":[{"id":0,"source":{"name":"issue_2.pl","path":"C:\\...\\issue_2.pl","sourceReference":0},"line":5,"column":0,"name":"DB::DB"}],"totalFrames":1}}

The last event sent by the debug adapter is the stopped event for the breakpoint on line 5, which is returned in the stackTrace-response afterwards. This seems correct in my eyes except the two calls on the stackTraceRequest. I will continue to investigate this further.

didster commented 1 year ago

That's great to hear I'm not going mad :-). Good luck with the fix.

Nihilus118 commented 1 year ago

@didster the newest VSCode update fixed the problem for me. Are you still experiencing this problem after updating to the latest release of VSCode?

didster commented 1 year ago

Hiya,

Yep! I can confirm it's all working again for me after the last update. Phew!

Thanks for the investigations, I'll raise another issue etc if it stops working again after the next update :-)

Nihilus118 commented 1 year ago

Great to hear! Have a good time coding and using the debugger.