Breakpoints setting and pausing is not working in debugger

[hurricup]

Need to investigate and test this

[aaron-j-garcia]

Hi! If you have some suspicions on what the issue may be for this, I"m happy to take a look (I have some limited Intellij plugin experience). I am diving into a new project in Perl that involves a lot of legacy code, and it would be very helpful if the breakpoints in the debugger worked again. Please feel free to reach out if you want some help, or if you could prioritize this issue, it would be great. Thank you so much!!

[hurricup]

Could you please describe exact reproduction steps? And perl/ide/plugin versions.

[aaron-j-garcia]

Absolutely. As requested, here are some preliminaries:

1. CLion Version: Build CL-241.11761.23 (the 2024.1 EAP from 02/07/2024).
2. Perl Plugin Version: 241.4832
3. Perl Version: 5.38.0

Steps to reproduce:

1. Create a new CLion project. I called mine "perl_plugin_debugging".
2. Add a file called test_perl_plugin.pm to the project. It is the only file in the attached .zip, and is a very simple Perl program.
3. Add a new "Perl Remote Debugging" configuration to the project. The default options are fine.
4. Set a break point in the IDE on line 25. (The "print "$test\n" line).
5. On your machine (I used an openSUSE Linux machine, version 15.5), run the test_perl_plugin.pm script with the debugging options that are provided from the plugin by default: "PERL5_DEBUG_HOST=localhost PERL_5_DEBUG_PORT=12345 PERL5_DEBUG_ROLE=client /path/to/your/perl -d:Camelcadedb ./test_perl_plugin.pm.
6. In the IDE, execute the run configuration.
7. The break point will not be stopped at.

I would expect the break point to be stopped at, and then I could press F9 and stop at it again the next time it hits... the debugging functionality works fine for stepping over code, and going line by line... but when you have a loop with 1000's of iterations (and most of them being thrown away by a "next unless" it makes for slow and painful debugging.

Happy to help in any way I can to get this fixed! Thank you again!!!

issue-2648.zip

[hurricup]

plugin is still unstable with 241. Lot of bugs. Also, please ensure that paths mappings are correct between local and remote project roots.

[aaron-j-garcia]

My understanding from other co-workers of mine is that this hasn't been working for the last six plus months (so from 2023.2 onward). Are you able to reproduce with the information I provided?

[hurricup]

Didn't try yet. Going to on the weekend.

[aaron-j-garcia]

Sounds good. Thank you for letting me know! I'll follow up with you next week.

[aaron-j-garcia]

Did you have a chance to look at this over the weekend? I'm happy to take a look if you can point me in the right direction of where you think the problem may be...

[hurricup]

I did some work on plugin, but not your particular issue yet. Trying to fix some exception in 2023.3 and 2041.1

As I mentioned above - first i would check if your mapping is correct. The symptom looks like it is not.

[aaron-j-garcia]

Hello,

You are right -- my mapping was incorrect. After fixing the mappings, I was able to use breakpoints, but only if they were defined before starting the debugger (or are defined while a breakpoint is active). For me, this use case is more-or-less fine.

However, a co-worker of mine also had this issue, and it was communicated incorrectly to me. If you try to set a breakpoint while a program is running, it does not work. It only works if a breakpoint was defined before execution of the program. This is a problem for us.

It turns out that you have hit on this issue once before here, in one of your YouTube videos: https://www.youtube.com/watch?v=kzG0GmWRZts. If you start watching from minute 37:30 to minute 39:00, you'll see where you hit the issue.

If you could point me to the place in the code where this occurs, I can take a stab at fixing this, and send a pull request to you. I'm a Java developer with some Intellij plugin experience.

Thanks so much for your help. Looking forward to hearing from you!

[hurricup]

Most likely problem is in perl part of the debugger. Not the IDEA part.

[hurricup]

Oh, there is actually a way to make it work, here are debug options:

And there is an option to make bp work when not paused. but it gives some overhead.

[aaron-j-garcia]

https://github.com/Camelcade/Perl5-IDEA/assets/160070707/e346ff6b-97af-4cd6-b31a-2be9d739456c

That option doesn't seem to work.

Please see the uploaded screen capture video to show you the steps that were taken. I have tried all of the various options in the run/debug configuration option, but they don't work. In the screen capture, I just selected the option to allow "breakpoints while script is not paused, moderate overhead".

This is running the master branch of the Perl plugin from Github on the latest IntelliJ IDEA community edition for plugin development.

[astange1]

I would love to see this get fixed too. In the video posted by @aaron-j-garcia, I see that the pause button is never enabled in the UI, even though the option to allow pausing the running program was selected. I'm happy to have a look at the plugin code for this, if you can provide a hint as to which files to look at.

[hurricup]

Ok, now I remember what is going on there and why. Here is a little story:

Perl has no usable threading (at least it didn't for sure), may be now something changed. So, unlike ruby, for example, where I create a separate thread to interact with debugger in kinda parallel, in perl I need to do everything synchronously and in the same thread.

Basically, perl debugger api have several hooks i can use:

• compiling file - DB::postponed
• calling a sub or jumping - DB::sub, DB::lsub, DB::goto (atm only sub is supported)
• stepping to the line - DB::DB

So debugger needs to check if there are new commands from the debugger in one of those hooks. Enabling line hook and basically check for IDE commands on each line is terrible for performance, so I decided to optimize things, and checking for them only on new sub invocation. So, you can't pause/set BP in runtime in some simple loop like in example above, but if there is a call for another sub - it works perfectly.

Here is related commit: https://github.com/Camelcade/Devel-Camelcadedb/commit/d5b2db764323e3cea3c59462907fdd513be30cec

Example demonstrating working behavior:

#!/usr/bin/perl
use strict;
use warnings FATAL => 'all';
use v5.36;

sub sayrunning{
    say 'Really running';
}

while(1){
    say "Running...";
    sayrunning;
    sleep 1;
}

My thoughts on this right now:

1. This is terrible usability, option need to be re-worded and probably some wiki article created with explanation.
2. Technically, we could provide an option to enable terrible-performing way to debug the script with line events on each line, but this still feels like an edge case, when you need to stop exactly somewhere with NO invocations of something.
3. The easiest way to debug a real thing is to temporary add a fake invocation to some no-op sub.

[hurricup]

This probably could also be solved with some native threading communication code, which will span the system thread, interact with debugger and propagate commands to the perl code somehow, but this is os-dependent stuff as far as I know windows needs a special treatment for threads, also may have some compatibility issues with native API, so i'm not ready for this.

[astange1]

Thank you for the additional details on how the plugin interacts with the perl DB. I was assuming it had to be something like how you described given the limitations of the perl platform (or some sort of signal handler that traps, but that too has problems).

But before any of what is described here can be invoked, the UI in the IDE has the pause button disabled. While test case provded by @aaron-j-garcia does not have a subroutine call in the loop, the user interface still has disabled the pause button, which must certainly be a bug and not just a usability issue.

[hurricup]

Ye, this most likely caused by https://github.com/JetBrains/intellij-community/commit/e9a81e62d7ca8f62b7bd3610b20505c39562c7c5

Previously it was enabled when not paused, but now it needs a special treatment.