develooper Front page | | Postings from January 2013

TPF Devel::Cover grant report Weeks 30-32

Thread Next
Paul Johnson
January 2, 2013 14:37
TPF Devel::Cover grant report Weeks 30-32
Message ID:
In accordance with the terms of my grant from TPF this is the report for
weeks 30-32 of my work on improving Devel::Cover.

This report covers 08.12 to 28.12.

Last week I mentioned the pull requests I had received.  I this week I merged
a pull request from Steffen Schwigon adding some important modules to  I'm always happy to add modules that people would like to see
on cpancover, so if there's anything you think should be on there, let me

And speaking of, you should now be able to see a note at the
foot of the title page thanking Bytemark for their generosity in donating the
server that hosts the site.  See last week's report for the details.  Thanks
again to Bytemark for that.

I spent some time looking at
This is a bug report from David Cantrell in which there is different behaviour
when a program is run under Devel::Cover to when it is run normally.  To me
this is the most serious type of problem.  Devel::Cover should not alter the
output of the program being covered.  This is more important than missing or
giving incorrect coverage information, or being slow.

From the mail message I wrote to p5p to clarify the situation:

I have narrowed the problem down to the following code:

    my $attributed;
        my ($class, $code, @attrs) = @_;
        $attributed = $code;
    my $foo = sub :MyAttribute {};
    print "$attributed, $foo\n";

If you run this code normally, you find that $attributed and $foo have
the same value.  This is as it should be since the docs for say that $code should be a reference to the sub with the
attribute.  (Actually, the docs don't explicitly say that but I think
the intent is clear.)

When run under the debugger you find that $code is actually a different
subroutine reference.  The reason is this little bit of code in

    if (PL_cv_has_eval || PL_perldb) {
        const CV *cv;
        for (cv = PL_compcv ;cv; cv = CvOUTSIDE(cv)) {
            if (cv != PL_compcv && CvCOMPILED(cv))
                break; /* no need to mark already-compiled code */
            if (CvANON(cv)) {
                    "Pad clone on cv=0x%"UVxf"\n", PTR2UV(cv)));

The code is preceded by this comment:

    /* If this CV has had any 'eval-capable' ops planted in it
     * (ie it contains eval '...', //ee, /$var/ or /(?{..})/), Then any
     * anon prototypes in the chain of CVs should be marked as cloneable,
     * so that for example the eval's CV in C<< sub { eval '$x' } >> gets
     * the right CvOUTSIDE.
     * If running with -d, *any* sub may potentially have an eval
     * executed within it.

So, there are a few questions.

First, is it correct that these two subroutine refs should be identical?

If so, should that also hold when running under the debugger?

And if it shouldn't necessarily hold, is that also true for $^P being
set to any value, as is currently the case?

The reason this shows up in Devel::Cover is because $^P is set to 0x104
which, I think, doesn't meet the conditions in the comment.

So the upshot of this one is that I don't think this is a bug in Devel:Cover.
It seems that the expectation that $code should be a reference to the sub with
the attribute is false.  As Dave Mitchell wrote:

] Given that MODIFY_CODE_ATTRIBUTES() is only called once at compile time,
] while sub {} can be called multiple times at runtime, I'm not sure it
] makes sense in general for $attributed to match anything; e.g. in
]   my $x;
]   push @foo, sub :MyAttribute {$x} for 1..10;
] which (if any) of the elements of @foo would you expect to be equal to
] $attributed?

I also spent some time tracking down a problem that someone had with a
Catalyst application that was giving a Unique Constraint Error in SQLite only
when run with Devel::Cover.  As it happens, that turned out to be exactly the
same problem.  So that's Dancer and Catalyst where this problem is showing up.

Then I looked into the possibility of adding a link on MetaCPAN to a module's
coverage on CPANcover.  I put together a patch to the front-end to see whether
there was general interest, which seems to be the case.  However, some
back-end support is probably needed since CPANcover only has coverage for a
subset of CPAN, and I don't really want to be directing people to 404s.  With
backend support it will also be possible to go directly to the coverage for a
specific file.

I've not made a backend patch since I'm not really sure how to do it.  I'm
hoping someone will offer to either do that, or tell me how to do it.  The
patch is at should anyone
feel like taking this further.

Merged pull requests:

  37 Add modules to cpancover

You can see the commits at

Hours worked:

  08.12   6:20
  22.12   2:30

  Total   8:50

Paul Johnson -

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About