|
From: | Richard Frith-Macdonald |
Subject: | Re: [Gnustep-cvs] r26258 - /libs/base/trunk/Source/NSAutoreleasePool.m |
Date: | Tue, 11 Mar 2008 07:54:40 +0000 |
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.mUgh! 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.
[Prev in Thread] | Current Thread | [Next in Thread] |