View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0003581 | VTK | (No Category) | public | 2006-08-03 15:36 | 2006-10-30 13:03 | ||||
Reporter | Sean McBride | ||||||||
Assigned To | Mathieu Malaterre | ||||||||
Priority | normal | Severity | minor | Reproducibility | always | ||||
Status | closed | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | |||||||||
Target Version | Fixed in Version | ||||||||
Summary | 0003581: vtkCocoaRenderWindow should not create an NSAutoreleasePool | ||||||||
Description | An autorelease pool is created in vtkCocoaRenderWindow's constructor and released in the destructor. The problem with this autorelease pool: any objects (including all objects that have nothing to do with VTK) created after this constructor are added to this autorelease pool and are never released until this VTK window is deleted. In a native Mac application one uses many autoreleased objects and they cannot be correctly released (at small time intervals) when a VTK window is opened and suddenly when a VTK window is closed many autoreleased objects are deleted, including some objects that should not be deleted during this process, generating random crashes. If I remove this autorelease pool, the problems disappear. I think the reason the pool is even created is this: most apps that use vtkCocoaRenderWindow.mm are not true cocoa apps, that is, they never call NSApplicationMain(), so as a workaround, an autorelease pool is created. For real cocoa apps, this is a pain. I believe the best solution is to _not_ create the autorelease pool and instead call the NSApplicationLoad() function. It is described like so "If NSApplication is not already initialized, initializes it and sets up event handlers for Cocoa. You typically call this before calling other Cocoa code in a plug-in loaded into a primarily Carbon application. A return value of YES indicates that NSApplication was successfully initialized for the Carbon application". I am testing this solution and will submit a patch. | ||||||||
Tags | No tags attached. | ||||||||
Project | |||||||||
Type | |||||||||
Attached Files | vtk_patch.txt [^] (4,442 bytes) 1969-12-31 19:00 [Show Content] | ||||||||
Relationships | |
Relationships |
Notes | |
(0004839) Mathieu Malaterre (developer) 2006-09-04 10:22 |
Patch should make sure that nothing is changed in the way user write sample. The code in Tcl should be exactly the same on win32 or MacOSX. |
(0005398) Sean McBride (developer) 2006-10-13 15:44 |
I have tested my patch. The dashboard continue to pass. I have also tried with several Mac-only vtk app, they work too. I think the change is quite safe. Patch attached. |
(0005602) David Gobbi (developer) 2006-10-30 13:03 |
Patch committed to cvs. /vtk/cvsroot/VTK/Rendering/vtkCocoaRenderWindow.h,v <-- vtkCocoaRenderWindow.h new revision: 1.28; previous revision: 1.27 /vtk/cvsroot/VTK/Rendering/vtkCocoaRenderWindow.mm,v <-- vtkCocoaRenderWindow.mm new revision: 1.41; previous revision: 1.40 /vtk/cvsroot/VTK/Rendering/vtkCocoaRenderWindowInteractor.mm,v <-- vtkCocoaRenderWindowInteractor.mm new revision: 1.13; previous revision: 1.12 |
Notes |
Issue History | |||
Date Modified | Username | Field | Change |
2011-06-16 13:11 | Zack Galbreath | Category | => (No Category) |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |