Re: Devel::cover bug?
On Wed, Jun 01, 2005 at 03:00:03PM -0700, Kevin Scaldeferri wrote: On Jun 1, 2005, at 2:35 PM, James E Keenan wrote: Kevin Scaldeferri wrote: I'm looking at a bit of output from Devel::Cover that I imagine has to be a bug. I'll try my best to reproduce the HTML output: stmt branch cond sub time code 221862 100 100 _1613639 next if ($line =~ /^\s*[#!]/ || $line =~ /^\s*$/); If you look at the subroutine coverage page, it claims that there is a BEGIN block uncovered at that line. ... nor have I seen an uncovered BEGIN block. But that may just be a side effect of the sort of things I've been doing coverage analysis on. Well, there is no BEGIN block there at all, so that suggests something funny is going on. Certainly. Of course, it's always possible and quite likely that there is a bug in my code somewhere. But there is also a chance that I am conflating two ops, since I have yet to come up with a way to uniquely identify an op (suggestions welcome). You're not running on 5.6.x are you? -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Devel::cover bug?
On Jun 3, 2005, at 1:40 PM, Paul Johnson wrote: Certainly. Of course, it's always possible and quite likely that there is a bug in my code somewhere. But there is also a chance that I am conflating two ops, since I have yet to come up with a way to uniquely identify an op (suggestions welcome). You're not running on 5.6.x are you? No, 5.8.x -kevin
Re: Devel::cover bug?
Kevin Scaldeferri wrote: On Jun 3, 2005, at 1:40 PM, Paul Johnson wrote: Certainly. Of course, it's always possible and quite likely that there is a bug in my code somewhere. But there is also a chance that I am conflating two ops, since I have yet to come up with a way to uniquely identify an op (suggestions welcome). You're not running on 5.6.x are you? No, 5.8.x -kevin As I recall [I may be wrong], some of your snippets were under /5.8.0/... isn't 5.8.2 considered squirrelly (technical term) under Devel::Cover? Perl 5.8.0 and 5.8.1 will give slightly different results to more recent versions due to changes in the op tree. -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: Devel::cover bug?
On Fri, Jun 03, 2005 at 06:56:50PM -0400, Christopher H. Laco wrote: As I recall [I may be wrong], some of your snippets were under /5.8.0/... isn't 5.8.2 considered squirrelly (technical term) under Devel::Cover? Yes, you're right, I do recommend a minimum version of 5.8.2. It would be interesting to see whether the problem remains in something more recent. I wonder too whether 64bits has anything to do with it. Perl 5.8.0 and 5.8.1 will give slightly different results to more recent versions due to changes in the op tree. Actually, the changes are between 5.8.0 and 5.8.1, but I notice the docs are wrong there. They wont be in the next release. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Devel::cover bug?
On Tue, May 31, 2005 at 04:00:12PM -0700, Kevin Scaldeferri wrote: I'm looking at a bit of output from Devel::Cover that I imagine has to be a bug. I'll try my best to reproduce the HTML output: You might find it slightly easier with the textual report (cover -report text), or does the problem only show up under the html report? If you look at the subroutine coverage page, it claims that there is a BEGIN block uncovered at that line. That does sound a little strange. Are you able to produce an example showing this problem? Any insights? Not at the moment, I'm afraid. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Devel::cover bug?
On Jun 1, 2005, at 12:49 AM, Paul Johnson wrote: If you look at the subroutine coverage page, it claims that there is a BEGIN block uncovered at that line. That does sound a little strange. Are you able to produce an example showing this problem? No. In fact, it isn't consistent. Last night it happened in this module. The night before it didn't. The night before that it did. I have a feeling the problem happens semi-consistently somewhere each night, as I always get a couple of these messages: Use of uninitialized value in concatenation (.) or string at /home/kevin/lib/perl5/site_perl/5.8.0/i686-linux-64int/Devel/Cover/ Report/Html_minimal.pm line 530, $in line 213. Use of uninitialized value in concatenation (.) or string at /home/kevin/lib/perl5/site_perl/5.8.0/i686-linux-64int/Devel/Cover/ Report/Html_minimal.pm line 530, $in line 222. Use of uninitialized value in concatenation (.) or string at /home/kevin/lib/perl5/site_perl/5.8.0/i686-linux-64int/Devel/Cover/ Report/Html_minimal.pm line 530, $in line 118. Use of uninitialized value in concatenation (.) or string at /home/kevin/lib/perl5/site_perl/5.8.0/i686-linux-64int/Devel/Cover/ Report/Html_minimal.pm line 530, $in line 64. But, in hundreds of modules, it's hard to find the problem each time. I only spotted this particular case because I knew that the module in question should have 100% coverage. -kevin
Re: Devel::cover bug?
Kevin Scaldeferri wrote: I'm looking at a bit of output from Devel::Cover that I imagine has to be a bug. I'll try my best to reproduce the HTML output: stmt branch cond sub time code 221862 100 100 _1613639 next if ($line =~ /^\s*[#!]/ || $line =~ /^\s*$/); 0 0 0 0 0 0 That _ is actually a thin red line (but no text). If it helps, here's a slightly modified version of the html: I started to write a reply last night, but got sidetracked. But Paul anticipated my suggestion: call 'cover --report=text'. That way, it's the data speaking to you, not the HTML. I've been using Devel::Cover a lot in the past year, both for my own projects and modules and for the Phalanx project. I've never seen the thin red line (but no text) you describe ... [snip] If you look at the subroutine coverage page, it claims that there is a BEGIN block uncovered at that line. ... nor have I seen an uncovered BEGIN block. But that may just be a side effect of the sort of things I've been doing coverage analysis on. I gather that this is your own module that you're testing -- as distinct from a CPAN module. And, lacking the code and tests, we won't be able to reproduce the problem. So here's my sole bright idea: Split that line of code into two, thereby eliminating the 'and' condition. See if the problem continues to crop up in that circumstance. HTH jimk
Re: Devel::cover bug?
On Jun 1, 2005, at 2:35 PM, James E Keenan wrote: Kevin Scaldeferri wrote: I'm looking at a bit of output from Devel::Cover that I imagine has to be a bug. I'll try my best to reproduce the HTML output: stmt branch cond sub time code 221862 100 100 _1613639 next if ($line =~ /^\s*[#!]/ || $line =~ /^\s*$/); If you look at the subroutine coverage page, it claims that there is a BEGIN block uncovered at that line. ... nor have I seen an uncovered BEGIN block. But that may just be a side effect of the sort of things I've been doing coverage analysis on. Well, there is no BEGIN block there at all, so that suggests something funny is going on. -kevin
Re: Devel::cover bug?
On Jun 1, 2005, at 12:49 AM, Paul Johnson wrote: On Tue, May 31, 2005 at 04:00:12PM -0700, Kevin Scaldeferri wrote: I'm looking at a bit of output from Devel::Cover that I imagine has to be a bug. I'll try my best to reproduce the HTML output: You might find it slightly easier with the textual report (cover -report text), or does the problem only show up under the html report? In text, it shows up as 0 subroutine coverage on that line: 118 *** 221862100100 0 1737338 next if ($line =~ /^\s*[#!]/ || $line =~ /^\s*$/); *** 0 0 *** 0 0 *** 0 0 Uncovered Subroutines - Subroutine Count Location -- -- - BEGIN XXX.pm:118 And warning messages like: Use of uninitialized value in concatenation (.) or string at /home/kevin/lib/perl5/site_perl/5.8.0/i686-linux-64int/Devel/Cover/ Report/Text.pm line 235. Use of uninitialized value in concatenation (.) or string at /home/kevin/lib/perl5/site_perl/5.8.0/i686-linux-64int/Devel/Cover/ Report/Text.pm line 235. Use of uninitialized value in concatenation (.) or string at /home/kevin/lib/perl5/site_perl/5.8.0/i686-linux-64int/Devel/Cover/ Report/Text.pm line 235. Use of uninitialized value in concatenation (.) or string at /home/kevin/lib/perl5/site_perl/5.8.0/i686-linux-64int/Devel/Cover/ Report/Text.pm line 235. -kevin
Re: Devel::Cover bug
On Sat, Jun 26, 2004 at 08:41:08PM -0400, Vsevolod (Simon) Ilyushchenko wrote: The problem occurs because Devel::Cover overrides some of B::Deparse's subs, but when you go calling them in a program it gets upset. The solution is to only override the subs for as long as is necessary. The change is in my development copy and will be in the next release. Muchas gracias! I am looking formard to using Devel::Cover on my testing classes (the offending code occured in the Test::Unit framework). Sounds good. I've just released 0.47 with this fix in it, so let me know if there are any other problems. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Devel::Cover bug
Hi,
I've run into Can't call method add_statement on an undefined value
running Devel::Cover. Apologies if this was reported before, but the
list archive is not searchable. I am using perl 5.8.4 and Devel::Cover 0.46.
To reproduce the bug, run
/opt/perl/bin/perl -MDevel::Cover -MFooBar -e FooBar-new-test_foo
The files FooBar.pm and CodeRef.pm are attached.
The bug occurs while calling $sub in CodeRef::to_string. It is probably
related to using B::Deparse, but I was not able to minimize the code
further and still reproduce the error.
Simon
--
Simon (Vsevolod ILyushchenko) [EMAIL PROTECTED]
http://www.simonf.com
Terrorism is a tactic and so to declare war on terrorism
is equivalent to Roosevelt's declaring war on blitzkrieg.
Zbigniew Brzezinski, U.S. national security advisor, 1977-81
package FooBar;
sub new {
my $proto = shift;
my $self = {};
bless $self, $proto;
return $self;
}
use CodeRef;
my $sub = sub {
my $str1 = shift;
};
my $assertion = CodeRef-new($sub);
*{FooBar::test_foo} =
sub {
my $self = shift;
$assertion-do_assertion(@_);
};
1;
package CodeRef;
use strict;
sub new {
my $class = shift;
my $code = shift;
bless \$code = $class;
}
sub do_assertion {
my $self = shift;
$self-to_string(aaa);
}
sub to_string {
my $self = shift;
require B::Deparse;
my $deparser ||= B::Deparse-new(-p);
$deparser-coderef2text($$self);
}
1;
Devel::Cover bug in ActiveState Perl for *Linux*
After much research, I've managed to reduce a Devel::Cover bug down to a one-liner
which only
fails on one box. This box is unique because it's ActiveState Perl for Linux (not my
choice!).
However, that might be a red herring. My 'perl -V' is below the test case. Does
anyone have a
similar setup which they can check this against?
--
$ perl -MDevel::Cover -e 'local *{foo} = sub {}'
Devel::Cover 0.26: Collecting coverage data for branch, condition, statement,
subroutine and time.
Pod coverage is unvailable. Please install Pod::Coverage from CPAN.
Selecting packages matching:
Ignoring packages matching:
Ignoring packages in:
.
/dp/usr/cxp/perl/lib
/usr/local/lib/perl5/site_perl
/usr/local/lib/perl5/site_perl/5.6.1
/usr/local/lib/perl5/site_perl/5.6.1/i686-linux-multi
/usr/local/stow/perl-5.6.1-a633/lib/perl5/5.6.1
/usr/local/stow/perl-5.6.1-a633/lib/perl5/5.6.1/i686-linux-multi
/usr/local/stow/perl-5.6.1-a633/lib/perl5/site_perl
/usr/local/stow/perl-5.6.1-a633/lib/perl5/site_perl/5.6.1
/usr/local/stow/perl-5.6.1-a633/lib/perl5/site_perl/5.6.1/i686-linux-multi
Can't locate object method find_cv via package B::SPECIAL (perhaps you forgot to
load
B::SPECIAL?) at
/usr/local/stow/perl-5.6.1-a633/lib/perl5/5.6.1/i686-linux-multi/B.pm line 213.
END failed--call queue aborted.
--
And the Perl -V
--
$ perl -V
Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
Platform:
osname=linux, osvers=2.4.9-e.3, archname=i686-linux-multi
uname='linux bulkmailer 2.4.9-e.3 #1 fri may 3 17:02:43 edt 2002 i686 unknown '
config_args='-d -O -Dinstallstyle=lib/perl5
-Dprefix=/usr/local/stow/perl-5.6.1-a633
-Uinstallusrbinperl -Dd_dosuid=define -Dotherlibdirs=/usr/local/lib/perl5/site_perl
-Dusemultiplicity'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=define
useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
Compiler:
cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64',
optimize='-O2',
cppflags='-fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='2.96 2731 (Red Hat Linux 7.2 2.96-108.1)',
gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, usemymalloc=n, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lgdbm -ldb -ldl -lm -lc -lcrypt -lutil
perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil
libc=/lib/libc-2.2.4.so, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY USE_LARGE_FILES PERL_IMPLICIT_CONTEXT
Locally applied patches:
ActivePerl Build 633
Built under linux
Compiled at Mar 24 2003 17:43:39
%ENV:
PERL5LIB=/dp/usr/cxp/perl/lib
@INC:
/dp/usr/cxp/perl/lib/i686-linux-multi
/dp/usr/cxp/perl/lib
/usr/local/stow/perl-5.6.1-a633/lib/perl5/5.6.1/i686-linux-multi
/usr/local/stow/perl-5.6.1-a633/lib/perl5/5.6.1
/usr/local/stow/perl-5.6.1-a633/lib/perl5/site_perl/5.6.1/i686-linux-multi
/usr/local/stow/perl-5.6.1-a633/lib/perl5/site_perl/5.6.1
/usr/local/stow/perl-5.6.1-a633/lib/perl5/site_perl
/usr/local/lib/perl5/site_perl/5.6.1/i686-linux-multi
/usr/local/lib/perl5/site_perl/5.6.1
/usr/local/lib/perl5/site_perl
--
Any ideas on where to look next?
Cheers,
Ovid
=
Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm
Ovid http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
Re: Devel::Cover bug in ActiveState Perl for *Linux*
FYI: I've managed to replicate this error on another ActiveState Perl linux box. The Perl -V information is the same, but the module list is quite a bit smaller. The only common element that I can find is ActiveState. Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/ __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
Re: Devel::Cover bug in ActiveState Perl for *Linux*
On Mon, Oct 13, 2003 at 01:49:58PM -0700, Ovid wrote: After much research, I've managed to reduce a Devel::Cover bug down to a one-liner which only fails on one box. This box is unique because it's ActiveState Perl for Linux (not my choice!). However, that might be a red herring. My 'perl -V' is below the test case. Does anyone have a similar setup which they can check this against? I think the key is that it is perl version 5.6.1. I can reproduce the problem on a stock 5.6.1 on linux (well, hacked just enough to get it to build). Is there any chance that we can just say it is a bug in 5.6.1 that has been fixed? I think that is actually the case. Devel::Cover uses the B modules which were still a little immature in 5.6.1. The test works (in that the bug does not show) for 5.8.0, 5.8.1, maintperl and bleadperl. Actually, I wonder whether 5.6.1 should be supported or not. It generally works, but then you get cases like this. The results are also different between different versions of perl, and often it is 5.6.1 and the rest. But this is a problem which will only get worse. In any case, thanks a lot for tracking this down. I'm sure it wasn't trivial. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Devel::Cover bug in ActiveState Perl for *Linux*
--- Paul Johnson [EMAIL PROTECTED] wrote: I think the key is that it is perl version 5.6.1. I can reproduce the problem on a stock 5.6.1 on linux (well, hacked just enough to get it to build). Hmmm ... I saw this *after* my second ActiveState email. Actually, I wonder whether 5.6.1 should be supported or not. I think that 5.6.1 is widespread enough that you might lose much of your intended audience if it's not supported. I know that I currently have a project at work that involves code coverage stats, but this is part of our plan to migrate to 5.8.1. We don't *need* this information, but it would be very helpful. In any case, thanks a lot for tracking this down. I'm sure it wasn't trivial. Not a problem. Devel::Cover has been part of my plan for fixing some serious problems at work. I've been hoping to use to help us figure out how much old code we have so we can delete it and start refactoring from a cleaner code base. I'll dig some more and see if I can come up with a workaround. Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/ __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
