lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [lucy-dev] Perl’s global destruction
Date Mon, 20 Jun 2011 01:01:33 GMT

On Jun 19, 2011, at 2:39 PM, Marvin Humphrey wrote:

> On Sun, Jun 19, 2011 at 12:47:15PM -0700, 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

> 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

View raw message