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

[Sebastian Reitenbach]

Hi,

Richard Frith-Macdonald <richard@tiptree.demon.co.uk> wrote: 
> 
> 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.
> 
> 
thanks for these suggestions, I think they will keep me busy for a time.

cheers
Sebastian