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 _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev