Assertion Failure: Perl_sv_grow (sv.c:1587) #15613

p5pRT · 2016-09-18T19:43:57Z

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

Searchable as RT129300$

p5pRT · 2016-09-18T19:43:57Z

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 · 2016-09-19T04:51:31Z

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 · 2016-09-19T04:51:31Z

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

p5pRT · 2017-03-21T10:54:46Z

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&#8203;: $\!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 · 2017-03-21T11:41:13Z

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$; @&#8203;a = %h; print "\[$\_\]\\n" for @&#8203;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 · 2017-03-22T10:50:51Z

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$; @&#8203;a = %h; print "\[$\_\]\\n" for @&#8203;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&#8203;: //depot/perl@&#8203;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 · 2017-06-05T15:53:27Z

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 · 2017-06-06T07:31:14Z

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

p5pRT · 2018-06-23T15:29:25Z

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 · 2018-06-23T15:29:25Z

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

p5pRT closed this as completed Jun 23, 2018

p5pRT added the Severity Low label Oct 19, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Assertion Failure: Perl_sv_grow (sv.c:1587) #15613

Assertion Failure: Perl_sv_grow (sv.c:1587) #15613

p5pRT commented Sep 18, 2016

p5pRT commented Sep 18, 2016

p5pRT commented Sep 19, 2016

p5pRT commented Sep 19, 2016

p5pRT commented Mar 21, 2017

p5pRT commented Mar 21, 2017

p5pRT commented Mar 22, 2017

p5pRT commented Jun 5, 2017

p5pRT commented Jun 6, 2017

p5pRT commented Jun 23, 2018

p5pRT commented Jun 23, 2018

Assertion Failure: Perl_sv_grow (sv.c:1587) #15613

Assertion Failure: Perl_sv_grow (sv.c:1587) #15613

Comments

p5pRT commented Sep 18, 2016

p5pRT commented Sep 18, 2016

From @geeknik

p5pRT commented Sep 19, 2016

From @cpansprout

p5pRT commented Sep 19, 2016

p5pRT commented Mar 21, 2017

From @iabyn

p5pRT commented Mar 21, 2017

From @arc

p5pRT commented Mar 22, 2017

From @demerphq

p5pRT commented Jun 5, 2017

From @iabyn

p5pRT commented Jun 6, 2017

p5pRT commented Jun 23, 2018

From @khwilliamson

p5pRT commented Jun 23, 2018