On Jun 19, 2011, at 2:39 PM, Marvin Humphrey wrote: > On Sun, Jun 19, 2011 at 12:47:15PM -0700, [email protected] wrote: >> Perl’s extra pass during global destruction to fire destructors on any >> remaining objects that escaped the purge--which was added and removed before >> 5.14.0--has been reinstated in 5.15.0, to be released tomorrow. I don’t know >> whether this is still a problem for Lucy, but, if it is, that gives you at >> least ten months before this change makes it into a stable release of Perl. > > If I understand what's happening correctly... So long as the only objects left > at global destruction time are VTables, we'll just leak them intentionally and > we'll be OK. > > However, if other objects have leaked, non-deterministic destruction order can > potentially cause problems. > > It's easy to leak stuff: > > my %hash; > $hash{foo} = \%hash; > $hash{indexer} = Lucy::Index::Indexer->new(index => $path); > > An Indexer has-a SegWriter; if by chance the SegWriter's desctructor fires > before the Indexer's destructor, then when Indexer_Destroy() tries to call > DECREF(self->seg_writer), we'll get a use-after-free memory violation. > > I think we need two fixes. > > First, change VTable's destructor to a no-op, so that it no longer throws an > error. As soon as we do this, tests will start passing again. > > Second, perhaps we should change lucy_Memory_wrapped_free() to a no-op once we > enter the global destruction phase. That way, even when SegWriter gets > reclaimed first, there's still a real object at indexer->seg_writer instead of > a dangling pointer.
Or you could use END blocks, as you suggested for KinoSearch::Simple (at least two renamings ago), and for which I wrote a patch that you applied. The same technique could be applied to other classes with a has-a relationship. In any case, this second fix that you are suggesting is unrelated to the Perl change I mentioned above. (Prior to that change, the VTable object would be freed, but without its destructor called.) > > That second fix defeats the purpose of the change to Perl in some ways. Say > that you've embedded Perl in some other program and you keep creating and > destroying interpreters. Lucy doesn't really support that use case yet, > though. > > Marvin Humphrey >
