[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: opengroupware and gnustpe-base WAS: [OGo-Developer] gsmake2 branch s
Re: opengroupware and gnustpe-base WAS: [OGo-Developer] gsmake2 branch segmentation fault
Mon, 18 Feb 2008 09:44:40 +0000
On 18 Feb 2008, at 09:01, Sebastian Reitenbach wrote:
as promised, I wanted to keep you updated on the progress porting
sope/SOGo/OGo to gnustep-make 2. The switch to gnustep-make 2 seemed
fine, for all of the three. Wolfgang also announced the possibility to
compile SOGo against GNUstep make 2 some days ago on the sogo list.
The current state of affair can be found here:
However, OGo, on Linux, *BSD usually compiled against libFoundation,
to have a problem when compiled against gnustep-base. Stable or
doesn't matter, it ends up, with the same segmentation fault, see
mail below. This segfault was observed on OpenBSD(i386) and Linux.
There seem to be differences in libFoundation and gnustep-base with
to NSAutoreleasePool, but I have no real idea, what the actual
Any idea, what could be the problem? or how to investigate further?
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.