EOFault / NSAutoreleasePool

[David Ayers]

Richard Frith-Macdonald schrieb:

> The underlying fault in ogo was that an array was being released too
> many times ... so it's possible that the EOFault I found on one debug
> run was just there because it had re-used the memory of the deallocated
> array in the autorelease pool.  It's even possible (assuming that
> EOFault manages its oven memory ... I haven't checked the source) that
> the EOFault had not only re-used the memory form the array but had also
> been deallocated itsself.  ie. the crash in + instanceMethodForSelector:
> may have been because the fault had been deallocated rather than because
> of a bug in the method itsself.  You would probably know whether that
> could happen ... I don't know the EOFault code.

EOFault instance are rather tricky when it comes to retain counting.
They are proxy classes that update their class_pointer to morph back
into an instance of the class the originally were.

(i.e. one doesn't create EOFault instances, one creates custom Objects
and they are "faulted" by releasing the attributes and storing some data
they need to be restored later and updating the class_pointer to the
EOFault class.)

see: + (void)makeObjectIntoFault: (id)object
                withHandler: (EOFaultHandler *)handler

But part of the data that must be retained in both guises is the retain
count.  Now there is code that is supposed to insure this.

To make things worse, the implementation of the these fault handlers is
partly in EOControl (EOFaultHandler (abstract class)) and EOAccess
(EOAccessFault).

> I haven't tried running the gdl2 testsuite, but I assume you have done
> that and it doesn't crash.

No it doesn't for me.  But I'm not sure we cover the concrete EOFault
classes wrt retain counts excessively.  I think we my need some tests
here to insure that the problem isn't here, if you are using ogo with
gdl2... is that the case?

Cheers,
David