Hi, Richard Frith-Macdonald <[EMAIL PROTECTED]> 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 _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
