Re: [Gnustep-cvs] r26258 - /libs/base/trunk/Source/NSAutoreleasePool.m

[Richard Frith-Macdonald]

On 10 Mar 2008, at 13:25, David Ayers wrote:

> Richard Frith-Macdonald schrieb:
>
> > URL: http://svn.gna.org/viewcvs/gnustep?rev=26258&view=rev
> > Log:
> > Minor tweak to cope with EOFault
> >
> > Modified:
> >   libs/base/trunk/Source/NSAutoreleasePool.m
>
> Ugh!  An autorelease was sent to the EOFault class?
>
> I'm not sure that EOFault should be handled specially here.  Maybe we
> have a different issue.  Does the testsuite trigger this?

I'll explain the context ... I was debugging a crash when releasing an  
autorelease pool in ogo.

I found that [EOFault+instanceMethodForSelector:]] was crashing ... so  
I changed the code to call -methodForSelector: on the object being  
released rather than calling +instanceMethodForSelector: on the  
object's class, as this seemed more likely to be correctly implemented.

However ...
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.

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