Crash with AudioDeviceSelectorComponent in PluginEditor

Audio Plugins
1

For a music library plugin I have an AudioDeviceManager in the editor for the sole purpose of auditioning the tracks, before they are selected. This used to work for 3 years now (released product with plenty documented users).

I haven’t worked on the project since beginning this year, but updating to develop I experience a crash far away from my code when the AudioDeviceSelectorComponent is populated on creation of the editor:

Crash-AudioDeviceSelectorComponent
Crash-AudioDeviceSelectorComponent.jpg2609×1747 1010 KB

I was suspicious of the use of std::move of stack objects in PopupMenu::Item, but they seem legit…

Is there anything I can do?

Thanks for help

2

This is the breaking commit:

It works before, crashes after that commit. Can you please have a look @jules?

3

This simple editor crashes AudioPluginHost and FinalCutProX:

class CrashPluginAudioProcessorEditor  : public AudioProcessorEditor
{
public:
    CrashPluginAudioProcessorEditor (CrashPluginAudioProcessor& p)
    : AudioProcessorEditor (&p), processor (p)
    {
        addAndMakeVisible (selector);

        setSize (400, 300);
    }

    void paint (Graphics&) override {}
    void resized() override
    {
        selector.setBounds (getLocalBounds());
    }

private:
    CrashPluginAudioProcessor& processor;

    AudioDeviceManager devMan;
    AudioDeviceSelectorComponent selector {devMan, 0, 0, 2, 2, false, false, true, false };

    JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR (CrashPluginAudioProcessorEditor)
};

I have a slightly older Logic version, that didn’t crash (scratches head)

4

Did someone verify? working on it? not planning to? already fixed?

Friendly bump…

5

Looking into it, but I don’t think it’s any easy fix…

6

Thanks, that’s great.

I agree, it will be nasty to track down. But at least it happens every time here, not just sometimes, and I guess, you will find a problem, that is most likely not limited to that particular case.

Good luck!

7

OK, so this should be fixed with this commit:

You’ll need to rebuild the AudioPluginHost and plug-in with these changes.

Jules’ PopupMenu changes weren’t the culprit, but they were triggering some weird behaviour that we haven’t run into before. Essentially there was a symbol collision happening with the static EmptyString object at the top of juce_String.cpp when running a JUCE plug-in in the JUCE host which was causing the checks for empty strings to be incorrect as they were relying on the address of the static object.

I don’t know why this would crash in Final Cut though, are you sure it’s the same crash you’re seeing there?

8

When I wrote it, I was sure, now I am not so sure any more :wink:

I rather get a crash in AsyncUpdater:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x00007fff723222c6 __pthread_kill + 10
1   libsystem_pthread.dylib       	0x00007fff723ddbf1 pthread_kill + 284
2   libsystem_c.dylib             	0x00007fff7228c6a6 abort + 127
3   libc++abi.dylib               	0x00007fff6f468641 abort_message + 231
4   libc++abi.dylib               	0x00007fff6f474ad2 __cxa_pure_virtual + 18
5   com.filmstro.FilmstroFCPX     	0x00000001450ba7e8 juce::AsyncUpdater::AsyncUpdaterMessage::messageCallback() + 72 (juce_AsyncUpdater.cpp:35)
6   com.filmstro.FilmstroFCPX     	0x00000001450c37fb juce::MessageQueue::deliverNextMessage() + 107 (juce_osx_MessageQueue.h:82)
7   com.filmstro.FilmstroFCPX     	0x00000001450c3746 juce::MessageQueue::runLoopCallback() + 54 (juce_osx_MessageQueue.h:93)
8   com.filmstro.FilmstroFCPX     	0x00000001450c3615 juce::MessageQueue::runLoopSourceCallback(void*) + 21 (juce_osx_MessageQueue.h:102)
9   com.apple.CoreFoundation      	0x00007fff462d6083 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
10  com.apple.CoreFoundation      	0x00007fff462d6029 __CFRunLoopDoSource0 + 108
11  com.apple.CoreFoundation      	0x00007fff462b99eb __CFRunLoopDoSources0 + 195
12  com.apple.CoreFoundation      	0x00007fff462b8fb5 __CFRunLoopRun + 1189
13  com.apple.CoreFoundation      	0x00007fff462b88be CFRunLoopRunSpecific + 455
14  com.apple.HIToolbox           	0x00007fff455a496b RunCurrentEventLoopInMode + 292
15  com.apple.HIToolbox           	0x00007fff455a46a5 ReceiveNextEventCommon + 603
16  com.apple.HIToolbox           	0x00007fff455a4436 _BlockUntilNextEventMatchingListInModeWithFilter + 64
17  com.apple.AppKit              	0x00007fff4393e987 _DPSNextEvent + 965
18  com.apple.AppKit              	0x00007fff4393d71f -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1361
19  com.apple.AppKit              	0x00007fff4393783c -[NSApplication run] + 699
20  com.apple.LunaKit             	0x000000010d84143b LKApplicationMain + 363
21  libdyld.dylib                 	0x00007fff721e73d5 start + 1

You are right, it’s a different crash. The project is using the deprecated AudioProcessorValueTreeState createAndAddParameter, and the DuplicateParamIDCheck gets into deleting an AsyncUpdater, which jasserts() sometimes (if an update is pending).

50%20(2)
Screenshot 2019-07-10 at 12.27.50 (2).png3235×992 627 KB

I’ll check your fix in AudioPluginHost and my host first… thanks already!

9

Yes, the original bug is solved, thank you!

Now I need to get that AsyncUpdater resolved.
It happens when skimming over the timeline. Very strange, but FCPX is creating multiple instances on the fly, so it is more likely to catch these kind of things than a host, that only creates an instance once, and most times unloads only once the session is over…

BTW. in release I get crashes as well, so it is probably not just a benign jassert().

10

OK, we’ll look into it.

11

Thanks!

I just verified, that using the latest AudioProcessorValueTreeState constructor and avoiding the deprecated createAndAddParameter makes no difference.

12

If you add a destructor to DuplicateParamIDCheck and add a call to cancelPendingUpdate() in there does that solve the first crash? I can’t see how this would crash in release mode though as the check is only added for debug builds.

13

Awesome, you’re great! That does indeed fix the problem in debug and release.

Seems, FCPX is discarding instances before they even finished the setup. So the cancelPendingUpdate() in the destructor is a good safety measure to add.

Thanks a bunch!

14

OK, I’ll get that added.

1 Like