[MAC] AU Plugin crash when switching from one instance to another in Reaper

Audio Plugins
1

I have the same plugin code for VST/AU and VST worked just fine but AU (under MacOS) crashed(EXC_BAD_ACCESS (code=1, address=0xffffffff00000001)) when switching from instance to instance in Reaper (FX: Track1) quite fast. On every switch, Reaper deletes the old GUI window and creates a new one and after five or tens switches occur crash.

#0 Crash inside child component destructor (like juce::String)
..
#25	0x000000011257a4a1 in MainWindow::~MainWindow() at Plugin/GUI/MainWindow.cpp:1939
#26	0x000000011257c4b5 in MainWindow::~MainWindow() at Plugin/GUI/MainWindow.cpp:1916
#27	0x000000011257c5bc in MainWindow::~MainWindow() at Plugin/GUI/MainWindow.cpp:1916
#28	0x0000000112031490 in juce::Component::deleteAllChildren() at modules/juce_gui_basics/components/juce_Component.cpp:1536
#29	0x0000000111ce71f6 in JuceAU::EditorCompHolder::~EditorCompHolder() at modules/juce_audio_plugin_client/AU/juce_AU_Wrapper.mm:1480
#30	0x0000000111ce5b65 in JuceAU::EditorCompHolder::~EditorCompHolder() at modules/juce_audio_plugin_client/AU/juce_AU_Wrapper.mm:1479
#31	0x0000000111ce5b8c in JuceAU::EditorCompHolder::~EditorCompHolder() at modules/juce_audio_plugin_client/AU/juce_AU_Wrapper.mm:1479
#32	0x0000000111ce1d4f in std::__1::default_delete<JuceAU::EditorCompHolder>::operator()(JuceAU::EditorCompHolder*) const at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:2338
#33	0x0000000111ce1ccf in std::__1::unique_ptr<JuceAU::EditorCompHolder, std::__1::default_delete<JuceAU::EditorCompHolder> >::reset(JuceAU::EditorCompHolder*) at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:2651
#34	0x0000000111ce1a67 in std::__1::unique_ptr<JuceAU::EditorCompHolder, std::__1::default_delete<JuceAU::EditorCompHolder> >::operator=(std::nullptr_t) at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:2609

#35	0x0000000111ce17db in JuceAU::JuceUIViewClass::deleteEditor(objc_object*) at modules/juce_audio_plugin_client/AU/juce_AU_Wrapper.mm:1631
#36	0x0000000111ce8070 in JuceAU::JuceUIViewClass::shutdown(objc_object*) at modules/juce_audio_plugin_client/AU/juce_AU_Wrapper.mm:1660
#37	0x0000000111ce7ce6 in JuceAU::JuceUIViewClass::dealloc(objc_object*, objc_selector*) at modules/juce_audio_plugin_client/AU/juce_AU_Wrapper.mm:1647

#38	0x00007fff6ac6c054 in AutoreleasePoolPage::releaseUntil(objc_object**) ()
#39	0x00007fff6ac50dba in objc_autoreleasePoolPop ()
#40	0x00007fff31d17a85 in _CFAutoreleasePoolPop ()
#41	0x00007fff343b1a81 in -[NSAutoreleasePool release] ()
#42	0x000000010ba3fc93 in AU_Plugin::QuitConfig() ()
#43	0x000000010b877f32 in FxDsp::delConfig() ()
#44	0x000000010b8ad3bf in FxChain::displayDspConfig(HWND__*, int) ()
#45	0x000000010b8a601d in FxChain::dialogProc(HWND__*, unsigned int, unsigned long, long) ()
#46	0x000000010b9e06d6 in SwellDialogDefaultWindowProc(HWND__*, unsigned int, unsigned long, long) ()
#47	0x00007fff344522fa in __NSFireTimer ()
#48	0x00007fff31d747f9 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ ()
#49	0x00007fff31d7435f in __CFRunLoopDoTimer ()
#50	0x00007fff31d73e47 in __CFRunLoopDoTimers ()
#51	0x00007fff31d58bea in __CFRunLoopRun ()
#52	0x00007fff31d57e3e in CFRunLoopRunSpecific ()
#53	0x00007fff30984abd in RunCurrentEventLoopInMode ()
#54	0x00007fff309847d5 in ReceiveNextEventCommon ()
#55	0x00007fff30984579 in _BlockUntilNextEventMatchingListInModeWithFilter ()
#56	0x00007fff2efca039 in _DPSNextEvent ()
#57	0x00007fff2efc8880 in -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] ()
#58	0x00007fff2efba58e in -[NSApplication run] ()
#59	0x00007fff2ef8c396 in NSApplicationMain ()
#60	0x000000010b4cadf4 in start ()

Is it a known JUCE issue or my?
Any hints please

2

Are you able to reproduce this with any of the example plugins from the JUCE repo? I just attempted to reproduce it with the DSPModulePluginDemo AU, and was able to switch back and forth between two instances more than fifty times without seeing any crashes.

If the JUCE examples don’t crash, then the problem is likely in your code somewhere. You could try building your plugin and the AudioPluginHost both with Address Sanitizer enabled, and then running both under a debugger. If the problem is a dangling pointer or similar, Address Sanitizer should help you locate the problem quickly.

3

Thanks, I will try, Does AudioPluginHost allow to switch between multiple instances of the same plugin?

4

Not in quite the same way as REAPER, but you can load multiple instances of the plugin and then independently open/close the editors of each. It looks like the issue might just be an intermittent problem in the editor’s destructor, so loading multiple instances may not even be necessary to track down the problem with Address Sanitizer.

5

The issue is reproducible only if very fast switch one instance of plugin to another (in Track1) in the same window, so Reaper (due to debug information) will destory/create plugin window as fast as switching occour.

For example, after enabling sanitizer in XCode I have got new sig.fault inside JUCE Component where parentComponent pointer is looks like uninitialized/danglee.

mega-switching-in-reaper
mega-switching-in-reaper1225×841 239 KB

6

Are you sure you enabled Address Sanitizer correctly? On my system, after building a plugin with Asan I’m not able to load it in REAPER directly (it is possible, but requires some modification of environment variables and it’s a little bit awkward). If you didn’t do this addtional setup stage, then I don’t think you have correctly enabled Asan. This is the main reason I suggested to use the AudioPluginHost - if both the plugin and host are built with Asan, then plugin loading should work as normal. You could also try running the standalone version of your app with Asan enabled, as this will be even easier than using the AudioPluginHost.

Asan is a bit “stricter” than running a program normally, so it is sometimes able to locate bugs even without reproducing the issue exactly. It looks like the problem is a dangling pointer, either in the constructor or destructor (maybe both) of your MainWindow class. It’s possible that Asan will flag up the issue just by running this constructor/destructor. For this reason I’d strongly suggest testing in the Standalone or AudioPluginHost with Asan enabled.

To be clear, you can enable Asan by adding -fsanitize=address to the compile flags in the Projucer, and then resaving and rebuilding the project.

There’s not much to go on in your screenshot. What does the constructor of MainWindow look like? At what point are you calling setLookAndFeel?

7

Thank you for a very descriptive answer, I will try to enable Asan using -fsanitize from Projucer.
setLookAndFeel called from the MainWindow constructor ‘//[Constructor] You can add your own custom stuff here…’ section. MainWindow constuctor creates many buttons, labels and so and assign setLookAndFeel for each component, connects listeners and so …