Assertion Failure: Perl_sv_grow (sv.c:1587)

[p5pRT]

Migrated from rt.perl.org#129300 (status was 'resolved')

Searchable as RT129300$

[p5pRT]

From @geeknik

Triggered in Perl v5.25.5 (v5.25.4-130-g7aa7bbc).

./perl -e '$^D=X^S^C,map%​::,​::​::'

perl​: sv.c​:1587​: char *Perl_sv_grow(SV *const, STRLEN)​: Assertion `!((((_svcur)->sv_flags & (0x00004000|0x00008000)) == 0x00008000) && (((svtype)((_svcur)->sv_flags & 0xff)) == SVt_PVGV || ((svtype)((_svcur)->sv_flags & 0xff)) == SVt_PVLV))' failed.

[p5pRT]

From @cpansprout

On Sun Sep 18 12​:43​:57 2016, brian.carpenter@​gmail.com wrote​:

Triggered in Perl v5.25.5 (v5.25.4-130-g7aa7bbc).

./perl -e '$^D=X^S^C,map%​::,​::​::'

perl​: sv.c​:1587​: char *Perl_sv_grow(SV *const, STRLEN)​: Assertion
`!((((_svcur)->sv_flags & (0x00004000|0x00008000)) == 0x00008000) &&
(((svtype)((_svcur)->sv_flags & 0xff)) == SVt_PVGV ||
((svtype)((_svcur)->sv_flags & 0xff)) == SVt_PVLV))' failed.

Slightly less exotic​:

$ ./perl -DH -e 'map %​::, "​::​::"'

About a tenth of the time it gives me​:

  Modification of a read-only value attempted at -e line 1.

instead of​:

  Assertion failed​: (!isGV_with_GP(_svcur)), function Perl_sv_grow, file sv.c, line 1587.

That may be due to hash randomisation.

--

Father Chrysostomos

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @iabyn

On Sun, Sep 18, 2016 at 09​:51​:32PM -0700, Father Chrysostomos via RT wrote​:

On Sun Sep 18 12​:43​:57 2016, brian.carpenter@​gmail.com wrote​:

Triggered in Perl v5.25.5 (v5.25.4-130-g7aa7bbc).

./perl -e '$^D=X^S^C,map%​::,​::​::'

perl​: sv.c​:1587​: char *Perl_sv_grow(SV *const, STRLEN)​: Assertion
`!((((_svcur)->sv_flags & (0x00004000|0x00008000)) == 0x00008000) &&
(((svtype)((_svcur)->sv_flags & 0xff)) == SVt_PVGV ||
((svtype)((_svcur)->sv_flags & 0xff)) == SVt_PVLV))' failed.

Slightly less exotic​:

$ ./perl -DH -e 'map %​::, "​::​::"'

About a tenth of the time it gives me​:

Modification of a read\-only value attempted at \-e line 1\.

instead of​:

Assertion failed​: \(\!isGV\_with\_GP\(\_svcur\)\)\, function Perl\_sv\_grow\, file sv\.c\, line 1587\.

That may be due to hash randomisation.

-DH is very weird. DEBUG_H is used in exactly one place in core,
Perl_do_kv(), where for each hash entry value it pushes on the stack (via
values(%h), or %h in list context), it replaces the value with a string
containing debugging info about the entry​:

  while ((entry = hv_iternext(keys))) {
  if (dokeys) {
  SV* const sv = hv_iterkeysv(entry);
  XPUSHs(sv);
  }
  if (dovalues) {
  SV *tmpstr = hv_iterval(keys,entry);
  DEBUG_H(Perl_sv_setpvf(aTHX_ tmpstr, "%lu%%%d=%lu",
  (unsigned long)HeHASH(entry),
  (int)HvMAX(keys)+1,
  (unsigned long)(HeHASH(entry) & HvMAX(keys))));
  XPUSHs(tmpstr);
  }

Note that it actually *corrupts* every value stored in the hash, replacing
it with the debugging info​:

  $ perl -DH -e'%h=qw(a 1 b 2 c 3); @​a = %h; print "[$_]\n" for @​a'
  [a]
  [264771555%8=3]
  [c]
  [236623641%8=1]
  [b]
  [3658656729%8=1]

The bug in this ticket is that its trying to coerce a glob or a RO value
into a debugging string.

I can't think that the current behaviour of -DH is intentional; perhaps
the real intent was that it would print every value?

I can't see any use for this insane behaviour. So I propose that -DH
/ DEBUG_H is removed from the core.

--
Fire extinguisher (n) a device for holding open fire doors.

[p5pRT]

From @arc

Dave Mitchell <davem@​iabyn.com> wrote​:

Note that it actually *corrupts* every value stored in the hash, replacing
it with the debugging info​:

$ perl \-DH \-e'%h=qw\(a 1 b 2 c 3\); @​a = %h; print "\[$\_\]\\n" for @​a'
\[a\]
\[264771555%8=3\]
\[c\]
\[236623641%8=1\]
\[b\]
\[3658656729%8=1\]

I can't think that the current behaviour of -DH is intentional; perhaps
the real intent was that it would print every value?

Changing the value in the hash looks like it was an unnoticed
side-effect of this commit​:

commit b6429b1
Author​: Gurusamy Sarathy <gsar@​cpan.org>
Date​: Wed Sep 23 06​:08​:46 1998 +0000

  make \(%foo) return refs to values (not copies of values)
  From​: Stephen McCamant <smccam@​uclink4.berkeley.edu>
  Date​: Fri, 28 Aug 1998 20​:46​:10 -0700 (PDT)
  Message-ID​:
<13799.30680.47765.352558@​fre-76-120.reshall.berkeley.edu>
  --
  From​: Roderick Schertler <roderick@​argon.org>
  Date​: Sat, 29 Aug 1998 00​:58​:33 -0400
  Message-ID​: <29894.904366713@​eeyore.ibcinc.com>
  Subject​: Re​: \(%x) problems

  p4raw-id​: //depot/perl@​1819

Inline Patch

diff --git a/doop.c b/doop.c
index c6270e44f4..a3663f9d1d 100644
--- a/doop.c
+++ b/doop.c
@@ -1067,10 +1067,9 @@ do_kv(ARGSproto)
        if (dokeys)
            XPUSHs(hv_iterkeysv(entry));        /* won't clobber stack_sp */
        if (dovalues) {
-           tmpstr = sv_newmortal();
            PUTBACK;
-           sv_setsv(tmpstr,realhv ?
-                    hv_iterval(hv,entry) : avhv_iterval((AV*)hv,entry));
+           tmpstr = realhv ?
+                    hv_iterval(hv,entry) : avhv_iterval((AV*)hv,entry);
            DEBUG_H(sv_setpvf(tmpstr, "%lu%%%d=%lu",
                            (unsigned long)HeHASH(entry),
                            HvMAX(keys)+1,

(A perfect example of why debugging code with side-effects is a bug-in-waiting!)

Before that, DEBUG_H did, as you surmise, merely print every hash
value on iteration.

I can't see any use for this insane behaviour. So I propose that -DH
/ DEBUG_H is removed from the core.

I agree. Even if this were fixed, -DH would produce overwhelmingly
voluminous output on any non-toy program, so it's hard to imagine many
situations in which it could be useful. And since the bug has been
sitting there, silently corrupting hashes when enabled, for the better
part of 20 years, we have strong evidence that nobody can have
meaningfully used -DH in that time.

--
Aaron Crane ** http​://aaroncrane.co.uk/

[p5pRT]

From @demerphq

On 21 March 2017 at 12​:40, Aaron Crane <arc@​cpan.org> wrote​:

Dave Mitchell <davem@​iabyn.com> wrote​:

Note that it actually *corrupts* every value stored in the hash, replacing
it with the debugging info​:

$ perl \-DH \-e'%h=qw\(a 1 b 2 c 3\); @​a = %h; print "\[$\_\]\\n" for @​a'
\[a\]
\[264771555%8=3\]
\[c\]
\[236623641%8=1\]
\[b\]
\[3658656729%8=1\]

I can't think that the current behaviour of -DH is intentional; perhaps
the real intent was that it would print every value?

Changing the value in the hash looks like it was an unnoticed
side-effect of this commit​:

commit b6429b1
Author​: Gurusamy Sarathy <gsar@​cpan.org>
Date​: Wed Sep 23 06​:08​:46 1998 +0000

make \\\(%foo\) return refs to values \(not copies of values\)
        From&#8203;: Stephen McCamant \<smccam@&#8203;uclink4\.berkeley\.edu>
        Date&#8203;: Fri\, 28 Aug 1998 20&#8203;:46&#8203;:10 \-0700 \(PDT\)
        Message\-ID&#8203;:

<13799.30680.47765.352558@​fre-76-120.reshall.berkeley.edu>
--
From​: Roderick Schertler <roderick@​argon.org>
Date​: Sat, 29 Aug 1998 00​:58​:33 -0400
Message-ID​: <29894.904366713@​eeyore.ibcinc.com>
Subject​: Re​: \(%x) problems

p4raw\-id​: //depot/perl@​1819

diff --git a/doop.c b/doop.c
index c6270e44f4..a3663f9d1d 100644
--- a/doop.c
+++ b/doop.c
@​@​ -1067,10 +1067,9 @​@​ do_kv(ARGSproto)
if (dokeys)
XPUSHs(hv_iterkeysv(entry)); /* won't clobber stack_sp */
if (dovalues) {
- tmpstr = sv_newmortal();
PUTBACK;
- sv_setsv(tmpstr,realhv ?
- hv_iterval(hv,entry) : avhv_iterval((AV*)hv,entry));
+ tmpstr = realhv ?
+ hv_iterval(hv,entry) : avhv_iterval((AV*)hv,entry);
DEBUG_H(sv_setpvf(tmpstr, "%lu%%%d=%lu",
(unsigned long)HeHASH(entry),
HvMAX(keys)+1,

(A perfect example of why debugging code with side-effects is a bug-in-waiting!)

Before that, DEBUG_H did, as you surmise, merely print every hash
value on iteration.

I can't see any use for this insane behaviour. So I propose that -DH
/ DEBUG_H is removed from the core.

I agree. Even if this were fixed, -DH would produce overwhelmingly
voluminous output on any non-toy program, so it's hard to imagine many
situations in which it could be useful. And since the bug has been
sitting there, silently corrupting hashes when enabled, for the better
part of 20 years, we have strong evidence that nobody can have
meaningfully used -DH in that time.

If we need to debug these things we dont need a -DH flag to do it.
I've done a fair bit of hacking on our hash code, and I've never
noticed or needed this feature. Kill it with fire.

Yves

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

[p5pRT]

From @iabyn

On Tue, Mar 21, 2017 at 10​:54​:02AM +0000, Dave Mitchell wrote​:

I can't think that the current behaviour of -DH is intentional; perhaps
the real intent was that it would print every value?

I can't see any use for this insane behaviour. So I propose that -DH
/ DEBUG_H is removed from the core.

Now removed with v5.27.0-129-gfcd573e

--
"There's something wrong with our bloody ships today, Chatfield."
  -- Admiral Beatty at the Battle of Jutland, 31st May 1916.

[p5pRT]

@iabyn - Status changed from 'open' to 'pending release'

[p5pRT]

From @khwilliamson

Thank you for filing this report. You have helped make Perl better.

With the release yesterday of Perl 5.28.0, this and 185 other issues have been
resolved.

Perl 5.28.0 may be downloaded via​:
https://metacpan.org/release/XSAWYERX/perl-5.28.0

If you find that the problem persists, feel free to reopen this ticket.

[p5pRT]

@khwilliamson - Status changed from 'pending release' to 'resolved'