[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: opengroupware and gnustpe-base WAS: [OGo-Developer] gsmake2 branch s

From: Richard Frith-Macdonald
Subject: Re: opengroupware and gnustpe-base WAS: [OGo-Developer] gsmake2 branch segmentation fault
Date: 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 to work
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, 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]