I tried to run valgrind to check for memory problems on a small test project, before integrating it to the main project
It’s the first time I run valgrind on a Juce project, and valgrind reports plenty of problems. Well that’s not a huge surprise. What is surprising is where the problems appear.
Have a look at the first reported error for exemple :
==9892== Invalid write of size 8 ==9892== at 0x47F608: juce::ScopedPointer<juce::DocumentWindow::ButtonListenerProxy>::ScopedPointer() (juce_ScopedPointer.h:58) ==9892== by 0x47D6FE: juce::DocumentWindow::DocumentWindow(juce::String const&, juce::Colour const&, int, bool) (juce_DocumentWindow.cpp:79) ==9892== by 0x4108E8: MainAppWindow::MainAppWindow() (MainWindow.cpp:19) ==9892== by 0x40A99D: TestApplication::initialise(juce::String const&) (Main.cpp:40) ==9892== by 0x415EAF: juce::JUCEApplication::initialiseApp(juce::String const&) (juce_Application.cpp:171) ==9892== by 0x416174: juce::JUCEApplication::main(juce::String const&) (juce_Application.cpp:223) ==9892== by 0x41637C: juce::JUCEApplication::main(int, char const**) (juce_Application.cpp:263) ==9892== by 0x408D3F: main (Main.cpp:132)
It’s kind of confusing because my own code here, is only creating a mainAppWindow here !
On the other hand, it’s hard for me to believe that there are memory errors in a library like juce. Furthermore, I’ve seen times, for example, whith visual studio leak checker, where a leak is reported in Juce, but caused by the calling code .
Well in the end, what I would like to know, is whther jules, or someone else, tried to use valgrind on code using juce, and it came clean ?
I don’t really know how to interpret the error above (I’ve quite a few like this)
- Is it a false positive ?
- Is it a real error, but the reported location is not where the cause of the error lies ?
- There really are memory problems inside juce ?
What do you guys think ?
P.S. : The exact same code, ran on windows leads to no error at all, with all the possible run-time checks enabled in visual studio.