Running:

#!/usr/bin/env perl

*guard::DESTROY = sub {
   ${$_[0]}->();
};

*guard = sub (&) {
   my $callback = shift;
   return bless \$callback, "guard"
};

my %t; %t = (
    stash => {
        guard => guard(sub{
            print "Guard\n";
            delete $t{stash};
        }),
        foo => "bar",
        bar => "baz",
    },
);

delete $t{stash}{guard};


causes SIGABRT by glibc heap allocator:

$ ./perl-doublefree_on_delete_hash_entry 
Guard
*** glibc detected *** perl: munmap_chunk(): invalid pointer: 0x000000000222be38 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3f5ec7c2d6]
/usr/lib64/perl5/CORE/libperl.so(Perl_hv_free_ent+0x6c)[0x3f700a564c]
/usr/lib64/perl5/CORE/libperl.so(Perl_hv_common+0xae2)[0x3f700a7e92]
/usr/lib64/perl5/CORE/libperl.so(Perl_pp_delete+0x451)[0x3f700dcfb1]
/usr/lib64/perl5/CORE/libperl.so(Perl_runops_standard+0x16)[0x3f700ac796]
/usr/lib64/perl5/CORE/libperl.so(perl_run+0x3aa)[0x3f7004ddfa]
perl[0x400cd9]
/lib64/libc.so.6(__libc_start_main+0xed)[0x3f5ec2169d]
perl[0x400d11]

This issue has been reported to upstream as <https://rt.perl.org/rt3/Public/Bug/Display.html?id=100340> and fixed in development tree as commit:

commit 3b2cd8095a6fc52afccf519205a3c5a92669b0c3
Author: Father Chrysostomos <sprout>
Date:   Sat Dec 31 18:54:14 2011 -0800

    [perl #100340] Free hash entries before values on delete
    
    When a hash element is deleted in void context, if the value is freed
    before the hash entry, it is possible for a destructor to see the hash
    in an inconsistent state--inconsistent in that it contains entries
    that are about to be freed, with nothing to indicate that.  So the
    destructor itself could free the very same hash entry (e.g., by
    freeing the hash), resulting in a double free, panic, or other
    unpleasantness.