I am new to JUCE, however I have been strugling to discover why CameraDevice::openDevice() static function leaks memory even if you delete the CameraDevice returned.
I mean I was leaking memory in my own project but then I openned and debugged the cameraDemo, and I realized that even the demmmo drains memory each time you open a device, it gets destroyed but the without releasing the same amount of memory it took.
Anyone knows why this happenned or how to fix it? I have just kept the pointers to CameraDevices it returns instead of deleting them because of this, however I think it can be a bug to be fixed in the future.
juce::CameraDevice is a cross-platform abstraction, which has very different implementations on each platform. In order to help you track down this memory leak, we need to know on which platform you are running and debugging your own project and the CameraDemo.
We also need to know how you are detecting your leaks.
We get a fair number of people reporting that the system memory usage is increasing with runtime, but this often just means that the OS is choosing not to reuse memory for new allocations, rather than an actual memory leak. If, however, you are triggering JUCE’s leak detector, you can show that a destructor isn’t being called for a matching constructor, or you are seeing un-freed memory messages from your IDE, compiler or Valgrind then that’s worth investigating.
Hi @McMartin and @t0m. First of ll thank you or the quick answer to my issue.
I am running it in Windows 10 and with visual studio 2017. I have detected the leak looking at the memory used by application with the debugging tools of visual studio and also with the Windows task manager both in release and debug.
I am not getting any juce leak detection for not destroying appropriately the object. If you just run the camera demo and look at its stats in the task manager you can realise that switching from no camera to the local webcam or other cam like the usb capture device that I am using the memory increases every time when it is supposed to stay stable because the camera demo creates and destroys the objected previously opened.
So as you say is maybe de SO I don’t know but it doesn’t seem normal to me.
As I said, Windows can choose not to reuse memory it has freed. This means that indicators like the Windows task manager and similar often make it look like your application is using increasing amounts of memory with time, but the reality is that everything is being cleaned up correctly.
Yes exactly, that’s how I realized for the first time. I attached a screen image showing that each time the camera demo destroys a device and opens a new one, the memory used increases more than it frees without upper limit!
Any indicator that is just a simple measure of how much memory a process is using, including the graph in Visual Studio’s Diagnostic Tools window, can display increasing memory usage because the OS decides not to reuse memory that has actually been freed by the process.
I sent you that link because it describes the process of taking a snapshot of the memory used by your program, which you can then compare with a reference state. This is the only reliable way to detect leaks in your code, other than actively monitoring calls to destructors or other purpose built compiler tools like Valgrind.
If you do this after going through the process of opening then closing the camera you will see that the size of the heap stays more or less constant (it will fluctuate a little because it contains things like GUI event-loop messages), but the graph shows a 6 MB jump upwards.
I am seeing this issue as well (building with VS2019). To demonstrate that this is indeed a leak, I wrote a PIP that repeatedly opens and closes the camera. The heap does increase over time and eventually my machine crashes and needs a reboot.
The snapshots show the majority of the memory going to “Unresolved Allocations” so nothing blatantly obvious.
I am also able to demonstrate the memory increase by repeatedly opening and closing the camera in the DemoRunner CameraDemo. Just for reference, I tried repeatedly opening and closing the camera in a non-Juce app (OBS) and saw no memory change.
Here is a screenshot from my Diagnostics Tools while running the PIP
