One clue as to what's going on might be in the perl -MO=Deparse output:

package X;
sub BEGIN {
    require strict;
    do {
        'strict'->import
    };
}
use Attribute::Handlers;
sub a {
    use strict 'refs';
    print "a\n";
}
use attributes ('X', sub {
    use strict 'refs';
    print "a\n";
}
, 'ATTR(SCALAR)');
sub b {
    use strict 'refs';
    print "b\n";
}
package main;
use strict 'refs';
X::a();
X::b();
[download]

Adding a call to a routine that prints "caller" info instead of the print statements in a and b shows that the caller info is sane, and matches the expected line numbers.

The use attributes line is there for two reasons:
1. Loads attributes.pm if it isn't loaded.
2. Regardless of if it was loaded, calls attributes->import( ... ) with the params passed.

I'm willing to bet that what happens is that the breakpoint is set on the "sub a", but that function isn't executed. Instead, it is replaced by the one declared by attributes. Unfortunately, the attributes heavy lifting code is within the Perl source, so it's a little less accessible to one such as I.

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Instead of "b X::a", do the following:

 % perl -d test.pl
# ...
206:                    $global_phase++;
  DB<1> l X::a
Switching to file 'test.pl'.
5:      sub a : ATTR(SCALAR) {
6:          print "a\n";
7:      }
  DB<2> b 6
  DB<3> c
X::a(attribBreak.pl:6):     print "a\n";
  DB<3>
[download]

Indeed that's the obvious solution in this case, but in the real case, the line in question is buried in some class in another file. The reason I want to breakpoint a method is because I can't put a breakpoint there using the line number, at least without stepping through lots of intervening code.

I don't see how what you describe makes what I suggested any less useful. Instead of putting a breakpoint on a method, list the start of the method and put a breakpoint on the first line inside of the method. I certainly didn't step "though lots of intervening code" so I'm not sure why you think you would need to.

- tye        

Using 5.8.8 on Solaris 10, I get the same results you report.

I wonder if Attribute::Handler is interacting with the debugger in strange and wonderful ways. I don't have any particular insights on the problem.

sub a : ATTR(SCALAR) {
    _a( @_ ); 
}

sub _a {
    print "a\n";
}
[download]

Thank you, this does work. Unfortunately this makes the resulting code look like a non-sequitur, so I'm not sure I could justify it for the general case.

IIRC, I tried to diagnose the Attributes::Handler code, but got lost pretty quickly in some of its more arcane symbol twiddling.

Thanks, but no, mainly because my problem isn't so much getting the debugger to stop once, it's passing on test code which is difficult debug in general.