JUCE Application leaking


#1

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)
    {
    }

#2

Did you mean ApplicationProperties ?

Rail


#3

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.


#4

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.


#5

Its dumping the entire application :frowning:


#6

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!


#7

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.


#8

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


#9

{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.


#10

Those are the leaked messages I mentioned above.


#11

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.


#12

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

Rail


#13

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

Nothing to see here, move along!


#14

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


#15

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!