VLD reports leaks when Juce doesn't. False positives?

General JUCE discussion
1

Hi!

I set up visual leak detector with my code, and suddenly got loads of leaks, when Juce’s leak detector reported none.

Since all leaks from VLD seem to be from the same static function (), and I found some information on the internet on it reporting false positives sometimes, I though’t I’d check here to make sure that that’s the case.

I made a test program, with the code below, in the MainComponent constructor of my program, which is reported as leaking by VLD:

Value test_Value;
test_Value = 0.0;
String test_label;
test_label = test_Value.toString();

Where that last .toString() call is reported as responsible for 5 leaks.

Should I just ignore this as a false positive, or is there something wrong in my code above? I’m relatively new to C++, but I don’t see why that code should be leaking really :slight_smile:

Oh, and I’m using the latest Juce modules, as of yesterday.

Thank you!

2

Your code creates a string and passes it to something called test_label, but you haven’t explained what that variable is. Is it a static string? If so then it’s probably still hanging around when VLD runs, and looks like a leak.

3

Hi, thanks for the quick reply!

Both variables (test_Value and test_label) are declared just above the line reported as leaking. I didn’t tag the whole thing as code, here it is again for clarity:

Value	test_Value;
test_Value = 0.0;
String test_label;
test_label = test_Value.toString();

And the line detected as leaking is only the last one.

So I imagine that as soon as the constructor in which those lines of code live ends, they go out of scope and are deleted, since they are allocated to the stack. Unless I’ve gotten something very wrong of course!

4

…And here’s the leak report from VLD, for the sake of completion:

WARNING: Visual Leak Detector detected memory leaks! ---------- Block 173958 at 0x04A15198: 44 bytes ---------- Leak Hash: 0x8DD9929E Count: 1 Call Stack: f:\dd\vctools\crt_bld\self_x86\crt\src\wsetloca.c (332): Mediator.exe!_wcreate_locale + 0x15 bytes f:\dd\vctools\crt_bld\self_x86\crt\src\wsetloca.c (399): Mediator.exe!_create_locale + 0x10 bytes x:\portableapps\mediator\jucemodules\juce\modules\juce_core\text\juce_string.cpp (459): Mediator.exe!juce::NumberToStringConverters::doubleToString + 0x19 bytes x:\portableapps\mediator\jucemodules\juce\modules\juce_core\text\juce_string.cpp (484): Mediator.exe!juce::NumberToStringConverters::createFromDouble + 0x2B bytes x:\portableapps\mediator\jucemodules\juce\modules\juce_core\text\juce_string.cpp (498): Mediator.exe!juce::String::String + 0x24 bytes x:\portableapps\mediator\jucemodules\juce\modules\juce_core\containers\juce_variant.cpp (144): Mediator.exe!juce::var::VariantType_Double::toString + 0x2A bytes x:\portableapps\mediator\jucemodules\juce\modules\juce_core\containers\juce_variant.cpp (387): Mediator.exe!juce::var::toString + 0x2F bytes x:\portableapps\mediator\jucemodules\juce\modules\juce_data_structures\values\juce_value.cpp (160): Mediator.exe!juce::Value::toString + 0x38 bytes x:\portableapps\mediator\mediator introjucer\source\mediator\maincomponent.cpp (82): Mediator.exe!MainComponent::MainComponent + 0xF bytes x:\portableapps\mediator\mediator introjucer\source\mediator\main.cpp (33): Mediator.exe!HelloWorldWindow::HelloWorldWindow + 0x22 bytes x:\portableapps\mediator\mediator introjucer\source\mediator\main.cpp (82): Mediator.exe!JUCEHelloWorldApplication::initialise + 0x25 bytes x:\portableapps\mediator\jucemodules\juce\modules\juce_gui_basics\application\juce_application.cpp (183): Mediator.exe!juce::JUCEApplication::initialiseApp + 0x2A bytes x:\portableapps\mediator\jucemodules\juce\modules\juce_gui_basics\application\juce_application.cpp (238): Mediator.exe!juce::JUCEApplication::main + 0xF bytes x:\portableapps\mediator\mediator introjucer\source\mediator\main.cpp (133): Mediator.exe!WinMain + 0x18 bytes f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c (237): Mediator.exe!__tmainCRTStartup + 0x15 bytes f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c (164): Mediator.exe!WinMainCRTStartup 0x74C133AA (File and line number not available): kernel32.dll!BaseThreadInitThunk + 0x12 bytes 0x76FF9EF2 (File and line number not available): ntdll.dll!RtlInitializeExceptionChain + 0x63 bytes 0x76FF9EC5 (File and line number not available): ntdll.dll!RtlInitializeExceptionChain + 0x36 bytes Data: 00 00 00 00 38 01 A3 04 54 31 4A 01 4C 01 00 00 ....8... T1J.L... 08 00 00 00 02 00 00 00 9C A7 02 00 FD FD FD FD ........ ........

5

Oh sorry, I mis-read it. Well, there’s certainly nothing wrong with that code… I don’t know anything about how VLD works, but I’d say it’s a probably a false alarm.

6

Ok, I’ll just tell VLD to ignore similar calls and get on with it then :slight_smile: Thank you!

7

Would be interesting to know why it’s wrong though… I’ve never tried VLD myself, but maybe someone else can offer a technical insight?

Internally, the variant class uses some in-place string constructors, so maybe that’s throwing it…

8

I imagine it is because the functions used internally are static, and VLD somehow cannot deal with static functions allocating memory.

I saw some some discussion to that effect elsewhere on the internet about VLD:

http://stackoverflow.com/questions/10730614/can-visual-leak-detector-exclude-the-false-positive-memory-leaks

but as I wasn’t sure I thought I’d ask nonetheless.

9

Ah, maybe it’s just the variant’s internal static classes that it thinks are leaking. There are a few singleton-style objects used in there, but definitely not a real leak.

10

No, VLD does actually work with static as with anything else.
VLD is a static library that’s linked with a special pragma flag telling to be started first (and ended last).

However, some static objects are never destructed when you leave your application in Juce. They’ll be cleaned by the C library. VLD can’t detect the cleaning/destruction, and report a leaks.

VLD is not completely wrong here, since a static object that’s always increasing in size (and that will be cleaned at very very last step) is not a good code anyway.
Don’t use a static ValueTree for example.

I’m using VLD on Windows and valgrind on linux, and both are reporting the exact same leaks (but as Jules said, they are not “growing”, so it’s not worth considering as a “leak”).
(Off topic, did you know that there is no “free” in busybox code at all ? This is because when a process exits, the kernel cleans the memory faster/better than you could do, and adding “free” everywhere just increase the size of the binary, which for a project like busybox, in unacceptable).