Front page | perl.perl5.porters |
Postings from April 2012
On 31 March 2012 22:23, Father Chrysostomos via RT <perlbug-followup@perl.org> wrote: > On Fri Mar 30 22:31:21 2012, sprout wrote: >> On Fri Mar 30 07:42:51 2012, rmbarker.cpan@btinternet.com wrote: >> > > env PERL_DESTRUCT_LEVEL=1 ./perl -Ilib -MSafe \ >> > -we 'Safe->new->reval(q(use strict))' >> > Unbalanced string table refcount: (2) for "strict/vars" during global >> > destruction. >> > Unbalanced string table refcount: (2) for "strict/subs" during global >> > destruction. >> > Unbalanced string table refcount: (2) for "strict/refs" during global >> > destruction. >> >> It’s coming from this croak in op.c: >> >> #define CHECKOP(type,o) \ >> ((PL_op_mask && PL_op_mask[type]) \ >> ? ( op_free((OP*)o), \ >> Perl_croak(aTHX_ "'%s' trapped by operation mask", PL_op_desc[type]), \ >> (OP*)0 ) \ >> : PL_check[type](aTHX_ (OP*)o)) >> >> I haven’t thought of a way to fix it yet. > > Stopping Safe.pm from doing ‘no strict’ solves this particular test > case, and is something that needs doing to fix a regression (‘use 5.012’ > not enabling strict inside reval), so I’ve used this ticket’s blocking > status as an excuse to fix it in commit 25dc25e77. > > But with strict mode (true second argument to reval), the same problem > occurs: > > $ PERL_DESTRUCT_LEVEL=1 ./perl -Ilib -MSafe -we 'Safe->new->reval(q(use > strict),1)' > Unbalanced string table refcount: (1) for "strict/vars" during global > destruction. > Unbalanced string table refcount: (1) for "strict/subs" during global > destruction. > Unbalanced string table refcount: (1) for "strict/refs" during global > destruction. > > There appears to be no easy, unintrusive way to stop ops from leaking in > this case. It seems we need slab allocation, as suggested in > <https://rt.perl.org/rt3/Ticket/Display.html?id=107000#txn-1054694>; or > some way to tell the parser to stop, without needing to do a longjmp. > > For now, I’m simply going to restore the amount of warnings to the 5.14 > level by moving the new strict hints from %^H into $^H. Thanks for the patch, that looks sensible, but on a specific dual-life maintainance point of view : I did not foresee the need for patching Safe in core before 5.16 and I've already released 2.32 on CPAN with what's on branch dual/Safe. (mostly only commit 312434d200ea2a8487b21594aeb6c13838c42b0b, a small inobtrusive fix related to Devel::Cover.) The approach of least resistance would be now to merge dual/Safe in blead and release 2.33.Thread Previous | Thread Next