[vtk-developers] Use of autorelease in Cocoa classes

[Berk Geveci]

otool -oV returns empty:

alderaan:misc otool -oV ~/Work/ParaView/git-3.14/build/bin/pvbatch
/Users/berk/Work/ParaView/git-3.14/build/bin/pvbatch:

To provide a bit more detail. When I run the batch program in
Instruments, I see bunch of leaks originating from:

  NSOpenGLContext* context = [[[NSOpenGLContext alloc]
                              initWithFormat:pixelFormat
                              shareContext:nil] autorelease];

These leaks go away if I yank autorelease and add a release in DestroyWindow.

PS: Please be bear with me. My Objective C understanding is extremely limited.

-berk


On Fri, Feb 1, 2013 at 1:30 PM, Sean McBride <sean at rogue-research.com> wrote:
> On Fri, 1 Feb 2013 11:58:33 -0500, Berk Geveci said:
>
>>I just had a fun session tracking down what appeared to be a leak in
>>OpenGL resources in a VTK application running on a Mac. In short, the
>>application is a batch application (i.e. it never runs an interactor
>>and hence an event loop) that creates and destroys bunch of render
>>windows over the course of its execution. The issue is that none of
>>the resources for these windows are released until exit because the
>>autorelease behavior depends on the event loop running, which never
>>happens. Looking at the code, I see that Sean switched to using
>>Objective-C garbage collection in 2007 in the Cocoa render window.
>
> To clarify, it wasn't 'switched' to garbage collection, it was merely refactored to additionally support garbage collection.  There are 3 memory management models in Cocoa, in chronological order:
>  1) Manual reference counting (MRC): since the days of NeXT.
>  2) GC: new in OS X 10.5 and now deprecated, never available on iOS.
>  3) automatic reference counting (ARC): new in OS X 10.7 and iOS 5.
>
> The choice of which to use is made at compile time.  It's possible (though often contrived) to write code that supports all 3.  VTK supports 1 and 2.  A process is either GC or not, which is why VTK had to be refactored to support GC.  If a process in not GC, each source file can be compiled as MRC or ARC; thus a mostly-ARC app can still use VTK if its handful of Cocoa classes are compiled as MRC.  All rather confusing, I know.
>
> Anyway, it's certainly possible that while adding support for 2 I introduced a leak in 1.
>
>>My question is whether this is the right thing to do given that we may
>>batch applications like the one I was debugging that never run an
>>event loop and hence never do garbage collection of autorelease
>>objects. Is there a particular reason why we can't use old-fashioned
>>reference counting approach given that VTK does that very
>>successfully?
>
> Your process probably is in fact using 'old fashioned reference counting', but you can verify if your process is GC or not like so:
>
> $ otool -oV /Applications/Xcode.app/Contents/MacOS/Xcode | tail -3
> Contents of (__DATA,__objc_imageinfo) section
>   version 0
>     flags 0x6 OBJC_IMAGE_SUPPORTS_GC
>
> Xcode is a GC app, note the "OBJC_IMAGE_SUPPORTS_GC".
>
> Can we verify your leaky process before discussing further....?
>
> Cheers,
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng                 sean at rogue-research.com
> Rogue Research                        www.rogue-research.com
> Mac Software Developer              Montréal, Québec, Canada
>
>