Crashes when close App (Mac) once in a while


#1

Sometimes when i closing my app via the Main-Menu (its a plugin-host with a plugin-window open, not sure if i get the error also without an plugin window open) i get "BAD ACCESS" with this stack-trace.


#0    0x00007fff85f6c55a in realizeClass(objc_class*) ()
#1    0x00007fff85f6c62e in realizeClass(objc_class*) ()
#2    0x00007fff85f6f20c in lookUpImpOrForward ()
#3    0x00007fff85f62169 in objc_msgSend ()
#4    0x00007fff8a693dea in -[NSView _removeFromKeyViewLoop] ()
#5    0x00007fff8a69375c in -[NSView _finalizeWithReferenceCounting] ()
#6    0x00007fff8a693360 in -[NSView dealloc] ()
#7    0x00007fff85f6465a in (anonymous namespace)::AutoreleasePoolPage::pop(void*) ()
#8    0x00007fff878f99e2 in _CFAutoreleasePoolPop ()
#9    0x00007fff89af7e17 in -[NSAutoreleasePool drain] ()
#10    0x00007fff879dde0c in __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ ()
#11    0x00007fff878d18dd in _CFXNotificationPost ()
#12    0x00007fff89adf7ba in -[NSNotificationCenter postNotificationName:object:userInfo:] ()
#13    0x00007fff8a8b9304 in -[NSApplication terminate:] ()
#14    0x00007fff8a864260 in -[NSApplication sendAction:to:from:] ()
#15    0x00007fff8a87f1c8 in -[NSMenuItem _corePerformAction] ()
#16    0x00007fff8a87ef04 in -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] ()
#17    0x00007fff8a8ce40d in -[NSMenu _internalPerformActionForItemAtIndex:] ()
#18    0x00007fff8a8ce289 in -[NSCarbonMenuImpl _carbonCommandProcessEvent:handlerCallRef:] ()
#19    0x00007fff8a874ff6 in NSSLMMenuEventHandler ()
#20    0x00007fff886a41d4 in DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) ()
#21    0x00007fff886a3787 in SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) ()
#22    0x00007fff886b7880 in SendEventToEventTarget ()
#23    0x00007fff886ed640 in SendHICommandEvent(unsigned int, HICommand const*, unsigned int, unsigned int, unsigned char, void const*, OpaqueEventTargetRef*, OpaqueEventTargetRef*, OpaqueEventRef**) ()
#24    0x00007fff88720228 in SendMenuCommandWithContextAndModifiers ()
#25    0x00007fff887201d0 in SendMenuItemSelectedEvent ()
#26    0x00007fff887200af in FinishMenuSelection(SelectionData*, MenuResult*, MenuResult*) ()
#27    0x00007fff88728085 in MenuSelectCore(MenuData*, Point, double, unsigned int, OpaqueMenuRef**, unsigned short*) ()
#28    0x00007fff88727cb1 in _HandleMenuSelection2 ()
#29    0x00007fff8a7e762c in _NSHandleCarbonMenuEvent ()
#30    0x00007fff8a64654e in _DPSNextEvent ()
#31    0x00007fff8a6458bb in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#32    0x00007fff8a6399bc in -[NSApplication run] ()


JUCE_AUTORELEASEPOOL BAD_ACCESS in VST destructor
#2

If you're running a host, you should always make sure that after closing any open windows, you mustn't unload the plugin from memory until the event loop has run for at least 1-2 seconds. That gives them time to clean up. Otherwise, there can be NSWindow objects left floating around after the plugin's module is unloaded from memory which will crash when the OS tries to free them.


#3

I have the same problem with unloading plugins in Nuendo/Cubase. 

Sometimes I get a "BAD_ACCESS" in 

#0 0x00007fff85f6c55a in realizeClass(objc_class*) ()

or in:

#0    0x00007fff8e4b50a3 in objc_msgSend ()

or in: 

#0    0x00007fff8e4b80ee in objc_release ()

 

The Host always crash, when Im unloading a plugin. Only if i close the GUI before manually there is no problem with unloading. 
I think its a related problem. 

Are there any solutions or hints how to fix the problems? 
I dont know really where they come from, I think im closing everything in the right way on my side. 


#4

... any updates on this issue?

(I am seeing the same behavior here in Cubase 7, no issues with Ableton Live 8 though...)


#5

I've wasted yet another day trying to figure out a fix for this issue.

My objective-c skills are close to none tbh..

with my VST plugin it's pretty concistent in Reaper64 (4.78) on OS X 10.10.3,

If i open the FXChain window and add the plugin, and then remove it, it's removed without any issues, but if i click somewhere on it's gui and then try to remove it the libObjc module crashes in the realizeClass method.. 

 

I have no problems with the AU version when trying the same procedure in reaper.. Hopefully there will be a workaround or at least exposing a few new "rule of thumbs" on what not to do when making a vst editor on Mac ;)

 

John


#6


Are there any new information on this subject already , or solutions
 


#7

I’ve followed the advice of waiting at least 1-2 seconds (I actually wait 5 seconds), but still got a crash because the CPU was active for more than 5 seconds.

Any good way to find out if the event loop has had the chance to run for at least 1-2 seconds, or do I need to do some really dirty hacks in order to estimate this?


#8

Hmm, guess I can just wait 0.5 seconds 10 times.


#9

Put this as the last line in your app’s dtor:

 MessageManager::getInstance()->runDispatchLoopUntil (2000);

Rail


#10

Thank you. This will block my program for 2 seconds though since I’m using Qt as my main gui.


#11

This is the very last thing your app does before it shuts down… what’s it blocking?

Rail


#12

Why do you think it’s the last thing my app does before it shuts down? I need to do this every time after closing a plugin.


#13

But when you mention it, I should probably add that line at the end of my app too . My scheduled Timer instance probably doesn’t get the chance to run when exiting the program, so this might explain some of the crash reports I’ve got on OSX when shutting down.


#14

Sorry, I misread the issue (the thread topic refers to the App)… We close our plugins asynchronously… so they have time to cleanup without affecting our plugin (the host).

Rail


#15

As I wrote, it looked like the CPU was active for more than 5 seconds, and therefore was not giving the message manager time enough to run. So it doesn’t help if you run async (which I of course do).

But I guess that I will never hit this problem again just by scheduling 10 x 0.5s, instead of 1 x 5s. If some process takes a lot of time right after closing the GUI, then the remaining 9 x 0.5s scheduled timing instances will give the message manager time enough to close to window.