From @geeknik

Triggered with Perl v5.25.7-98-gdf13534 while fuzzing with AFL, but this
exact assertion failure doesn't happen with every execution.

od -tx1 test352
0000000 6d 61 70 2a 3a 3d 2a 5f 3d 44 2e 2e 00 20 2a 54
0000020 2c 25 5f 3d 44 2e 2a 00 20 54 2c 2a 5f 3d 44 2e
0000040 2e 00 20 2a 54 2c 25 5f 3d 44 2e 2e 00 20 54 2c
0000060 2a 3a 3d 2a 5f 3d 44 2e 2e 00 20 2a 54 2c 25 44
0000100 3d 44 2e 2a 00 20 54 2c 2a 5f 3d 44 2e 2e 00 20
0000120 2a 54 2c 25 5f 3d 44 2e 2e 00 20 54 2c 44 4f 55
0000140 4d 2c 04 fa 00 00 fa 3d 20 1e 44 f4 22 3a 75 6e
0000160 63 38 2e 41 3e 3b 80 69 66 00 01 3b 0a 6d 43 02
0000200 4f 69 66 fa 00 00 fa 6d 79 02 4f 61 54 2c 41 10
0000220 66 00 01 3b 33 6d 5b 02 64 69 66 00 01 3b 0a 74
0000240 72 14 80 12 00 80 00 73 74 67 32 22 3b 71 5f 80
0000260 00 00 00 41 5f 5b 0a 48 10 6c 80 6f 20 00 00 00
0000300 00 66 38 3a 41 3e 3b 0a 62 69 6e 6d 44 4f 55 4d
0000320 2c 04 fa 00 00 fa 3d 20 1e 44 f4 22 3a 75 6e 63
0000340 38 2e 41 3e 3b 5f 69 66 00 01 3b 0a 6d 43 02 4f
0000360 69 66 fa 00 00 fa 6d 79 02 51 61 54 2c 41 10 66
0000400 00 01 3b 33 6d 5b 02 64 69 66 00 01 3b 0a 74 72
0000420 14 80 12 00 80 00 73 74 67 32 22 3b 71 5f 80 00
0000440 00 00 41 5f 5b 0a 48 10 6c 80 6f 20 00 00 00 00
0000460 66 38 3a 41 3e 3b 0a 62 69 6e 6d 6f ff 21 0a
0000477

./perl test352
Attempt to free unreferenced scalar​: SV 0x621000010ba8 at test352 line 1.
Attempt to free unreferenced scalar​: SV 0x621000010bc0 at test352 line 1.
perl​: hv.c​:2690​: HE *Perl_hv_iternext_flags(HV *, I32)​: Assertion
`((svtype)((_svmagic)->sv_flags & 0xff)) >= SVt_PVMG' failed.
Aborted

./perl test352
Attempt to free unreferenced scalar​: SV 0x621000010a28 at test352 line 1.
Attempt to free unreferenced scalar​: SV 0x621000010a28 at test352 line 1.
Attempt to free unreferenced scalar​: SV 0x62100001bcf0 at test352 line 1.
perl​: sv.c​:6540​: void Perl_sv_clear(SV *const)​: Assertion
`((svtype)((sv)->sv_flags & 0xff)) != (svtype)0xff' failed.
Aborted

./perl test352
Attempt to free unreferenced scalar​: SV 0x621000010a28 at test352 line 1.
Attempt to free unreferenced scalar​: SV 0x621000010a28 at test352 line 1.
Attempt to free temp prematurely​: SV 0x621000010ba8 at test352 line 1.
Attempt to free unreferenced scalar​: SV 0x621000010ba8 at test352 line 1.

From @geeknik

test352.gz

From @hvds

The shortest/clearest replica of that particular assert I can get to is​:

% PERL_HASH_SEED=1 ./miniperl -e 'map *​: = *_ = (), (%_ = "D", *_ = 0, %_ = "D" .. "O", %_ = ())'
Attempt to free unreferenced scalar​: SV 0x1c44178 at -e line 1.
miniperl​: hv.c​:2690​: Perl_hv_iternext_flags​: Assertion `((svtype)((_svmagic)->sv_flags & 0xff)) >= SVt_PVMG' failed.
Aborted (core dumped)
%

This looks to be yet another stack-refcount issue, but I'm curious at the relevance of *​:.

Hugo

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

From @iabyn

On Mon, Dec 12, 2016 at 03​:17​:16AM -0800, Hugo van der Sanden via RT wrote​:

The shortest/clearest replica of that particular assert I can get to is​:

% PERL_HASH_SEED=1 ./miniperl -e 'map *​: = *_ = (), (%_ = "D", *_ = 0, %_ = "D" .. "O", %_ = ())'
Attempt to free unreferenced scalar​: SV 0x1c44178 at -e line 1.
miniperl​: hv.c​:2690​: Perl_hv_iternext_flags​: Assertion `((svtype)((_svmagic)->sv_flags & 0xff)) >= SVt_PVMG' failed.
Aborted (core dumped)
%

This looks to be yet another stack-refcount issue, but I'm curious at the relevance of *​:.

the HV slot of the *​: glob contains something that isn't a HV (due to
being freed and reallocated), and I don't quite understand why, but a glob
name which is a single '​:' is handled specially, and its HV slot is
treated as a stash, so MRO-ish stuff is done on %​:, which isn't a HV.

The single-colon stuff was added here​:

commit 1f656fc
Author​: Father Chrysostomos <sprout@​cpan.org>
AuthorDate​: Fri Apr 15 22​:33​:31 2011 -0700
Commit​: Father Chrysostomos <sprout@​cpan.org>
CommitDate​: Fri Apr 15 22​:34​:16 2011 -0700

  Followup to 088225f/[perl #88132]​: packages ending with :
 
  Commit 088225f was not sufficient to fix the regression. It still
  exists for packages whose names end with a single colon.
 
  I discovered this when trying to determine why RDF​::Trine was crashing
  with 5.14-to-be.
 
  In trying to write tests for it, I ended up triggering the same crash
  that RDF​::Trine is having, but in a different way.
 
  In the end, it was easier to fix about three or four bugs (depending
  on how you count them), rather than try to fix only the regression
  that #88132 deals with (isa caches not updating when packages ending
  with colons are aliased), as they are all intertwined.
 
  The changes are as follows​:
 
  Concerning the if (!(flags & ~GV_NOADD_MASK)...) statement in
  gv_stashpvn​: Normally, gv_fetchpvn_flags (which it calls and whose
  retval is assigned to tmpgv) returns NULL if it has not been told
  to add anything and if the gv requested looks like a stash gv (ends
  with :​:). If the number of colons is odd (foo​::​:), that code path is
  bypassed, so gv_stashpvn returns a GV without a hash. So gv_stashpvn
  tries to used that NULL hash and crashes. It should instead return
  NULL, to be consistent with the two-colon case.
 
  Blindly assigning a name to a stash does not work if the stash has
  multiple effective names. A call to mro_package_moved is required as
  well. So what gv_stashpvn was doing was insufficient.
 
  The parts of the mro code that check for globs or stash elems that
  contain stashes by looking for :​: at the end of the name now take into
  account that the name might consist of a single : instead.

--
Wesley Crusher gets beaten up by his classmates for being a smarmy git,
and consequently has a go at making some friends of his own age for a
change.
  -- Things That Never Happen in "Star Trek" #18