This is likely related to this change in 5.6 (from perldelta):
=head2 delete(), each(), values() and hash iteration are faster The hash values returned by delete(), each(), values() and hashes in a list context are the actual values in the hash, instead of copies. This results in significantly better performance, because it eliminate +s needless copying in most situations.
Previously, only copies were used, which meant that foreach-aliasing didn't really alias into the real hash values:
my %hash = (name => 'andrew', beer => 'Ale'); foreach my $KV (%hash) { print ">>$KV<<\n"; $hash{$KV} = 'Dark Ale' if $KV eq 'beer'; } __END__ # with 5.00503: >>name<< >>andrew<< >>beer<< >>Ale<< # with 5.6.1 >>beer<< >>Dark Ale<< >>name<< >>andrew<<
As you can see, with 5.005, even after we've changed the value for the key 'beer', we still get the old value because it was a copy. In 5.6 we get the new value because it is an alias into the hash. Now, in your situation, after deleting the key '*test' the next iteration involves an alias to a non-existing value and this is causing a problem for perl (which with -w gives "attempt to free unreferenced scalar", and a segfault otherwise).
In reply to Re: Why does this dump core?
by danger
in thread Why does this dump core?
by Ovid
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |