Open djerius opened 1 month ago
Bisecting with the following invocation on unthreaded Linux builds ...
perl Porting/bisect.pl \
--start=v5.38.0 \
--end=v5.40.0 \
--with-module Hash::Ordered \
-- ./perl -Ilib $P5P_DIR/gh-22710-hash-ordered.pl
... where I modified @djerius's program to read:
$ cat gh-22710-hash-ordered.pl
use v5.38;
use experimental 'declared_refs';
use Hash::Ordered;
package foo {
sub new { my $class = shift; bless {}, $class }
sub method { [] };
}
eval {
my $hash = Hash::Ordered->new( map { $_ => foo->new } 0..1 );
for my $value ( $hash->values ) {
next if defined( my \@foo = $value->method );
}
};
if ($@) {
print "XXX: $@\n";
exit 1;
}
else {
exit 0;
}
... and that pointed to a change of behavior at 604c0355d2 last December
604c0355d21cd2bdfa4adbc4cc6e2014acb8760a is the first bad commit
commit 604c0355d21cd2bdfa4adbc4cc6e2014acb8760a
Author: David Mitchell <davem@iabyn.com>
Date: Sun Sep 24 22:11:21 2023 +0100
Commit: David Mitchell <davem@iabyn.nospamdeletethisbit.com>
CommitDate: Mon Dec 4 16:42:35 2023 +0000
make RC-stack-aware: unwrap pp_refassign()
Remove the temporary wrapper from pp_refassign()
Also move a couple of variable declarations into the smallest scope
possible: mg and stash are used only by (and implicitly by)
SvCANEXISTDELETE().
I say "change of behavior" because I don't know enough about declared_refs
or Hash::Ordered to say what good behavior should be.
@iabyn, can you take a look? Thanks.
Description
This is an odd one. I create an ordered hash whose values are objects via Hash::Ordered, then loop over the values, and incorrectly call
which, under 5.40 and not 5.38.3, corrupts
$value
. If I remove the call todefined
, $value is not corrupted.Steps to Reproduce
This results in:
This is perhaps something related to tied objects (which
Hash::Ordered
is based on)? I've experimented with looping over a simple array of objects, and the corruption does not occur.Perl configuration