Leak Memory in Hello World

Windows
1

I have some Memory leaks in my application, so i try to find where they come.

In Hello World Project, if i write:

g.fillAll(Colours::beige); in Paint function instead of GradientBrush gradientBrush (Colours::lightblue, 0, 0, ... g.drawRect (0, 0, getWidth(), getHeight()); i have memory leaks !!!

Detected memory leaks! Dumping objects -> e:\jp\juce_1_13\juce\src\juce_core\text\juce_string.cpp(59) : {122} normal block at 0x0194BA60, 26 bytes long. Data: < Lucida C> 01 00 00 00 0E 00 00 00 4C 75 63 69 64 61 20 43 e:\jp\juce_1_13\juce\src\juce_core\text\juce_string.cpp(59) : {121} normal block at 0x0194BA10, 17 bytes long. Data: < Times > 01 00 00 00 05 00 00 00 54 69 6D 65 73 00 CD CD e:\jp\juce_1_13\juce\src\juce_core\text\juce_string.cpp(59) : {120} normal block at 0x0194B9C0, 19 bytes long. Data: < Verdana > 01 00 00 00 07 00 00 00 56 65 72 64 61 6E 61 00 Object dump complete.

Why ???

2

It’s just the names of the default fonts, which are static, so it’s not a worry, but I tried the same thing myself and didn’t get the memory leak…

I’d expect to see that leak only when the app isn’t shut down properly, so maybe you did something else that exits abruptly?

3

I don’t touch anything !!!
The HelloWorldWindow class look like :

class HelloWorldWindow  : public Component
{
public:
//==============================================================================
    HelloWorldWindow() : Component (T("Hello World"))
    {
        setOpaque (true);
        setVisible (true);
        addToDesktop (windowAppearsOnTaskbar | windowHasDropShadow);
centreWithSize(500,300);
    }
    ~HelloWorldWindow() {}

    void paint (Graphics& g)
    {
	g.fillAll(Colours::beige);
    }

    void mouseDown (const MouseEvent& e)
    {
        JUCEApplication::quit();
    }
};

And in another projects all my class have memory leaks + all class i use (tabbed component, textbutton, …)

With old version, i didn’t notice memory leaks, but now :shock:
so, is there a parameter or anything else i can verify ???

I test with a old demo project, there’s no Memory leak. If i put the HelloWorld file in this project (and i delete all other files) i have memory leaks :cry:

I see no difference …

Please give me a solution !!!

Ps : i use Visual Studio 2003

4

jules added leak dumping to 1.13. hence you don’t SEE them in earlier builds.

I get some statics leaking too.

try http://www.codeproject.com/tools/visualleakdetector.asp

It is somewhat more informative than the built in reporting in VS.

5

I try Visual Leak Detector, and now i have :

Detected memory leaks! Dumping objects -> C:\Projects\vld\vldutil.cpp(455) : {181} client block at 0x023D29F0, subtype bf42, 11268 bytes long. Data: < /= > 00 00 00 00 01 00 00 00 F4 2F 3D 02 B5 00 00 00 e:\jp\juce_1_13\juce\src\juce_core\text\juce_string.cpp(59) : {123} normal block at 0x01A336D8, 26 bytes long. Data: < Lucida C> 01 00 00 00 0E 00 00 00 4C 75 63 69 64 61 20 43 e:\jp\juce_1_13\juce\src\juce_core\text\juce_string.cpp(59) : {122} normal block at 0x01A33688, 17 bytes long. Data: < Times > 01 00 00 00 05 00 00 00 54 69 6D 65 73 00 CD CD e:\jp\juce_1_13\juce\src\juce_core\text\juce_string.cpp(59) : {121} normal block at 0x01A33638, 19 bytes long. Data: < Verdana > 01 00 00 00 07 00 00 00 56 65 72 64 61 6E 61 00 C:\Projects\vld\vld.cpp(152) : {55} client block at 0x01A35B10, subtype bf42, 11312 bytes long. Data: <<[ <a T^ > 3C 5B A3 01 3C 61 A3 01 54 5E A3 01 00 00 00 00 Object dump complete. No memory leaks detected. Visual Leak Detector is now exiting.

VLD say there’s no Memory leaks … so i think it’s good… i don’t care about these warning.

but if there’s really one leaks, i can’t see it. (in my “real” project, there’s about 175 memory leaks …)

thanks

6

VLD and the VS don’t agree on leaks apparently.

Your as well to ignore the VS leak output when using VLD.

VLD appears to be as bothered about those statics as jules is!

You’ll know all about it when you get one worth worrying about!

eg…

---------- Block 100 at 0x00D88D90: 24 bytes ----------
  Call Stack:
    0x00521432 (File and line number not available): sf_readf_float
    e:\sdk\juce\src\juce_core\text\juce_string.cpp (59): JUCE::String::createInternal
    e:\sdk\juce\src\juce_core\text\juce_string.cpp (332): JUCE::String::String
    e:\sdk\juce\src\juce_core\io\streams\juce_bufferedinputstream.cpp (167): JUCE::BufferedInputStream::readString
    e:\sdk\juce\src\juce_appframework\toolbag\juce_propertiesfile.cpp (85): JUCE::PropertiesFile::PropertiesFile
    f:\jucekali\src\gui\kalimainwindow.cpp (18): KALIMainWindow::KALIMainWindow
    f:\jucekali\src\main.cpp (40): KALIApplication::initialise
    e:\sdk\juce\src\juce_appframework\application\juce_application.cpp (163): JUCE::JUCEApplication::enterMainApplicationLoop
    e:\sdk\juce\src\juce_appframework\application\juce_application.cpp (237): JUCE::JUCEApplication::main
    f:\jucekali\src\main.cpp (85): WinMain
    f:\beta2\vctools\crt_bld\self_x86\crt\src\crt0.c (290): WinMainCRTStartup
    0x7C816D4F (File and line number not available): RegisterWaitForInputIdle
  Data:
    01 00 00 00    0C 00 00 00    43 3A 5C 74    65 73 74 61     ........ C:\testa
    72 65 61 5C    00 CD CD CD                                   rea\.... ........

here, by dbl clicking on the highest ranked line which refers to my code…

It takes me to the instantiation that never got deleted. well more usefull than the built in crap!

of course this leak was deliberatly introduced for demonstration purposes!

wouldn’t worry about the statics or any leaks that appear to come from VLD itself.

7

Karbon’s right that the leak’s not worth worrying about, but the font names should only leak if the DeletedAtShutdown objects aren’t getting shut down properly, and that’s a bit odd. Might just be something strange about your build because it works ok for me.

There’s a function called clearUpDefaultFontNames() that’s called when the typeface code shuts down and it zaps those strings to avoid the leak showing up, so you could break it there to see if that gets called when you quit.

8