bleadperl@28771 breaks Devel::Cover

I tried to CC p5p on the original RT posting but it seems to
me as if
it didn't come through to p5p. Apologies if this ends up as
a
duplicate.

-- 
andreas

-------------------- Start of forwarded message
--------------------
Subject: [rt.cpan.org #24067] AutoReply: bleadperl28771
breaks Devel::Cover 
From: "Bugs in Devel-Cover via RT"
<bug-Devel-Coverrt.cpan.org>
Reply-To: bug-Devel-Coverrt.cpan.org
References: <RT-Ticket-24067rt.cpan.org>
Message-ID:
<rt-3.6.HEAD-3696-1166937888-213.24067-3-0rt.cpan.org>
X-RT-Loop-Prevention: rt.cpan.org
RT-Ticket: rt.cpan.org #24067
RT-Originator: ANDKcpan.org
To: ANDKcpan.org
Date: Sun, 24 Dec 2006 00:24:52 -0500


------------------------------------------------------------
-------------
Since patch 28771 to bleadperl Devel::Cover testsuite fails:

t/acond_or.t                    166   31  7-8 72 121-148
t/adefault_param.t               69   27  7-8 40-41 56-57
59-74

Full test output uploaded to rt.cpan.org as file attachment.


-------------------- End of forwarded message
--------------------

On Sun, Dec 24, 2006 at 10:07:19PM +0100, Andreas J. Koenig
wrote:

> Since patch 28771 to bleadperl Devel::Cover testsuite
fails:

This was Nicholas' change to pp_anonlist and pp_anonhash
which
meant that Devel::Cover no longer recognised [] and {} as
operands which
could never be false.  Thanks for nailing it down to the
specific patch.

I fixed this in my repository a couple of months ago, but
I've not
managed to get a release out in the meantime.  The fix is
http://pjcj.sytes.net/svnweb/Devel::Cover/revision/?r
ev=179

But it seems that very recently something else has changed
which puts
Devel::Cover into a loop somewhere.  I've not tracked it
down yet, but
the last line of Perl encountered is File/Spec/Unix.pm:51:

  if ( $double_slashes_special && $path =~
s{^(//[^/]+)(?:/|z)}{/}s ) {

So perhaps it is something regexp related.  If this tiny
clue rings any
bells anywhere, please give me a shout.  Otherwise, I'll see
what I can
do to fix that, fix some other things, add a bunch of
patches I have and
get a new release out while I have a little time off work.

-- 
Paul Johnson - paulpjcj.net
http://www.pjcj.net

>>>>> On Mon, 25 Dec 2006 21:42:49 +0100,
Paul Johnson <paulpjcj.net> said:

  > On Sun, Dec 24, 2006 at 10:07:19PM +0100, Andreas J.
Koenig wrote:
 >> Since patch 28771 to bleadperl Devel::Cover
testsuite fails:

  > This was Nicholas' change to pp_anonlist and
pp_anonhash which
  > meant that Devel::Cover no longer recognised [] and
{} as operands which
  > could never be false.  Thanks for nailing it down to
the specific patch.

  > I fixed this in my repository a couple of months ago,
but I've not
  > managed to get a release out in the meantime.  The
fix is
  > http://pjcj.sytes.net/svnweb/Devel::Cover/revision/?r
ev=179

Thanks! The repository version passes all tests with
bleadperl for me.

  > But it seems that very recently something else has
changed which puts
  > Devel::Cover into a loop somewhere.  I've not tracked
it down yet, but
  > the last line of Perl encountered is
File/Spec/Unix.pm:51:

  >   if ( $double_slashes_special && $path =~
s{^(//[^/]+)(?:/|z)}{/}s ) {

Do you have a code snippet that exhibits the problem? With a
boolean
function that tells me if the bug is present, I can run a
quick binary
search for you.

-- 
andreas

>>>>> On Tue, 26 Dec 2006 08:17:00 +0100,
andreas.koenig.7os6VVqRfranz.ak.mind.de (Andreas J. Koenig) said:

 >> if ( $double_slashes_special && $path =~
s{^(//[^/]+)(?:/|z)}{/}s ) {

  > Do you have a code snippet that exhibits the problem?
With a boolean
  > function that tells me if the bug is present, I can
run a quick binary
  > search for you.

It turned out that I could tweak the testsuite of CPAN.pm to
run into
a timeout somewhere when the bug is present and to complete
the run
otherwise. I have not tried to find the code that loops, I
just did
the binary search.

I can now point my finger to 29570. Up to 29569 I have
successes, from
29570 up I run into a timeout which probably stands for the
loop that
you describe.

    Change 29570 by davemdavem-monkey on 2006/12/18
00:24:01

            move parser state into new parser object,
PL_parser

    Affected files ...

    ... //depot/perl/MANIFEST#1496 edit
    ... //depot/perl/embedvar.h#231 edit
    ... //depot/perl/intrpvar.h#187 edit
    ... //depot/perl/parser.h#1 add
    ... //depot/perl/perl.h#746 edit
    ... //depot/perl/perlapi.h#153 edit
    ... //depot/perl/perly.c#98 edit
    ... //depot/perl/pod/perlapi.pod#274 edit
    ... //depot/perl/pod/perlintern.pod#59 edit
    ... //depot/perl/toke.c#718 edit

Hope this helps, let me know if I can provide further info,
-- 
andreas

On Tue, Dec 26, 2006 at 02:34:31PM +0100, Andreas J. Koenig
wrote:
> >>>>> On Tue, 26 Dec 2006 08:17:00
+0100, andreas.koenig.7os6VVqRfranz.ak.mind.de (Andreas
J. Koenig) said:
> 
>  >> if ( $double_slashes_special && $path
=~ s{^(//[^/]+)(?:/|z)}{/}s ) {
> 
>   > Do you have a code snippet that exhibits the
problem? With a boolean
>   > function that tells me if the bug is present, I
can run a quick binary
>   > search for you.
> 
> It turned out that I could tweak the testsuite of
CPAN.pm to run into
> a timeout somewhere when the bug is present and to
complete the run
> otherwise. I have not tried to find the code that
loops, I just did
> the binary search.
> 
> I can now point my finger to 29570. Up to 29569 I have
successes, from
> 29570 up I run into a timeout which probably stands for
the loop that
> you describe.
> 
>     Change 29570 by davemdavem-monkey on 2006/12/18
00:24:01
> 
>             move parser state into new parser object,
PL_parser

Thanks again for pointing the finger.  But I don't suppose
you could
make it a patch where I'm more likely to understand what's
going on,
could you?  

Actually, I have trouble seeing what effect the changes Dave
has made
here could be having on Devel::Cover.  I've come up with a
fix, and I
also don't see how this would interact with Dave's patch.

The fix is to not call HvSHAREKEYS_off unless we are in a
threaded Perl.
I had missed the guard on a couple of calls, and this seemed
to be
leading to unpredictable results with a standard run, gdb
and valgrind
having different behaviours.  But I'll admit to not
understanding this
sort of thing particularly well, so this might just be a
change which
masks the real problem.  I also wonder whether the
apparently somewhat
random nature of the problem could have been toying with
your binary
sort.  Or perhaps Dave's patch made the problem more
apparent in some
way.

In any case, the fix is at
http://pjcj.sytes.net/svnweb/Devel::Cover/revision/?r
ev=183 and if you
have the time to test it I'd be very grateful.  Similarly if
anyone has
any insight into the problem based on my ramblings, I'd be
very happy to
be educated.

-- 
Paul Johnson - paulpjcj.net
http://www.pjcj.net

Op een mooie herfstdag (Wednesday 27 December 2006
13:44),schreef  Paul 
Johnson:
> On Tue, Dec 26, 2006 at 02:34:31PM +0100, Andreas J.
Koenig wrote:
> > >>>>> On Tue, 26 Dec 2006 08:17:00
+0100,
> > >>>>> andreas.koenig.7os6VVqRfranz.ak.mind.de (Andreas J. Koenig) said:
> >  >>
> >  >> if ( $double_slashes_special &&
$path =~ s{^(//[^/]+)(?:/|z)}{/}s )
> >  >> {
> >  >>
> >   > Do you have a code snippet that exhibits
the problem? With a boolean
> >   > function that tells me if the bug is
present, I can run a quick
> >   > binary search for you.
> >
> > It turned out that I could tweak the testsuite of
CPAN.pm to run into
> > a timeout somewhere when the bug is present and to
complete the run
> > otherwise. I have not tried to find the code that
loops, I just did
> > the binary search.
> >
> > I can now point my finger to 29570. Up to 29569 I
have successes, from
> > 29570 up I run into a timeout which probably
stands for the loop that
> > you describe.

Does it help that in my weekly coverage-run I see that
t/comp/uproto.t hangs 
from around that time?

That is, I add Devel::Cover to the bleadperl build with
-Dextras (and a prefab 
CPAN::Config) and run the test-suite under Devel::Cover.

A manual run shows the tests run ok, but somewhere in
finishing up it hangs:

Devel::Cover 0.59: 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:
    .t$
Ignoring packages in:
    /does/not/exist
1..39
ok 1
...
ok 38 - $_ is modifiable
ok 39 - my $_ is modifiable
Devel::Cover: Can't find file
"../../lib/Storable.pm": ignored.

HTH +
Good luck,

Abe
-- 
If I knew :Prof
enough to what is supposed to be in the SvIVX
I would knowingly nod my head here.
                                   -- Jarkko Hietaniemi on
p5p 
2002-05-14