Stop gv_try_downgrade from anonymising referenced CVs
authorFather Chrysostomos <sprout@cpan.org>
Tue, 5 Nov 2013 14:14:59 +0000 (06:14 -0800)
committerFather Chrysostomos <sprout@cpan.org>
Tue, 5 Nov 2013 20:55:02 +0000 (12:55 -0800)
commit8941bf970eeb8009630d57a0b1bacb99f40db9bf
tree81f1d4eacc8f94d1ec19dce2e51931f0cc0c7cde
parent3b927101bf18bfcb197cacec8603d2b8297963ae
Stop gv_try_downgrade from anonymising referenced CVs

I keep discovering ways in which gv_try_downgrade, which is supposed
to be an optimisation, changes observable behaviour even without look-
ing at the stash.

This one had me confused at first:

$ ./perl -Ilib -e 'use constant foo=>1; BEGIN { $x = \&foo } undef &$x; $x->()'
Undefined subroutine called at -e line 1.
$ ./perl -Ilib -e 'use constant foo=>1; BEGIN { $x = \&{"foo"} } undef &$x; $x->()'
Undefined subroutine &main::foo called at -e line 1.

Notice how the first example (where gv_try_downgrade kicks in)
shows no name in the error message.  This only happens on non-
threaded builds.

What’s happening is that, when the BEGIN block is freed, the GV op
corresponding to &foo get freed, triggering gv_try_downgrade, which
checks to see whether it can downgrade the GV to a simple reference
to a constant (the way constants are stored by default).  It then pro-
ceeds to do that, so the GV qua GV ceases to exist, and the CV gets
automatically anonymised as a result (the same thing happens with
‘$x = \&{"foo"}; Dump $x; delete $::{foo}’, but legitimately in
that case).

The solution here is to check the reference count on the CV before
downgrading the GV.  If the CV’s reference count > 1, then we should
leave it alone.
gv.c
t/op/gv.t