Hi Jan -
If you have write access to the "require"d file, you can try setting a breakpoint in it, via setting:
$DB::single = 1
The following worked for me:

In t.pm:
package t;
BEGIN {
debug: $DB::single=1;
   $a = 1;
}
debug: $DB::single=1;
$a = 3;
1;

In t.pl:
require 't.pm';
print "done\n";

When I run:
perl -d t.pl
The debugger correctly breaks at the lines labeled 'debug' above.

Best,
Jay Rifkin



Jan Ploski wrote:

Hello,

I am the current maintainer of EPIC (http://e-p-i-c.sf.net), searching
in despair for a sensible way of reliably breaking in "require"d source
files (and some "use"d ones, too).

Let me provide a few simple examples first:

require '/some/abs/path/foo.pm';
require 'foo.pm';
require '/some/abs/path/../foo.pm';

All the paths above when passed to Cwd::abs_path() resolve to
/somewhere_else/abs/path/foo.pm (/some happens to bea symlink
to /somewhere_else).

I want to set a breakpoint in /somewhere_else/abs/path/foo.pm.
I don't care how this file is referred to in the sources, I just want
the debugger to break in it!

However, if I pass the above canonical absolute path to "b load",
it won't break, obviously, because Perl uses one of the strange paths
to refer to the file in %INC. Hence I won't get a chance to set
line breakpoints and EPIC users will rightfully complain about bugs.

I thought I could work around this issue using a custom watchfunction
to do the path resolution. I did. It worked, but it made the debugger
potentially orders of magnitude slower (even an empty watchfunction
has this effect). Wrong approach.

Next I thought I could just hack perl5db.pl to break on all loaded
filenames and do the path resolution then myself. Well, it seems to
work and is faster, but it has an unfortunate side-effect that "step"
commands break in strange places instead of finishing where they would
have without this additional hack. Unlike with "continue", where I can
just keep the debugger going in case it breaks on a line without
a real breakpoint, I cannot do the same with "step" commands,
simply because I would have to know where they are supposed to
finish "naturally".

I am now considering throwing away perl5db.pl or rewriting significant
portions of it. But maybe someone has a better idea?

Regards,
Jan Ploski




Reply via email to