Fix perl debugger bits skipping files with DB in name

[Naatan]

Reference: http://forum.komodoide.com/t/iide-pro-v9-0-1-remote-debugging-for-perl-wont-stop-at-breakpoints/1603/9?u=nathanr

Relevant part:

The fix I installed was to inspect the $filePath variable for the element "Komodo", since the install path of the debugging module on my system is "/usr/lib64/perl5/vendor_perl/Komodo". Here is the code (in context) that works on my system:

    #...
    if (($single || $signal)
        && ($pkg eq 'DB::fake'|| !(($pkg =~ /^DB::/) && ($filePath =~ /Komodo/)))
        && !$inPostponed) {
    #...

[ericpromislow]

This won't work on Windows, and I'm not sure about OS X.

[ghost]

I originated this and wrote the fix. It's not quite right yet. First, "$filePath" should instead be $filename.

More importantly, it turns out that there are several (on the order of 5-6) other occurrences of the same test scattered through perl5db.pl. Each needs a similar change.

You're absolutely correct that it won't work on Windows. The issue is that the test for "DB::" has to be restricted to just the Komodo package. Another approach is to name the package in the Komodo distribution something more specific to Komodo, like "KomodoDB". On the other hand, if there's some other "DB::" package that these methods extend, that probably won't work either.

Once I replaced all occurrences of the too-broad search, KomodoIDE behaved much more nicely (I don't debug remote systems running on Windows or OS X).

[Niklas81]

It might interest you to know that this bug works the same for PHP as well. That is, remote debugging of PHP ignores breakpoints. Using Komodo IDE 9.1.

[th3coop]

It might interest you to know that this bug works the same for PHP as well. That is, remote debugging of PHP ignores breakpoints. Using Komodo IDE 9.1.

This is very likely not the same issue. Please ask for assistance in the forums http://forum.komodoide.com/. This bug reports a very specific case in Perl files. Your, @Niklas81, is likely configuration issue.

[mitchell-as]

It appears that Perl, when run in debug mode, looks for a "DB::DB" routine by default. Since we have injected our own DB package to override Perl's, renaming our package to something like "ActiveStateKomodoDB" will not work. I think we'll have to come up with another solution that does not involve renaming packages.

[mitchell-as]

This has been fixed by requiring an additional match of $filename to /dbgp[\/\\]perllib/. This subdirectory structure exists on all platforms.

[ghost]

@mitchell-as: That should work very nicely, thank you!

[ghost]

Sadly, the fix for this seems to have fallen off of the v 9.3.2 release. The symptoms are the same, and the several references to "DB" seem to have reverted to the same failing value.

I'm not sure if your desired protocol is to reopen this bug or file a new one.

[mitchell-as]

I'll re-open this for investigation later.

[mitchell-as]

I am not able to trigger this in Komodo X. @zeeforgellc if you can still reproduce this in X, please file a new ticket with some details on how to reproduce it. Thanks!

[ghost]

I'm still having issues that seem related. I'm using v10.0.1 (an evaluation copy), doing remote debugging on a Linux VM connected to a Windows host running Komodo. When the guest is finished, and trying to exit, execution stops on an apparent breakpoint in DbgrCommon.pm (an ActiveState file) at line 391. If I attempt to continue, it complains about attempting to start a debugging session.

I've attached two screenshots, showing the breakpoint location in Komodo and also the callstack. I find the "Call Stack Location" at the top of the stack suspicious ... "DbgrCommon.pm, line 391, in DB::DB".

[ghost]

This morning, I replicated the issue while no breakpoints were set at all, and captured the perl log (emitted after adding a value for "LogFile" to $PERLDB_OPTS). The resulting logfile is attached below.

komodo_perl_no_breakpoints.log.txt

[ghost]

That was for v9.3.2, by the way. The behavior is unchanged for v10.0.n.

[mitchell-as]

Okay, I think I may have identified the problem.

The Perl debugger tries to not break inside any package that matches /^DB::/. However, that may exclude non-Komodo-debugger packages, and this ticket was originally created to combat that case.

The fix I committed more than a year ago (along with a comment in this thread) relies on checking the filepath if the package matches /^DB::/. This filepath is /dbgp[\/\\]perllib/ and works for any local Perl debugging session. However, your remote machine has installed Komodo's remote Perl debugger to /usr/lib64/perl5/vendor_perl/Komodo/DB/. According to the remote Perl debugging instructions (http://docs.komodoide.com/Manual/debugperl#debugging-perl-komodo-ide-only_debugging-perl-remotely), one should "Copy Komodo's perl debugger and its associated libraries to the remote machine by copying the entire dbgp/perllib sub-directory of the Komodo installation to the new machine". If you match the directory structure, specifically keep dbgp/perllib, then Komodo should ignore its own internals on the remote machine.

TLDR: install Komodo's remote Perl debugging bits on your remote Linux machine to a path that includes "dbgp/perllib" (e.g. /usr/lib64/perl5/vender_perl/Komodo/dbgp/perllib/).

I need to update the documentation to reflect this.

[ghost]

Ah, that makes perfect sense. I'll make that change ASAP.

[ghost]

Works like a champ. Your last "TLDR" is exactly what's needed in the doc.

The other documentation change that needs to be made simultaneously is that the value added to $PERL5LIB has to also include the new addition to the path ...
export PERL5LIB=/usr/lib64/perl5/vendor_perl/Komodo/dbgp/perllib/".

I put mine in a little bash script in /etc/profile.d, be sure to append the new value to the end of $PERL5LIB if it's already there.

I appreciate your quick response for this, I'm glad to have this perl debugger working again. FWIW, the Komodo support for remote debugging is still WAY better than the several alternatives my team is looking at.

[tonyattwood]

Dear!

There are a cople of stories I wanted to share with you, please, read more here http://stothophomo.kelleypeart.com/e4eowyel

My Best, tony.attwood