I’d really love to fix it, but I’m completely stuck for ideas! Feel free to email me directly if you want more help…
May be move
from void removeSubWindow()
to the begining of JucePluginProcess destructor?
So this hack will only be called during PT close (as far as I remember), and not during opening\closing of plugin UI?
Seems to work here, will test it more, but I think that is the solution that will keep PT from crash during PT shutdown and it will not crash with fast UI open\close usecase.
PS what should I add to RTAS wrapper to enable plugin window hiding when PT hides? I mean that currently, if plugin editor is open and I’m trying to hide PT, all the PT windows are hiding except the JUCE plugin UI. Thnaks.
oh, that’s a good idea… So something like this:
[code] ~JucePlugInProcess()
{
if (mLoggedIn)
MIDILogOut();
deleteAndZero (midiBufferNode);
deleteAndZero (midiTransport);
if (prepared)
juceFilter->releaseResources();
delete juceFilter;
if (--numInstances == 0)
{
#if JUCE_MAC
// Hack to allow any NSWindows to clear themselves up before returning to PT…
for (int i = 20; --i >= 0;)
MessageManager::getInstance()->runDispatchLoopUntil (1);
#endif
shutdownJuce_GUI();
}
}
[/code]
Not sure about the window hiding - the OS normally handles that. I’ll have to try it and see what’s going on there.
[quote=“yfede”]
Investigating the selector that caused the problem, I think I found the cause: when compiled in Debug mode, the plugin creates an auxiliary window that isn’t child of it.
Sure enough, the EditorComponent’s destructor contains the code to deallocate that auxiliary window as well, but for some reason I have no time to investigate (here Jules may have more luck than me), it seems that it behaves correctly only when I explicitly close the editor AND THEN delete the plugin from live.
If I let the host do all the work upon deletion of the plugin, leaving the EditorComponent window open, I am sure (verified with the debugger) that the EditorComponent destructor gets called, but for some reason I fear that OS X “remembers” some reference to that auxiliary window, and attempts to send a message to that after having deleted it.[/quote]
Did you find a solution for this problem? I have exactly the same issue (an extra DocumentWindow created by my Editor).
If my EditorWindow is opened when its destructor is called AND it called the destructor of this window, it crashes.
Kevin
Is it the same as this?
http://www.rawmaterialsoftware.com/viewtopic.php?f=8&t=5609
If so, it’s a problem that we’re getting Ableton to look into at the moment.
No it isn’t. In my case it crashes at the first close without saving. I just have to delete the plugin track with the GUI opened.It seems to be exactly the same problem that yfede described.
…ah, actually that could be the same thing.
The bug I referred to happens if your GUI has the keyboard focus and you invoke a menu command that deletes the plugin, so this might also trigger it. The way to check would be to try deleting the track with a key shortcut - if that works ok, but using the menu crashes it, then it’s the same bug.
In my case it always crashes, no matter if I use the menu or the keyboard shortcut, if I have created my external window (so I delete it in my editor destructor) but never it has not been created (so not deleted).
Sounds like something else then. Can you reproduce the bug with the juce demo plugin?
No I don’t. Even with adding this kind of extra DocumentWindow.
It means that you will not be able to help me a lot 
I have to investigate more in my code.
[EDIT]
After a little bit more try. I achieved to reproduce the crash on the demo. But it does not appear all the time, it is very strange. It seems to be related to the content component of this extra window, but don’t know exactly what. I will stop it for today as I my head will explode if I continue.
Hi ke20, did you ever resolve this problem?
I have exactly the same issue. My plugin creates a auxilliary DocumentWindow. If I run the VST version Live 8 (Mac) I get exactly the same crash as described in this thread:
- Open Live, create an instance of the plugin - editor window opens automatically.
- Remove the plugin straight away using the keyboard shortcut.
- Crash as described in previous posts.
If I add the DocumentWindow to the Desktop I get the crash, even if I don’t make it visible. It seems to make no difference whether I clean up the DocumentWindow properly in my editor’s destructor or not, I still get the crash. If I don’t add the DocumentWindow to the Desktop I don’t get the crash. Incidentally, this only affects the VST version, the AU build is fine.
Does anyone have any idea what I could do about this? Does anyone have a plugin using a relatively recent version of Juce that opens a secondary DocumentWindow that works in Live?
I also get the objc_msgSend crash in Reaper if I quit Reaper when my plugin UI is open. I get this one from time to time whether I open a second DocumentWindow or not. Both of these crashes only happen in the VST version, my AUs are fine.
I need to get these resolved quickly but I’m out of ideas!
Thanks in advance for any help,
Bennie
Hi Bennie,
I didn’t find the time to solve this issue until now but I think I’ll have to in the next few weeks.
I’ll keep you in touch.
Kevin
I can reproduce this using the juce demo plugin by adding the following to the JuceDemoPluginAudioEditor constructor:
mp_window = new DocumentWindow( "Window", Colours::grey, 0, true );
mp_window->setAlwaysOnTop( true );
mp_window->setSize( 200, 200 );
mp_window->setVisible( true );
and this to the destructor:
delete mp_window;Here’s a callstack:
#0 0x926df6e8 in objc_msgSend
#1 0x9072a9bd in __NSFireDelayedPerform
#2 0x94bb7b45 in CFRunLoopRunSpecific
#3 0x94bb7cf8 in CFRunLoopRunInMode
#4 0x921b8da4 in RunCurrentEventLoopInMode
#5 0x921b8bbd in ReceiveNextEventCommon
#6 0x921b8a31 in BlockUntilNextEventMatchingListInMode
#7 0x92ac0505 in _DPSNextEvent
#8 0x92abfdb8 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
#9 0x92ab8df3 in -[NSApplication run]
#10 0x01486e12 in std::out_of_range::~out_of_range
#11 0x0147a9c2 in std::out_of_range::~out_of_range
This is a release build of the demo run in Live 8 (Mac). I open the plug-in and then delete it straight away without closing the plug-in UI first. I’m using the latest released version of Juce, not the tip. I will investigate further…
What can happen with mac NSWindows is that when you delete them, they schedule themselves to do some kind of clean-up stuff asynchronously… But if the host removes your module from memory before their callback happens, then it’ll be calling into some memory that no longer exists.
I added a bodge for this in RTAS by calling MessageManager::runDispatchLoopUntil after deleting the window, to give it a chance to clean-up, but I can’t think of a more robust workaround.
[quote]
I added a bodge for this in RTAS by calling MessageManager::runDispatchLoopUntil after deleting the window, to give it a chance to clean-up, but I can’t think of a more robust workaround.[/quote]
The odd thing about that is that even if I increase the length of time the bodge works for and the number of messages, I still get the crash. It doesn’t seem to matter how long I make them. Since I’m looking at the VST version, this is where I’m changing the numbers (in juce_VST_wrapper.mm):
for (int i = 20; --i >= 0;)
MessageManager::getInstance()->runDispatchLoopUntil (1);
I’ve tried starting i at 100 and running the dispatch loop for 20ms but there’s no change.
Would your advice be to not add any components to the Desktop from a VST plug-in because of this problem? Is there any workaround that would let me display a window not constrained to the boundary of my plug-in’s editor window without adding it to the desktop? (I’m guessing there isn’t but you can’t blame me for asking!) Otherwise I’m at a bit of a dead end. I can’t really release a VST that crashes the host whenever you delete it!
You probably shouldn’t have a window floating around all the time, anyway, but it’s an annoying problem because it should be possible. I wish I could think of a better solution, but since I don’t even know what the NSWindow is doing, I’ve really no idea how best to deal with it.
Another possibility is that something in Live is keeping a reference to your NSWindow, e.g. as part of some kind of internal list of windows in Cocoa, but that the module gets unloaded while that pointer is still held, so any subsequent calls to it crash.
I agree that the floating window should not be open all the time but as you say it is possible.
So maybe the best now is to contact an Ableton developper.
TBH I doubt whether anyone at Ableton would know anything either - this is more of an OSX/objective-C issue. I don’t think it sounds like a bug or problem in the host, just bad luck that the library is getting unloaded before this callback happens.
Well that’s a good point. It’s just a settings window so it’s only open now and then. The strange thing is that if it’s ever been added to the desktop I get the crash. It doesn’t matter how long ago it was or how long it is since it was removed from the desktop.
Anyway, I’ve skirted round the issue for the time being by making the settings window modal and I don’t seem to get any crashes this way. I’d love to get this fixed properly but I can’t afford to spend any more time looking into it now I’m afraid.
I get a similar crash with Cubase (5.5) when several plugins are loaded and the GUIs are closed very fast. Therefore I load all GUIs, put them at the same place and click the close buttons fast. I couldn’t reproduce this in Reaper and it doesn’t seem to be a problem in Live which only shows the GUIs of plugins from the current track (don’t know Live that much, maybe this can be setup differently).
The crash only occurs when closed manually; closing the project with all GUIs open quits normal.
Also I once crashed Cubase by opening the GUIs fast (by loading the plugin in the same FX-slot of different channels and open them with mouse-click/cursor down), but I couldn’t reproduce that.
I tried to add a random delay to the editor’s destructor which didn’t work and brings me to a question about XCode: I set a breakpoint in the editors destructer and started XCode with breakpoints on, but it never reached the breakpoint. What am I missing?
Any suggestions for a work-around for the crash?
Chris