Discussion:
TPF Devel::Cover grant report January 2013
Paul Johnson
2013-02-11 20:53:10 UTC
Permalink
In accordance with the terms of my grant from TPF this is the monthly
report for my work on improving Devel::Cover covering January 2013.

If you were watching closely you'll have noticed that I finished my December
report with exactly 200 hours worked on the grant. The reason for that was
that that completed the first half of the grant.
From my point of view the first half has been rather successful. I won't go
through the accomplishments in detail, they're in the monthly reports if you
want to look, but I'm happy to have been able to have the opportunity to solve
a number of tricky bugs which have been around for a long time.

I'm pleased to be able to report that we've agreed to continue with the second
half of the grant. This is likely to continue in a similar vein to the first
half but we've decided that, in conjunction with the monthly reports, the
weekly reports are overkill so there'll be just the one official report per
month unless I do a bit more work than usual one month.

I'd like to publicly thank Ricardo Signes and Florian Ragwitz for their help
and support in managing the first half of the grant. I'm well aware that
neither of them has really got anything better to do, but I'm grateful
nevertheless. I'm happy to announce that that Christian Walde (Mithaldu) has
agreed to manage the second half of the grant in Florian's stead, and I look
forward to working with him.

January started with fixing a segmentation fault which occurred when an xor
operator was optimised away through constant folding. Then I looked into a
couple of cpantesters reports which showed a problem on Windows. I couldn't
repeat the failures, and it seemed that only one tester had the problem, on
version 0.98. Version 0.99 seems not to have shown any failures, so I'll
chalk that up to cosmic rays or something.

There was a problem reported on perlmonks
(http://www.perlmonks.org/?node_id=1011058) which turned out to be a bug in
Devel::Cover. The code to check whether we are collecting coverage in a file
calls into Perl code from within hijacked ops. Hijacked ops are perl ops
where Devel::Cover changes the op's function pointer so it can do some work
before continuing on with what perl needs to do.

When collecting coverage with tainting turned on, this could leave things
tainted when they shouldn't have been. The fairly simple solution was to get
the tainting status before calling the Perl subroutine and restore that status
afterwards, but this was one of those bugs where all the effort was spent in
locating the problem, which involved getting fairly intimate with gdb and
PL_tainted.

David Cantrell added JavaScript to filter results in html_basic and sent me a
pull request. This is a useful option if your coverage run includes many
files. I merged the pull request and also added an option to the report to
control whether or not the filter is available. The option defaults to on,
but it might be worth making that dependent on the number of files in the
report.

I tested Devel::Cover against the newly released 5.17.8 which didn't show up
any problems.

I started preparing a release and decided that I should finally finish off and
document the "uncoverable" options - the ability to flag a section of code
that cannot be covered. In doing so, I came across a bug, not in that code,
but in the code for condition coverage. This is probably the most complicated
section of the Devel::Cover code.

I narrowed down the problem somewhat, and it seems to be caused by a change in
perl's opcode handling, but I didn't come to any firm conclusions. Hopefully
there will be more news on this in February's report.

Closed RT tickets:

Closed Github tickets:

40 0.99 Segmentation fault for xor eval'ed operator
41 Spurious tainting errors.

Merged pull requests:

42 Add Javascript filtery thing to Html_basic reports

You can see the commits at https://github.com/pjcj/Devel--Cover/commits/master

Hours worked:

05.01 9:20
19.01 2:30
23.01 1:15
26.01 8:25

Total 21:30

Total hours worked on grant: 221:30
--
Paul Johnson - ***@pjcj.net
http://www.pjcj.net
Paul Johnson
2013-02-12 22:36:34 UTC
Permalink
Then I looked into a couple of cpantesters reports which showed a problem
on Windows. I couldn't repeat the failures, and it seemed that only one
tester had the problem, on version 0.98. Version 0.99 seems not to have
shown any failures, so I'll chalk that up to cosmic rays or something.
I can explain this one.
Older Perls have an odd bug that causes $ENV{PERL5LIB} of over 65k
chars to be completely ignored on Windows 7, resulting in a
automated smoker which does not actually install dists, but only
saves them to cpan/build and adds them to PERL5LIB. On windows below
7 this does not happen, as the 65k limit is correct there and the
process won't even start before reaching the perl interpreter code.
On higher Perls the limit is observed properly.
http://www.cpantesters.org/cpan/report/dfc0a61f-6c90-1014-b3bb-e7381ede6b02
If it's massive, ask the smoker to upgrade to Perl5 16.0 or newer. :)
Related ticket: https://rt.perl.org:443/rt3/Ticket/Display.html?id=87322
Excellent. Thanks!
David Cantrell added JavaScript to filter results in html_basic
and sent me a pull request.
This is pretty cool, is there a reason that wasn't also added to the
default html output?
The main reason is that the patch wasn't for that report :) But there
are reasons behind that too.

The default html report has it's advantages, for sure, but it also has
disadvantages. The code for that report is harder to work with and this
is probably the main reason why new features get added to the html_basic
report. In addition, the nice condition coverage reports are inaccurate
in complicated cases. Also the default report doesn't take into account
the newly released uncoverable code correctly.

I have been using the html_basic report for cpancover.com, and at some
point I want to make it the default report, but it could probably do
with a little work from someone who knows how to make things look nice.
--
Paul Johnson - ***@pjcj.net
http://www.pjcj.net
Ricardo Signes
2013-02-13 02:45:31 UTC
Permalink
Post by Paul Johnson
I'm pleased to be able to report that we've agreed to continue with the second
half of the grant.
Excellent!
Post by Paul Johnson
I'd like to publicly thank Ricardo Signes and Florian Ragwitz for their help
and support in managing the first half of the grant. I'm well aware that
neither of them has really got anything better to do, but I'm grateful
nevertheless.
It's true, if it weren't for spending 30 minutes a month reviewing these grant
reports, I'd be returning to a life of crime! With Florian!
Post by Paul Johnson
Total hours worked on grant: 221:30
+1
--
rjbs
Christian Walde
2013-02-12 11:38:12 UTC
Permalink
Post by Paul Johnson
05.01 9:20
19.01 2:30
23.01 1:15
26.01 8:25
Total 21:30
Total hours worked on grant: 221:30
+1

Thank you for working on this. :)
Post by Paul Johnson
I'm happy to announce that that Christian Walde (Mithaldu) has agreed to
manage the second half of the grant in Florian's stead, and I look
forward to working with him.
Glad to be able to help you with this. :)
Post by Paul Johnson
Then I looked into a couple of cpantesters reports which showed a problem
on Windows. I couldn't repeat the failures, and it seemed that only one
tester had the problem, on version 0.98. Version 0.99 seems not to have
shown any failures, so I'll chalk that up to cosmic rays or something.
I can explain this one.

Older Perls have an odd bug that causes $ENV{PERL5LIB} of over 65k chars
to be completely ignored on Windows 7, resulting in a near-empty @INC.
This happens in his case as he's running an automated smoker which does
not actually install dists, but only saves them to cpan/build and adds
them to PERL5LIB. On windows below 7 this does not happen, as the 65k
limit is correct there and the process won't even start before reaching
the perl interpreter code. On higher Perls the limit is observed properly.

So, if you get spurious errors, check their PERL5LIB:

http://www.cpantesters.org/cpan/report/dfc0a61f-6c90-1014-b3bb-e7381ede6b02

If it's massive, ask the smoker to upgrade to Perl5 16.0 or newer. :)

Related ticket: https://rt.perl.org:443/rt3/Ticket/Display.html?id=87322
Post by Paul Johnson
David Cantrell added JavaScript to filter results in html_basic and sent
me a pull request.
This is pretty cool, is there a reason that wasn't also added to the
default html output?
--
With regards,
Christian Walde
Loading...