On 18 Feb 2008, at 09:01, Sebastian Reitenbach wrote:
However, OGo, on Linux, *BSD usually compiled against libFoundation,
seems
to have a problem when compiled against gnustep-base. Stable or
unstable
doesn't matter, it ends up, with the same segmentation fault, see
forwarded
mail below. This segfault was observed on OpenBSD(i386) and Linux.
There seem to be differences in libFoundation and gnustep-base with
regards
to NSAutoreleasePool, but I have no real idea, what the actual
problem is.
Any idea, what could be the problem? or how to investigate further?
any more
information I could provide?
Looking at the code, there only appear to be a few possibilities, and
none of them are really issues with NSAutoreleasePool itsself:
1. somehow the pool is being deallocated recursively so that it's
trying to release a nil object ... but unless I'm missing something,
that seems to be ruled out by the fact that we don't see it in the
stacktrace,.. unless one of the objects being deallocated releases
the
pool in another thread so that it doesn't appear in the trace ...
hard
to see how that would happen.
2. an object being deallocated returns a bad value from
instanceMethodForSelector: or methodForSelector: ... obviously rather
unlikely as this would really need the object to be of a class which
overrides the method in a buggy way, or would need to be corrupt.
3. by far the most likely would be if the pool is releasing an object
which has already been deallocated ... all that's needed for this to
happen is a retain/release bug somewhere in the code.
To check for (1) you could add code to test to see if anObject is
nil ... if it is, then the pool is being emptied recursively.
To check for (2) you could add code to test the result of those calls
to see if it is zero.
To check for (3) you could try replacing the fast
GSObjCClass(anObject) with the slower [anObject class]. This will
effectively remove the method lookup optimisation from the code here,
but will more reliably catch the lookup of the class of a deallocated
object, making it clearer what the underlying problem is.
Approaching the issue from another direction, you could try calling
[NSObject enableDoubleReleseCheck: YES] right at the start of the
program ... this will get the autorelease system to spot cases where
an object is autoreleased too often (though it can't spot cases where
the object is released too often after being added to a pool).
You could also try running with the environment variable setting
'NSZombieEnabled=YES' ... which will effectively leak all memory (so
you need to find out how to reproduce the crash after running the
program for as short a time as possible before you try this) but will
log when you try to deallocate an object which was already
deallocated.