[Ecls-list] ECL 10.3.1 GC finalization bug and patch

[Juan Jose Garcia-Ripoll]

On Sun, Mar 14, 2010 at 2:30 AM, Ram Krishnan <kriyative at gmail.com> wrote:

> There's a fairly serious bug in the GC finalization code in
> 10.3.1 (and 9.12.3). The effect of the bug is that if a program
> allocates multiple ffi objects, and calls SET-FINALIZER on them, then
> under some circumstances the finalizer may be called with a completely
> bogus pointer object, or just crash with a SIGSEGV. The issue is in
> the queueing_finalizer() function in src/c/alloc_2.d.
>

It would be nice if you could provide a test case.


> After staring at this function for a while I gave up on what the
> motivation behind it is. All that queueing_finalizer() does is to
> create a list of the objects and their finalizers, which were passed
> to it, so that those finalizers may be called at some later point. I
> can't figure out what the benefit of deferring these finalization
> calls is. Anyway, the simplest fix is to not do any queueing, and just
> invoke the finalizer, like so:
>

This can not be done. An arbitrary lisp finalizer can not be invoked inside
the garbage collector when the code has been marked as not live.

Among other things the problem is that some of its components may be
destroyed when you try this approach. Say you have object A and B that point
each other and suddenly they become  garbage-collectable. If you invoke the
finalizer in the garbage collector then A's finalizer may be called before
or after B's, but what is more important is that B or A might have been
already destroyed by the collector.

The approach we took was different. When an object becomes finalizable (and
it is not a simple object such as a stream or so) the object is brought back
to life and put in a queue which is known to the garbage collector. This
queue is processed later at another point in time and then the object is
removed from the queue and eventually garbage collected.

If there's a reason for the current behavior of queueing_finalizer(),
> I look forward to understanding it.
>

I hope the  text above helped you understand it. The situation is not at all
trivial and the current one is the best solution I could come up with.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20100314/fc48a4d1/attachment.html>