I have a Juce VST Audio Plugin running under Cubase 5 and 6. When I include a DialogWindow in the plugin editor then after closing a Cubase project Cubase crashes. If I don’t include the DialogWindow in the editor then there is no crash. Also if I manually close the editor before closing the project then there is no crash. So Cubase crashes when the project is closed while the editor is open, but does not crash if the editor is already closed before closing the project. In either case the DialogWindow is never visible, only instantiated. So it seems there might be a race condition that occurs during the process of closing the main editor window and deleting objects. The crash occurs in both Cubase 5 and 6. In the debugger the crash seems to occur during the infamous Cubase CResampleBase() routine, although this is the case for many unrelated Cubase crashes judging from a Google search. In trying to debug the problem I have simplified my DialogWindow derived class to point where it has no overridden functions, no content component, and no calls are made on the DialogWindow other than the constructor and delete. I am running Mac 10.6.6 and running 32 bit Cubase. Any Ideas?
No. No modal loop. Inside the main editor, which is a straightforward subclass of AudioProcessorEditor, there is a call to instantiate the simplest possible subclass of DialogWindow. I simplified the subclass of DialogWindow to the point where there isn’t even a content component. The dialog window is never made visible just instantiated in the AudioProcessorEditor subclass constructor and deleted in the destructor. Once again the crash occurs only if the main editor window is open when the Cubase project is closed. If the main editor is manually closed before hand then the crash does not occur. This suggests to me a race condition in the destruction of windows vs. other objects but I don’t know. Perhaps I need to throw in some mutexs somewhere?
This sounds like our old enemy, the lingering OSX window reference. We’ve discussed it on other threads, but basically what seems to happen is that when the underlying NSWindow is deleted, the OS keeps a reference to it, which it uses later, presumably to do some internal cleaning-up. Unfortunately, because the host closes our window and immediately unloads the plugin, then by the time the OS decides to make this call to the window reference, the plugin and its dll no longer exist, so obviously the call crashes. I’m stumped as to anything that could possibly be done about this in the plugin, other than to recommend that you don’t use an external window…
Is there no way, using some kind of timing mechanism perhaps, to emulate the project closing behavior that occurs when one manually closes the DialogWindow before closing the project?