JUCE Application leaking

I have a project in which the entire JUCE application is leaking somehow, or at least visual studio says so. I tried to boil it down to a minimal example. In the following code the ApplicationPreferences object is causing visual studio to spew out a memory leak, even though the reset is being called. Am I missing something in the startup/shutdown sequence? The project is projucer built for visual studio 2015. The weird thing is that the JUCE_LEAK_DETECTOR on the Builder object or the ApplicationPreferences object does not trigger.

//Main.cpp
    #include "Builder.h"

//This macro generates the main() routine that launches the app.
START_JUCE_APPLICATION(Builder)

//Builder.h
#include <memory>
#include <JuceHeader.h>

//Model
class ApplicationPreferences;

    class Builder : public JUCEApplication
    {
    public:
    	Builder();
    	virtual ~Builder();

    	//Startup
    	void initialise(const String& commandLine) override;

    	//Shutdown
    	void systemRequestedQuit() override;
    	void shutdown() override;

    	//ID
    	const String getApplicationName() override;
    	const String getApplicationVersion() override;

    	//Instances
    	void anotherInstanceStarted(const String& commandLine) override;
    	bool moreThanOneInstanceAllowed() override;

    private:
    	//Model
    	std::unique_ptr<ApplicationPreferences> applicationPreferences;

    	JUCE_LEAK_DETECTOR(Builder)
    };

//Builer.cpp
#include "Builder.h"
    Builder::Builder()
    	: applicationPreferences(std::make_unique<ApplicationPreferences>())
    {
    }

    Builder::~Builder()
    {
    	applicationPreferences.reset();
    }

    const String Builder::getApplicationName()		{ return ""; }
    const String Builder::getApplicationVersion()	{ return "0.0"; }
    bool Builder::moreThanOneInstanceAllowed()		{ return false; }


    void Builder::initialise(const String& commandLine)
    {
    	JUCEApplication::quit();
    }

    void Builder::shutdown()
    {
    	applicationPreferences.reset();
    }

    void Builder::systemRequestedQuit()
    {
    	JUCEApplication::quit();
    }

    void Builder::anotherInstanceStarted(const String& commandLine)
    {
    }

Did you mean ApplicationProperties ?

Rail

Its a custom class, but it doesn’t really matter what kind of object I put in Builder, Builder just leaks by itself. If I put a std::vector in there it will also dump a memory leak. The _CrtDumpMemoryLeaks call just dumps everything that is in the Builder instance, without hitting the leak detector.

Are you talking about a single leak of just a few bytes? That’s quite common, as you can sometimes get one or two not-yet-delivered messages still on the system message queue at shutdown, not an actual problem.

Its dumping the entire application :frowning:

Then I have no idea, never heard of that happening. Must be some other clue that you’ve not mentioned here. Get some breakpoints in the destructors and do some debugging!

The Builder destructor is being called and it cleans up the unique ptrs, I think it is just giving me a faulty memory leak dump… but I don’t see where its coming from.

Maybe there’s something wrong with the preprocessor definitions?

_CRT_SECURE_NO_WARNINGS
WIN32
_WINDOWS
DEBUG
_DEBUG
JUCER_VS2015_78A5022=1
JUCE_APP_VERSION=1.0.0
JUCE_APP_VERSION_HEX=0x10000

{209} normal block at 0x0062CB38, 8 bytes long.
Data: < L > A8 F8 4C 02 01 00 00 00
{196} normal block at 0x0060BF00, 48 bytes long.
Data: <l , T 0 b > 6C 0E 2C 02 CD CD CD CD 54 EB 1B 02 30 C9 62 00
{195} normal block at 0x0060C0D8, 40 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{169} normal block at 0x0060DD78, 48 bytes long.
Data: <02 T2 b > 30 32 1C 02 CD CD CD CD 54 32 1C 02 88 C7 62 00
{168} normal block at 0x0060C610, 40 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.

Those are the leaked messages I mentioned above.

Sorry forgot to mention that when I remove the ApplicationPreferences member it does not give me these leaks, the same for a std::vector member.

And if you put applicationPreferences on the stack without using a unique_ptr?

Rail

Presumably because the ApplicationPreferences class dispatches some messages. And then you quit before they get delivered.

Nothing to see here, move along!

What would be the best way to make sure that all the messages are handled on shutdown, so I can detect actual leaks?

Well not doing this would be a good start!

void Builder::initialise(const String& commandLine)
{
	JUCEApplication::quit();
}

If you quit before the message loop has even started, it doesn’t stand a chance!