[vtkusers] Autorelease pool issue with vtkCocoaRenderWindowInteractor

[Corrie Allen]

David,
Your fix worked!  Thanks.  You've not only taken care of this little  
problem but also helped me understand a little more about autorelease  
pool issues.
Corrie
On Feb 23, 2008, at 12:11 PM, David Cole wrote:

> Looks to me like this call...
>   // Now that we are about to begin the standard Cocoa event loop,  
> we can get
>   // rid of the 'pool of last resort' because [NSApp run] will  
> create a new
>   // pool for every event
>   #ifndef __OBJC_GC__
>   gEarlyCocoaSetup->DestroyPoolOfLastResort();
>   #endif
>
> ...should be moved up to just before the lines that read:
>   // Start the NSApplication's run loop
>   [NSApp run];
>
> ...they used to be in exactly that order prior to revision 1.15 of  
> that file.
>
> Unfortunately, that also means it looks like moving the entire  
> vtkEarlyCocoaSetup class above the ObjectiveC class implementations  
> to factilitate that call.
>
> I've modified the file to see if it works for you. I will send it to  
> you separately as an attached file. Let me know if it works for you  
> and I will commit it to VTK after you let me know...
>
>
> Thanks, (and hope this helps!)
> David Cole
> Kitware, Inc.
>
>
> On 2/23/08, Corrie Allen <corrieallen at gmail.com> wrote:
> Hi David & VTKers,
> At the time my program runs, __OBJC_GC__ is undefined and I can't  
> find anywhere in my project, the VTK build, or my environment  
> setting where it is either defined  (or undefined).  So, if the  
> definition isn't hiding away somewhere, my understanding of it is  
> that the PoolOfLastResort "hack" should be setting up a pool that  
> can be subsequently autoreleased during Cocoa operations.   I guess  
> I need to now dig into the workings of CMake so as to understand  
> what Sean is doing with his RogueResearch builds.  Any further  
> suggestions (Like Hey Corrie, buy the Cmake book!) will certainly be  
> appreciated.
> Corrie
>
> On Feb 22, 2008, at 9:55 AM, David Cole wrote:
>
>> Look at the code around line 222 of VTK/Rendering/ 
>> vtkCocoaRenderWindowInteractor.mm
>>
>> If you are getting that message, then the vtkEarlyCocoaSetup  
>> constructor is probably not being called. Maybe __OBJC_GC__ is  
>> defined, but there is a need for an autorelease pool anyhow....?
>>
>> Some of the RogueResearch mac VTK dashboards use this cache entry...
>> VTK_REQUIRED_OBJCXX_FLAGS:STRING=-fobjc-gc
>> ...to turn on objective C++ garbage collection.
>>
>> Are you doing that in some fashion for your build? Or is  
>> __OBJC_GC__ defined for your build somehow?
>>
>>
>> HTH,
>> David
>>
>> On 2/21/08, Corrie Allen <corrieallen at gmail.com> wrote:
>> Hi VTK gurus,
>>
>> I'm getting this snippet of output in my log window during the run  
>> of a little program I've written.
>> "
>> Gonna initialize interactor next!
>> And now starting interactor
>> 2008-02-21 20:03:26.496 spawar2[1365:10b] ***  
>> _NSAutoreleaseNoPool(): Object 0x13e22460 of class vtkCocoaServer  
>> autoreleased with no pool in place - just leaking
>> Stack: (0x90a3012f 0x9093cec2 0xda040 0xdaa3c 0x702b 0x6176)
>> "
>> The c++ code where this is occurring is
>> ....
>>    cout<<"Gonna initialize interactor next!"<<endl;
>>   iren->Initialize();
>>   cout<< "And now starting interactor"<< endl;
>>   iren->Start(); //where iren is an instance of  
>> vtkCocoaRenderWindowInteractor
>> ....
>> The 3-D object is rendered fine after the log note appears and the  
>> interactor works well. The log output,though, is worrisome.  Where  
>> can I begin to look for the cause of this: just leaking with no  
>> pool in place seems bad.
>>
>> Corrie
>>
>> MacBook Pro, OSX 10.5.1, CMake 2.4.8, VTK 5.1,
>> i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5465)
>>
>>
>> _______________________________________________
>> This is the private VTK discussion list.
>> Please keep messages on-topic. Check the FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
>> Follow this link to subscribe/unsubscribe:
>> http://www.vtk.org/mailman/listinfo/vtkusers
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20080224/adb4e70a/attachment.htm>