in #0 0x000000010c714b61 in juce::LeakedObjectDetectorjuce::ValueTree::SharedObject::LeakCounter::~LeakCounter() at /Users/……/juce_LeakedObjectDetector.h:92
*** Leaked objects detected: 16 instance(s) of class SharedObject
JUCE Assertion failure in juce_LeakedObjectDetector.h:92
*** Leaked objects detected: 2 instance(s) of class DynamicObject
JUCE Assertion failure in juce_LeakedObjectDetector.h:92
We had some similar errors and fixed them because we could find the class which does not leaked objects. But with these errors we can not find the class. Is there any tool to find the leaked objects? I tried https://github.com/jcredland/juce-toys/tree/master/jcf_advanced_leak_detector but the detector does not print anything, even when I continue the debugger after JUCE_LEAK_DETECTOR assert fires. I initialize “jcf::AdvancedLeakDetector advancedLeakDetector;” in multiple classes, but still no print.
Make sure to add the JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR (MyClass) or JUCE_LEAK_DETECTOR (MyClass) to all your own classes, so they can be detected as well.
That helps you to find the enclosing class that is leaking (assuming it is one of yours, but that’s most likely given that this is the only code nobody tests besides yourself)
You can add it to the definition of the leaked object’s class e.g. SharedObject. In this case you will have to replace the JUCE_LEAK_DETECTOR macro with the heavyweight version.
On top of detecting the leak this will also print a stack trace to help finding where the allocation happened.
Once the leak has been fixed you should switch back to the simple leak detector though, as saving the stack trace for every allocation is pretty expensive.
I’m having this problem on Monterey M1 desktop app, I have JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR (MyClass) in all of my classes but get:
*** Leaked objects detected: 328 instance(s) of class SharedObject
JUCE Assertion failure in juce_LeakedObjectDetector.h:92
(lldb)
I’ve scoured my code, I am not using new/delete anywhere and using unique_ptr and shared_ptr for all dynamic objects. The only exception is FileBrowserComponent which I can’t make work with unique_ptr. however I’ve compiled with that commented out and it isn’t the problem.
Presumably SharedObject is just a generic warning, so without knowing the offending class name I guess JUCE_HEAVYWEIGHT_LEAK_DETECTOR won’t help me?
Wondering if anyone has any tips on dealing with this situation?
SharedObject is used to implement ValueTree, so I assume a ValueTree is being leaked somehow. You could try adding a heavyweight leak detector to the definition of ValueTree and see whether it gives you any useful info.
Thanks very much, this narrowed down the problem and it was down to Valuetree and scope, it’s a massive relief to have it solved! On the plus side it made me really tighten up my code whilst hunting it down.
