Cubase Crash when closing project -- DialogWindow problem


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?

You’re not running a modal loop to show the dialogwindow, are you?

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?

Is there any Solution for this Problem right now? 
I've got the same Problem with one of my Plugins. 


I never use a dialog, I use always some subcomponents. This components ar hidden normaly.

So I switch to hidden/show  and have a bunch of components for different states. Not the best

design, but it works.



recommend that you don't use an external window

I never use a dialog, I use always some subcomponents

Is it fine if we use DialogWindow not on the desktop, but as child component of the editor, or would it lead to the same issue?

a small bump.. Jules, you said not to use external window, so it's fine to use child windows or the same problem could occur? 

Sure, child components of your plugin editor are handled entirely internally so should be fine.

What about the JUCE FileChooserDialogBox? We all need one, right :)

Is it better to add this one as child component too and does this help to avoid crashes? 

It seems that it works as child componenent:

        this->dialogBox = new FileChooserDialogBox(
            "Choose Directory",

        this->dialogBox->centreWithSize(800, 600);
        this->dialogBox->enterModalState(true, ModalCallbackFunction::forComponent(StaticFileCallback, this));

Any input is welcome!

Edit: It's better to use the file chooser component directly without the dialog box...