ex-PVBM and mro interact badly

Running this script

    use constant PVBM => 'foo';
    index 'foo', PVBM;
    my %h = ( a => PVBM );

with blead32107 causes an assertion failure:

    Assertion ((((shplep)->sv_flags &
(0x00004000|0x00008000)) ==
    0x00008000) && (((svtype)((shplep)->sv_flags
& 0xff)) == SVt_PVGV ||
    ((svtype)((shplep)->sv_flags & 0xff)) ==
SVt_PVLV)) failed: file
    "hv.c", line 1453.

This patch appears to fix the problem, though I'm not sure
what to do
about the fact that the test will never fail: perl will die
instead. The
eval doesn't seem to catch it.

Ben

diff -ur perl-current/hv.c perl-current-pvbm/hv.c
--- perl-current/hv.c	Wed Sep 26 11:24:23 2007
+++ perl-current-pvbm/hv.c	Mon Oct 15 21:28:30 2007
 -1450,7
+1450,7 
     if (!entry)
 	return;
     val = HeVAL(entry);
-    if (val && isGV(val) && GvCVu(val)
&& HvNAME_get(hv))
+    if (val && isGV(val) &&
isGV_with_GP(val) && GvCVu(val) &&
HvNAME_get(hv))
         mro_method_changed_in(hv);	/* deletion of method
from stash */
     SvREFCNT_dec(val);
     if (HeKLEN(entry) == HEf_SVKEY) {
diff -ur perl-current/t/op/hash.t
perl-current-pvbm/t/op/hash.t
--- perl-current/t/op/hash.t	Mon Sep 17 23:35:50 2007
+++ perl-current-pvbm/t/op/hash.t	Mon Oct 15 21:55:11 2007
 -8,7
+8,7 
 
 use strict;
 
-plan tests => 5;
+plan tests => 6;
 
 my %h;
 
 -109,3
+109,12 
     $u += $u << 15; $u %= MASK_U32;
     $u;
 }
+
+# This will crash perl if it fails
+
+use constant PVBM => 'foo';
+
+my $dummy = index 'foo', PVBM;
+eval { my %h = (a => PVBM); 1 };
+
+ok (!$, 'fbm scalar can be inserted into a hash');

On 10/15/07, Ben Morrow <benmorrow.me.uk> wrote:
> Running this script
>
>     use constant PVBM => 'foo';
>     index 'foo', PVBM;
>     my %h = ( a => PVBM );
>
> with blead32107 causes an assertion failure:
>
>     Assertion ((((shplep)->sv_flags &
(0x00004000|0x00008000)) ==
>     0x00008000) &&
(((svtype)((shplep)->sv_flags & 0xff)) == SVt_PVGV
||
>     ((svtype)((shplep)->sv_flags & 0xff)) ==
SVt_PVLV)) failed: file
>     "hv.c", line 1453.
>
> This patch appears to fix the problem, though I'm not
sure what to do
> about the fact that the test will never fail: perl will
die instead. The
> eval doesn't seem to catch it.

There is a class of error that perl cant catch, such as seg
faults and
serious errors like that. In the case of the regex engine we
have a
section at the end of the test file t/op/pat.t that says
something
like:

# Tests that can segfault perl go after here so that we test
as much
as we can before crash

Which seems to work out well enough, except when people just
blindly
stick new tests at the bottom of the file. So we solve that
with a
comment like

# New tests should go above the comment about tests that can
segv perl.

at the bottom of the file.

Sticking the test count in a begin block just above the the
first
comment or right at the end of the file seems to help as
well.

Yves


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Quoth demerphqgmail.com (demerphq):
> On 10/15/07, Ben Morrow <benmorrow.me.uk> wrote:
> >
> > This patch appears to fix the problem, though I'm
not sure what to do
> > about the fact that the test will never fail: perl
will die instead. The
> > eval doesn't seem to catch it.
> 
> There is a class of error that perl cant catch, such as
seg faults and
> serious errors like that. In the case of the regex
engine we have a
> section at the end of the test file t/op/pat.t that
says something
> like:
> 
> # Tests that can segfault perl go after here so that we
test as much
> as we can before crash

Would it be worth the effort of running tests like this in a
subprocess,
and testing $? ?

Ben

On 10/16/07, Ben Morrow <benmorrow.me.uk> wrote:
>
> Quoth demerphqgmail.com (demerphq):
> > On 10/15/07, Ben Morrow <benmorrow.me.uk> wrote:
> > >
> > > This patch appears to fix the problem, though
I'm not sure what to do
> > > about the fact that the test will never fail:
perl will die instead. The
> > > eval doesn't seem to catch it.
> >
> > There is a class of error that perl cant catch,
such as seg faults and
> > serious errors like that. In the case of the regex
engine we have a
> > section at the end of the test file t/op/pat.t
that says something
> > like:
> >
> > # Tests that can segfault perl go after here so
that we test as much
> > as we can before crash
>
> Would it be worth the effort of running tests like this
in a subprocess,
> and testing $? ?

I guess if you can do it portably then maybe so. But, er,
well,
considering these tend to be "this really shouldnt ever
happen" type
bugs then its probably not worth the effort.

Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

On Tue, Oct 16, 2007 at 04:55:12PM +0200, demerphq wrote:
> On 10/16/07, Ben Morrow <benmorrow.me.uk> wrote:
> >
> > Quoth demerphqgmail.com (demerphq):
> > > On 10/15/07, Ben Morrow <benmorrow.me.uk> wrote:
> > > >
> > > > This patch appears to fix the problem,
though I'm not sure what to do
> > > > about the fact that the test will never
fail: perl will die instead. The
> > > > eval doesn't seem to catch it.
> > >
> > > There is a class of error that perl cant
catch, such as seg faults and
> > > serious errors like that. In the case of the
regex engine we have a
> > > section at the end of the test file
t/op/pat.t that says something
> > > like:
> > >
> > > # Tests that can segfault perl go after here
so that we test as much
> > > as we can before crash
> >
> > Would it be worth the effort of running tests like
this in a subprocess,
> > and testing $? ?
> 
> I guess if you can do it portably then maybe so. But,
er, well,
> considering these tend to be "this really shouldnt
ever happen" type
> bugs then its probably not worth the effort.

Traditionally this has been done using the runperl()
function and
similar from t/test.pl, although I tend not to bother these
days.

-- 
This is a great day for France!
    -- Nixon at Charles De Gaulle's funeral

This

    #!/usr/bin/perl

    sub PVBM () { 'foo' }
    index "foo", PVBM;

    $x = PVBM;

    my $str = 'foo';
    my $pvlv = substr $str, 0, 1;

    $x = $pvlv;

    __END__

causes (the same) assertion failure in glob_assign_ref,
which it should
never have got to in the first place. The patch below
appears to fix it.

Ben

diff -ur perl-current/sv.c perl-current-pvbm/sv.c
--- perl-current/sv.c	Sat Oct  6 22:32:11 2007
+++ perl-current-pvbm/sv.c	Tue Oct 16 18:20:31 2007
 -3536,7
+3536,7 
 	}
 
 	if (dtype >= SVt_PV) {
-	    if (dtype == SVt_PVGV) {
+	    if (dtype == SVt_PVGV && isGV_with_GP(dstr))
{
 		glob_assign_ref(dstr, sstr);
 		return;
 	    }
diff -ur perl-current/t/op/lex_assign.t
perl-current-pvbm/t/op/lex_assign.t
--- perl-current/t/op/lex_assign.t	Tue Jun 13 20:29:32 2006
+++ perl-current-pvbm/t/op/lex_assign.t	Tue Oct 16 18:41:09
2007
 -24,7
+24,7 
 
 INPUT = <DATA>;
 simple_input = grep /^s*w+s*$w+s*[#n]/, INPUT;
-print "1..", (10 + INPUT + simple_input), "n";
+print "1..", (11 + INPUT + simple_input), "n";
 $ord = 0;
 
 sub wrn {"_"}
 -170,6
+170,25 
     }
   }
 }
+
+$ord++;
+eval {
+    sub PVBM () { 'foo' }
+    index 'foo', PVBM;
+    my $x = PVBM;
+
+    my $str = 'foo';
+    my $pvlv = substr $str, 0, 1;
+    $x = $pvlv;
+
+    1;
+};
+if ($) {
+    warn "# $";
+    print 'not ';
+}
+print "ok $ordn";
+
 __END__
 ref $xref			# ref
 ref $cstr			# ref nonref

On 15/10/2007, Ben Morrow <benmorrow.me.uk> wrote:
> Running this script
>
>     use constant PVBM => 'foo';
>     index 'foo', PVBM;
>     my %h = ( a => PVBM );
>
> with blead32107 causes an assertion failure:
>
>     Assertion ((((shplep)->sv_flags &
(0x00004000|0x00008000)) ==
>     0x00008000) &&
(((svtype)((shplep)->sv_flags & 0xff)) == SVt_PVGV
||
>     ((svtype)((shplep)->sv_flags & 0xff)) ==
SVt_PVLV)) failed: file
>     "hv.c", line 1453.
>
> This patch appears to fix the problem, though I'm not
sure what to do
> about the fact that the test will never fail: perl will
die instead. The
> eval doesn't seem to catch it.

Thanks, applied as #32119

On 16/10/2007, Ben Morrow <benmorrow.me.uk> wrote:
> This
>
>     #!/usr/bin/perl
>
>     sub PVBM () { 'foo' }
>     index "foo", PVBM;
>
>     $x = PVBM;
>
>     my $str = 'foo';
>     my $pvlv = substr $str, 0, 1;
>
>     $x = $pvlv;
>
>     __END__
>
> causes (the same) assertion failure in glob_assign_ref,
which it should
> never have got to in the first place. The patch below
appears to fix it.

Thanks, applied as #32121.

I haven't bothered either.  If the test passes, then the
Perl core has
been fixed.  If it core dumps, the tests will fail.  I don't
know that
the extra work is necessary.

Steve Peters
stevefisharerojo.org

On 10/16/07, Dave Mitchell <davemiabyn.com> wrote:
> On Tue, Oct 16, 2007 at 04:55:12PM +0200, demerphq
wrote:
> > On 10/16/07, Ben Morrow <benmorrow.me.uk> wrote:
> > >
> > > Quoth demerphqgmail.com (demerphq):
> > > > On 10/15/07, Ben Morrow <benmorrow.me.uk> wrote:
> > > > >
> > > > > This patch appears to fix the
problem, though I'm not sure what to do
> > > > > about the fact that the test will
never fail: perl will die instead. The
> > > > > eval doesn't seem to catch it.
> > > >
> > > > There is a class of error that perl cant
catch, such as seg faults and
> > > > serious errors like that. In the case of
the regex engine we have a
> > > > section at the end of the test file
t/op/pat.t that says something
> > > > like:
> > > >
> > > > # Tests that can segfault perl go after
here so that we test as much
> > > > as we can before crash
> > >
> > > Would it be worth the effort of running tests
like this in a subprocess,
> > > and testing $? ?
> >
> > I guess if you can do it portably then maybe so.
But, er, well,
> > considering these tend to be "this really
shouldnt ever happen" type
> > bugs then its probably not worth the effort.
>
> Traditionally this has been done using the runperl()
function and
> similar from t/test.pl, although I tend not to bother
these days.
>
> --
> This is a great day for France!
>     -- Nixon at Charles De Gaulle's funeral
>