Memory leaks in JUCE codebase where std::unique_ptr<T>::release() is called...?

General JUCE discussion
1

I’ve just done an audit of my own code in relation to potentially “dangerous” calls to std::unique_ptr<T>::release() and noticed that there are few places in the JUCE code, where release() seems to be called with the intention of deleting a unique_ptr when in fact it doesn’t do that. Rather it simply releases ownership not memory.

For example in juce_WavAudioFormat.cpp::1757:

                if (writer != nullptr)
                {
                    outStream.release();

Also in juce_*_Windowing.cpp we have code like:

    std::unique_ptr<WindowsMessageBox> mb (new WindowsMessageBox (iconType, title, message, associatedComponent,
                                                                  MB_OKCANCEL, callback, callback != nullptr));
    if (callback == nullptr)
        return mb->getResult() != 0;

    mb.release();

And juce_AlertWindow.cpp:597

            alertBox->enterModalState (true, callback, true);
            alertBox.release();

There may be other instances.

NOTE: this is on the latest JUCE6 branch

Jamie

2

Here, AudioFormat::createWriterFor() takes ownership of the object on successful creation so we need to release it otherwise it’ll be deleted twice.

WindowsMessageBox deletes itself if it has an associated callback so again, we’re preventing double-deletion.

From the docs of Component::enterModalState():

If deleteWhenDismissed is true, then when it is dismissed, the component will be deleted and then the callback will be called. (This will safely handle the situation where the component is deleted before its exitModalState() method is called).

3

Ah great… I did think I must’ve missed something :slightly_smiling_face:

I think my brain is just a bit fried from adapting to the new combination of smart pointers and legacy bare pointers!

1 Like