[vtk-developers] Use of autorelease in Cocoa classes

[Sean McBride]

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