Father Chrysostomos via RT wrote: >> use constant INIT => 4; There's a problem with this line: INIT, as a subroutine name, is magic to Perl, and defining a constant in this way actually amounts to defining a subroutine. If you change the name to XNIT then nothing funny happens. With the name INIT, funny stuff happens. At some point the constant, represented specially in the stash, is liable to get upgraded to a full glob and subroutine. gv_init() invokes newCONSTSUB() to build the full subroutine, but building it triggers the magic behaviour of process_special_blocks(). Part of this magic behaviour is to remove the sub from the glob that it's just been attached to, which makes gv_init() fail its assertion (on a debugging build) that the sub was properly attached. I'm not clear on how &Needed gets involved. That part of the reported behaviour has all the hallmarks of an object address getting reused such that an uncounted reference ends up referring to something unexpected. I believe the fingering of the bareword sub lookup patch is a red herring. The reason why it's come up is that it added a new situation in which *INIT would be upgraded to a real glob. Now, the upgrading occurs as a temporary measure while the use of the INIT constant (in the callit expression) is being processed at compile time. Formerly, no upgrading would occur in the compilation of your script. You can also trigger upgrading by putting "our $INIT" somewhere in the script. However, in my tests, a non-debugging 5.10 did not visibly misbehave when "our $INIT" was included to trigger upgrading. -zeframThread Previous | Thread Next