Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[perl #41897] [BUG]: Parrot::Pmc2c::STMRef gets 'subroutine prederef redefined' warning

3 views
Skip to first unread message

James Keenan

unread,
Mar 18, 2007, 2:08:24 PM3/18/07
to bugs-bi...@rt.perl.org
# New Ticket Created by James Keenan
# Please include the string: [perl #41897]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41897 >


I've found through experience that running Devel::Cover to perform
coverage analysis on my code sometimes turns up problems that don't
appear when running 'prove' or 'make test' without Devel::Cover.

This was the case just now when, for the first time in a couple of
months, I ran coverage analysis on Parrot::Pmc2c::Utils and its
associated test suite, t/tools/pmc2cutils/*.t. See attached file.

Note the warning, "Subroutine prederef redefined at Users/jimk/work/
fresh/t/tools/pmc2cutils/../../../lib/Parrot/Pmc2c/STMRef.pm line
10." This occurs in each of the 8 files in the test suite. It
*only* appears when I'm running prove with Devel::Cover:

PERL5OPT=-MDevel::Cover=-db,coverage/pmc2c prove t/tools/
pmc2cutils/*.t "$@"

It does *not* appear when I run:

prove -v t/tools/pmc2cutils/*.t

These warnings do not impede any test from passing. But where
there's smoke ....

The facts that this warning (a) did not appear when I was running
coverage analysis on this code back in November and December (b)
occurs in each test file suggest that the offending line is:

use Parrot::Pmc2c::PMETHODs;

... because that was put into Parrot::Pmc2c::Utils since I last
worked on it. But I haven't yet looked into PMETHODs to see how it
relates to STMRef.

Googling for 'Subroutine prederef redefined' turns up 0 exact
matches, but the closest match refers to Parrot.

Ideas?

Thank you very much.
kid51


Parrot.Pmc2c.STMRef.subroutine.redefined.warning.txt

Paul Johnson

unread,
May 1, 2007, 7:13:00 AM5/1/07
to perl6-i...@perl.org
On Sun, Mar 18, 2007 at 11:08:24AM -0700, James Keenan wrote:

[ I've just noticed this via a summary that I rescued from
spamassassin's rather overenthusiastic clutches. Thanks Ann. ]

> I've found through experience that running Devel::Cover to perform
> coverage analysis on my code sometimes turns up problems that don't
> appear when running 'prove' or 'make test' without Devel::Cover.

[ snip details ]

> Ideas?

Not really, I'm afraid. I don't think I've seen a similar problem with
Devel::Cover and any other code. Devel::Cover has sometimes uncovered
questionable constructs that have otherwise gone unnoticed, but my first
thoughts would be that it was a bug in Devel::Cover.

Has anyone managed to shine any additional light on this in the last six
weeks?

--
Paul Johnson - pa...@pjcj.net
http://www.pjcj.net

James Keenan via RT

unread,
May 1, 2007, 10:25:24 PM5/1/07
to perl6-i...@perl.org
More research.

1. Here is the output of a recent run in trunk of coverage analysis on the code underlying
tools/build/pmc2c.pl:

[parrot] 517 $ PERL5OPT=-MDevel::Cover=-db,coverage/pmc2c prove t/tools/pmc2cutils/*.t
"$@"
t/tools/pmc2cutils/00-qualify........Devel::Cover: Can't open -e for MD5 digest: No such file
or directory
t/tools/pmc2cutils/00-qualify........ok 1/10Subroutine prederef redefined at /Users/jimk/
work/parrot/t/tools/pmc2cutils/../../../lib/Parrot/Pmc2c/STMRef.pm line 10.
Subroutine raw_deref redefined at /Users/jimk/work/parrot/t/tools/pmc2cutils/../../../lib/
Parrot/Pmc2c/STMRef.pm line 34.
t/tools/pmc2cutils/00-qualify........ok
t/tools/pmc2cutils/01-pmc2cutils.....ok 1/26Subroutine prederef redefined at /Users/jimk/
work/parrot/lib/Parrot/Pmc2c/STMRef.pm line 10.
Subroutine raw_deref redefined at /Users/jimk/work/parrot/lib/Parrot/Pmc2c/STMRef.pm
line 34.
t/tools/pmc2cutils/01-pmc2cutils.....ok
t/tools/pmc2cutils/02-find_file......ok 1/7Subroutine prederef redefined at /Users/jimk/
work/parrot/lib/Parrot/Pmc2c/STMRef.pm line 10.
Subroutine raw_deref redefined at /Users/jimk/work/parrot/lib/Parrot/Pmc2c/STMRef.pm
line 34.
t/tools/pmc2cutils/02-find_file......ok
t/tools/pmc2cutils/03-dump_vtable....ok 9/12Subroutine prederef redefined at /Users/jimk/
work/parrot/lib/Parrot/Pmc2c/STMRef.pm line 10.
Subroutine raw_deref redefined at /Users/jimk/work/parrot/lib/Parrot/Pmc2c/STMRef.pm
line 34.
t/tools/pmc2cutils/03-dump_vtable....ok
t/tools/pmc2cutils/04-dump_pmc.......ok 113/117Subroutine prederef redefined at /Users/
jimk/work/parrot/lib/Parrot/Pmc2c/STMRef.pm line 10.
Subroutine raw_deref redefined at /Users/jimk/work/parrot/lib/Parrot/Pmc2c/STMRef.pm
line 34.
t/tools/pmc2cutils/04-dump_pmc.......ok
t/tools/pmc2cutils/05-gen_c..........ok 66/68Subroutine prederef redefined at /Users/jimk/
work/parrot/lib/Parrot/Pmc2c/STMRef.pm line 10.
Subroutine raw_deref redefined at /Users/jimk/work/parrot/lib/Parrot/Pmc2c/STMRef.pm
line 34.
t/tools/pmc2cutils/05-gen_c..........ok
t/tools/pmc2cutils/06-print_tree.....ok 33/55Subroutine prederef redefined at /Users/jimk/
work/parrot/lib/Parrot/Pmc2c/STMRef.pm line 10.
Subroutine raw_deref redefined at /Users/jimk/work/parrot/lib/Parrot/Pmc2c/STMRef.pm
line 34.
t/tools/pmc2cutils/06-print_tree.....ok
t/tools/pmc2cutils/07-open_file......ok 1/23Subroutine prederef redefined at /Users/jimk/
work/parrot/lib/Parrot/Pmc2c/STMRef.pm line 10.
Subroutine raw_deref redefined at /Users/jimk/work/parrot/lib/Parrot/Pmc2c/STMRef.pm
line 34.
t/tools/pmc2cutils/07-open_file......ok
All tests successful.
Files=8, Tests=318, 132 wallclock secs (109.62 cusr + 9.16 csys = 118.78 CPU)

2. Here is the output of 'ack prederef lib/Parrot/':

lib/Parrot/OpTrans/CGP.pm:11:C<Parrot::OpTrans::CGoto> to provide predereferenced
register addressing
lib/Parrot/OpTrans/CGP.pm:70:# define opcode_to_prederef(i, op) \\
lib/Parrot/OpTrans/CGP.pm:94: goto **(cur_opcode = opcode_to_prederef(interp, $addr))";
lib/Parrot/OpTrans/CGP.pm:121: return "goto **(cur_opcode = opcode_to_prederef(interp,
lib/Parrot/OpTrans/CPrederef.pm:12:to provide basic functionality for predereferenced run
loops (switch,
lib/Parrot/OpTrans/CPrederef.pm:39:#define REL_PC ((size_t)(cur_opcode - interp->code-
>prederef.code))
lib/Parrot/OpTrans/CPrederef.pm:69: return "opcode_to_prederef(interp, $addr)";
lib/Parrot/OpTrans/CPrederef.pm:79: return "opcode_to_prederef(interp, pop_dest
(interp))";
lib/Parrot/OpTrans/CSwitch.pm:11:to provide a mixture of predereferenced register
addressing and a
lib/Parrot/OpTrans/CSwitch.pm:78:# define opcode_to_prederef(i, op) (op ? \\
lib/Parrot/OpTrans/CSwitch.pm:112: cur_opcode = opcode_to_prederef(interp,
$addr);
lib/Parrot/OpTrans/CSwitch.pm:141: cur_opcode = opcode_to_prederef(interp,
dest);
lib/Parrot/OpTrans.pm:86:C<opcode_t>, but the prederef runops core uses an array of
C<void*> to
lib/Parrot/Pmc2c/Ref.pm:25:=item C<prederef($method)>
lib/Parrot/Pmc2c/Ref.pm:32:sub prederef {
lib/Parrot/Pmc2c/Ref.pm:88: my $pre = $self->prederef($method);
lib/Parrot/Pmc2c/SharedRef.pm:13:=item C<prederef($method)>
lib/Parrot/Pmc2c/SharedRef.pm:20:sub prederef {
lib/Parrot/Pmc2c/StmRef.pm:10:sub prederef {

3. Here is the output of 'ack raw_deref lib/Parrot/':

lib/Parrot/Pmc2c/Ref.pm:47:=item C<raw_deref($method)>
lib/Parrot/Pmc2c/Ref.pm:54:sub raw_deref {
lib/Parrot/Pmc2c/Ref.pm:90: my $deref = $self->raw_deref($method);
lib/Parrot/Pmc2c/StmRef.pm:34:sub raw_deref {

Would the warnings emitted while running 'prove' with Devel::Cover be due to the fact that
both Parrot::Pmc2c::Ref and Parrot::Pmc2c::StmRef define prederef() and raw_deref() -- and
that the latter inherits from the former?

[parrot] 520 $ rhead lib/Parrot/Pmc2c/StmRef.pm
package Parrot::Pmc2c::STMRef;
use base 'Parrot::Pmc2c::Ref';

ack.prederef.lib.Parrot.txt

James Keenan via RT

unread,
Aug 25, 2007, 1:22:49 PM8/25/07
to perl6-i...@perl.org
I haven't gotten these warnings when doing coverage analysis for several
months. So we can close this ticket.

James Keenan via RT

unread,
Sep 23, 2007, 9:09:30 AM9/23/07
to perl6-i...@perl.org
On Sat Aug 25 10:22:49 2007, jk...@verizon.net wrote:
> I haven't gotten these warnings when doing coverage analysis for several
> months. So we can close this ticket.

It turns out that the reason I haven't been getting these warnings is
that I wasn't looking for them -- in a manner of speaking.

In recent months I haven't been running coverage analysis on my iBook
because it's so much slower than my Linux server. For unknown reason, I
was also not getting those warnings on Linux. So I closed the ticket,
not realizing that the fact that I wasn't getting the warnings was that
I wasn't doing the coverage analysis on the box that was generating them!

Last night I ran coverage analysis on the iBook for the first time in
months and got all these warnings. So I'm re-opening the ticket.

But there's another problem lurking here. As I recently posted on the
perl.qa mailing list (http://tinyurl.com/36zssb), I've been experiencing
problems using Devel::Cover with my configuration tests. It will work
perfectly for a week or so, then start to have individual test files
return this result:

t/configure/028-option_or_data....................dubious
Test returned status 0 (wstat 11, 0xb)
after all the subtests completed successfully

Problems: (1) This causes the coverage analysis to fail. And since the
first step is 'cover -delete', all coverage results currently existing
on my server get wiped out. (2) Such a test file always passes when run
without Devel::Cover. When I open up such a test file to look at it, I
can occasionally fix it thru voodoo code, e.g., adding one test
(pass("Keep Devel::Cover happy");) that doesn't really add anything to
the test but seems to shut off the problem cited above. (3) Sometimes
I'll fix the problem on one file, only to have the problem suddenly crop
up on the next test file or another file later in the test suite.

So this was one of those problems that are so maddening because they
appear to be intermittent.

But yesterday I noticed two things: (1) When the problems did occur,
they never occurred any earlier in the test suite than the test cited
above: t/configure/028-option_or_data.t. (2) That same file was the
first one on which (yesterday, at least) I got the "subroutine
redefined" warning.

Upon inspection, I realized that 028 was also the first file in the test
suite sequence to use a testing function I wrote,
Parrot::Configure::Test::test_step_thru_runstep(). When you go to test
certain configuration steps, you cannot do so unless you know the
results of earlier configuration steps. test_step_thru_runstep() runs a
simulation of those steps.

So I'm hypothesizing that something in test_step_thru_runstep() (a)
generates at least some of the 'subroutine redefined' warnings I get
when I do coverage analysis on the iBook; and (b) underlies the 'Test
returned status 0' error which is borking my coverage analysis on Linux.

kid51

James Keenan via RT

unread,
Dec 29, 2007, 9:57:30 PM12/29/07
to perl6-i...@perl.org
I'm closing this ticket for a number of reasons.

1. The "subroutine redefined" problem -- the original focus of the RT
-- is, I think, largely a Devel::Cover problem. More of an annoyance
than anything else.

2. The other problem I discussed -- the spurious test failures while
running Devel::Cover -- has been addressed in 2 ways: (i) I put an
extra 'pass' test at the end of many files. This seems to keep
Devel::Cover happy. (ii) I think that many of the problems occurred
when using Parrot::IO::Capture::Mini to capture STDOUT and STDERR. That
module did so via tied filehandles. Since we've moved to
IO::CaptureOutput::capture() for that purpose, I haven't seen any of
those spurious test failures while conducting coverage analysis. And,
as I'm writing new tests that use IO::CaptureOutput, I'm omitting the
'keep Devel::Cover happy' test and living to tell about it.

3. The ticket is old and stale and I'm sick of looking at it.

kid51

0 new messages