lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: [lucy-dev] Perl’s global destruction
Date Sun, 19 Jun 2011 21:39:32 GMT
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.

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,

Marvin Humphrey

View raw message