Re: Double free invisible due to autorelease pool

[Richard Frith-Macdonald]

On 3 Feb 2005, at 08:33, Sébastien Pierre wrote:

> Hi Richard, Adam,
>
> First, thanks a lot for your answers !
>
> Le 2 févr. 05, à 22:19, Adam Fedor a écrit :
>
> > > > I am currently in big trouble trying to find the cause of a "double 
> > > > free" which occurs when releasing an autorelease pool. Has anybody 
> > > > any idea to know how to identify where an autoreleased objects was 
> > > > freed (released, I guess) before being autoreleases ?
> > >
> > > [NSObject+enableDoubleReleaseCheck:] might well help you.
>
> This helped me to see that there is actually a double release check, 
> but I would like the debugger to break on the raising of the 
> "NSGenericException". On OSX, there is the "NSHangOnUncaughtException 
> = YES;" provided by NSDebug, but it does not seem to be on GNUstep :/
>
> Is there any workaround ?

I generally run under gdb and set a breakpoint in raise:format: but if 
you have other exceptions being raised, it's better to set the 
breakpoint at the line in -autorelease where the exception is raised.
Do that by starting under gdb, then doing a 'list autorelease' to look 
at the autorelease source code, then set a breakpoint at the 
appropriate line.  Of course, if you have gnustep built without debug 
or you don't have the source installed, this would be a problem...
In which case, you can use NSSetUncaughtExceptionHandler(), which is 
documented in the macros part of the 'Functions' section of the base 
library documentation.

> > I think you could also try setting the env var
> >
> > NSZombieEnabled
>
> I did not manage to find documentation on this, and it does not seem 
> to have any effect. What is this used for ?

The environment variable is documented at the top level (introductory) 
page of the base library documentation in the section on environment 
variables.
The global variable (set from the environment variable) is documented 
in the 'Types and Constants' documentation of the base library.

Basically, it allows deallocated objects to persist and call a standard 
function when you try to use them ... so you can track them down more 
easily under debug.