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