FileBrowser with canSelectDirectories crash in BigSur

Audio Plugins
#1

JUCE 6.1.2 with BigSur. I try to open a dialog for selecting a folder. When I try the following code it opens the native dialog to select the folder but it is not responsible and the application freezes.
The save dialog for example works without any problems. Also, the same code works in Catalina without any problems.

            myChooser = std::make_unique<juce::FileChooser>("Please choose directory.",
                                                      File::getSpecialLocation(juce::File::SpecialLocationType::userDocumentsDirectory),
                                                      "*");

            myChooser->launchAsync(
                    FileBrowserComponent::openMode | FileBrowserComponent::canSelectDirectories,
                    [this] (const FileChooser& myChooser)
                    {
                        File selectedFile = myChooser.getResult();

                        if (selectedFile == File())
                        {
                            return;
                        }

                        // do something
                    }

Any help is welcome.

#2

Looks like the same problem here but with macOS BigSur:

#3

I don’t have a Big Sur machine for testing, but on both 12.0.1 and 10.15.7, the DemoRunner remains responsive when adding the provided code to the end of the MainComponent constructor. I tried both selecting and opening a directory, and cancelling the chooser.

Is the provided code broken in all JUCE apps (e.g. if you modify a demo to include it), or only in your app? If it’s only broken in your app, what does the lifetime of the chooser pointed-to by myChooser look like? Do any other functions try to assign to myChooser while the native filechooser is opening or open?

#4

Thanks for looking at this. This is a show-stopper for us at the moment. I use the code in a plugin and a component that stays alive as long as the UI is open holds the FileChooser. It works in windows and also in Catalina.

Maybe it does not work when called from a plugin?

We can reproduce the crash with 3 different BigSur machines (two with M1). I will update one to see if it works in 12.0.1.

#5

That’s it. My button triggers it twice for mouse down and mouse up. I will verify ASAP. I think it is solved. Thanks for your time.

#6

Thanks, I can reproduce the issue in the AudioPluginDemo VST3 and the AudioPluginHost on 12.0.1.

Although it’s probably a mistake for an application to quickly open and close the FileChooser window, I think it’s also a bug in JUCE for such calls to hang/crash the application. I’ve investigated a bit, and I think there might be something a little bit broken at the OS level (creating an NSOpenPanel, displaying it, and then immediately closing it sometimes leaves the panel visible on screen). However, I was able to work around this by launching the panel in an async callback. This seems like a reasonable fix, given that the panel is async anyway.

Hopefully this fix will be on develop shortly (next week, maybe?), once it’s been reviewed by the team. It might take a bit longer than normal, as we’re still preparing and running ADC workshops this week.

2 Likes
#7

I’ve made the change outlined above here:

This avoids FileChooser-related crashes on my Monterey machines. Please try updating and let us know if you discover any new issues.

#8

Thanks for the fixes. I will report if I find something and make some tests. Seems to work on a first try.

#9

I’m not sure if this is related or a problem. I get the following exception when I cancel a file open or file save dialog on iOS on develop:


|#1|0x000000010287050c in juce::WeakReference<juce::Component, juce::ReferenceCountedObject>::Master::getSharedPointer(juce::Component*) at /Users/patrickkunz/Develop/tal/juce/modules/juce_core/memory/juce_WeakReference.h:173|
|---|---|
|#2|0x000000010287044c in juce::WeakReference<juce::Component, juce::ReferenceCountedObject>::getRef(juce::Component*) at /Users/patrickkunz/Develop/tal/juce/modules/juce_core/memory/juce_WeakReference.h:207|
|#3|0x0000000102870408 in juce::WeakReference<juce::Component, juce::ReferenceCountedObject>::WeakReference(juce::Component*) at /Users/patrickkunz/Develop/tal/juce/modules/juce_core/memory/juce_WeakReference.h:84|
|#4|0x000000010286fe24 in juce::WeakReference<juce::Component, juce::ReferenceCountedObject>::WeakReference(juce::Component*) at /Users/patrickkunz/Develop/tal/juce/modules/juce_core/memory/juce_WeakReference.h:84|
|#5|0x00000001025c1b6c in juce::Component::exitModalState(int) at /Users/patrickkunz/Develop/tal/juce/modules/juce_gui_basics/components/juce_Component.cpp:1764|
|#6|0x000000010275a00c in juce::FileChooser::Native::pickerWasCancelled() at /Users/patrickkunz/Develop/tal/juce/modules/juce_gui_basics/native/juce_ios_FileChooser.mm:305|

It asserts here:

                // You're trying to create a weak reference to an object that has already been deleted!!
                jassert (sharedPointer->get() != nullptr);

Is this the expected behavior?

#10

Can you tell me which OS version please? Can you trigger it in the DemoRunner Dialogs demo?

#11

Never mind, I’ve managed to repro the problem now.

1 Like