Marvin Humphrey wrote on 11/08/2011 11:33 PM: > It's not surprising that SWISH::3 would pass its tests. You haven't set up > tests to validate behavior under refcount leakage, have you?
I do, actually. http://cpansearch.perl.org/src/KARMAN/SWISH-3-1.000000/t/07-refcnt.t among others. I use a ref_cnt counter on the underlying C struct, not relying on the Perl ref counting. So my DESTROY blocks are conditional on that ref_cnt. void DESTROY(self) SV *self; PREINIT: swish_3 *s3; CODE: s3 = (swish_3*)sp_extract_ptr(self); s3->ref_cnt--; if (s3->ref_cnt < 1) { sp_Stash_destroy( s3->stash ); } but SWISH::3 is far less complex than Lucy in terms of the number of classes and code generation etc, so I was willing to hand-code all the ref counting etc of internal objects, etc. > > What I'm suggesting if a user writes a program which leaks Lucy objects, and > if we disconnect that "tripwire" exception without implementing the > PERL_PHASE_DESTRUCT wrapping, that program may segfault during global > destruction in Perl 5.15. > > Most small programs don't leak, because most small programs don't have > circular references. Circular refs are pretty common in big, complex > programs, though. > > If SWISH::3 -- or Perl/Tk, or whatever else -- has complex objects which count > on deterministic order of destruction, I believe that the potential for > segfaulting during global destruction exists in Perl 5.15. > I agree with all that. I think your patch is the right choice. -- Peter Karman . http://peknet.com/ . [email protected]
