Debugger cannot save breakpoints on modules loaded by code

[tomk3003]

When modules are loaded by code (by a subroutine reference in @INC) the debugger loads and displays the modules correctly. Stepping through them works as well. But saving breakpoints does not work because the files are displayed as e.g:

  /loader/0x5636792d93e8/Mod1.pm
  /loader/0x5636792d93e8/Mod2.pm

and the hex id will change on each debugger run. The id seems to be the code reference saved in %INC. For keeping track of the breakpoints it should be enough to just ignore the id or exchanging it with a fixed value since there is no real file anyway.

PyCharm 2020.2.2 (Professional Edition) Build #PY-202.7319.64, built on September 16, 2020 Runtime version: 11.0.8+10-b944.31 amd64 VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o. Linux 5.4.0-48-generic GC: ParNew, ConcurrentMarkSweep Memory: 4029M Cores: 8 Non-Bundled Plugins: net.seesharpsoft.intellij.plugins.csv, com.perl5, com.perl5.lang.embedded, com.perl5.lang.mojo, com.perl5.lang.tt2, com.jetbrains.intellij.datalore Current Desktop: ubuntu:GNOME

[tomk3003]

I have played around with the debug output of Devel::Camelcadedb and found that a saved brakepoint for a module loaded by code is never sent to the debugger on the next run. There seems to be a check that the defined breakpoint can be mapped against a real file.

[hurricup]

Yep. This requires special treatment I believe.

[tomk3003]

If you want to test this without too much effort, you can use my module lib::archive from CPAN. It puts a sub into @INC that can load modules from a TAR archive. I stumbled over the debugger issues while developing the new version.

[tomk3003]

A related Question: with modules loaded from code, the context sensitive actions (CTRL-Q:Quick Doc or CTRL-ALT-B:Goto Implementation) are not possible at the moment. Is this something you'd consider to implement?

[hurricup]

Probably, but not sure when.

[hurricup]

What is the reason for using such approach?

[tomk3003]

We are using a lib::archive TAR file consisting a versioned(!) collection of self written modules (an internal standard library). The developer just adds the line use lib::archive STD-v1.0.5.tgz; and thus keeps control over which version should be used. Upgrading is a concious decision by the developer. We have had bad experiences with centrally kept modules that break things when updated. So if the developer wants to look into the modules (e.g. for the context sensitive actions) it would be nice to resolve that dynamically. But I understand that this is only nice to have. I could also put a development option into lib::archive to extract the files to a temporary directory. The use case is not very strong for this alone. Another way altogether would be to use git submodule instead of module archives.

[hurricup]

I'm not sure I'll be able to fix this. Technically it's doable, but this is a too tricky and requires introducing some breakpoints processing we don't have and don't need in any other case. I'll keep this issue opened, but this most likely won't ever be fixed (by myself)

[tomk3003]

no worries, for our use case I have already added an option to extract to a temporary directory. Then everything works as expected.