Memory leak with Engine.loadAudioFilesIntoPool
-
@Christoph-Hart could you please look into this? Thank you!
-
Weird how I haven‘t noticed that - both the topic and the bug. Just from looking at the code it might be the case that the leaks occur only if background processing of the convolution effect is disabled, but then again I‘ve always have that enabled now.
Can you verify that? The fix with calling reset() is not the best option, there is a reason why I had to defer the deletion to the background thread (I vaguely remember it being added to fix occasional crashes).
-
@Christoph-Hart if you mean the Multithread option, have it enabled, and the bug is still there
-
@tomekslesicki alright, then I'll take a look, but it's weird that I never noticed that as I'm shipping quite a few plugins with convolution reverbs and never noticed any leaks / memory increase.
-
@Christoph-Hart I can confirm that if the multithreading option is disabled (like it is in the test project), the function that cleans up the pending impulse responses is not called periodically, but only when you close the plugin, so while it's technically not a memory leak, it certainly accumulates unnecessary resources.
This was an easy fix - not calling reset directly but making sure that the cleanup process is executed independant of the multithreading flag.
Once you enable the multithreading option, the problem goes away though - even if you deactivate the option again, as the thread keeps running so the cleanup will be performed even if the actual rendering is moved back to the audio thread.
@tomekslesicki can you check this with the test project that was uploaded earlier?
You even don't need to compile it, just look at the task manager in Windows should be enough to notice the leaks:
- Download the project, drop in any IR files
- Load the project
- Open the task manager and notice the memory usage
- Smash that combobox to load different IRs
- Notice how the number goes up.
- Now open the convolution module and enable background processing.
- The memory usage immediately drops to the original value because the old convolution objects are cleaned up at the first thread execution loop.
- Keep smashing, but now the memory usage stays down, even if you deactivate the multithreading again.
I've committed a fix so now it should clean up properly without the background thread needing to be enabled.
@tomekslesicki if your project is still exhibiting the problem we need to analyse what differs to this test project, eg:
- are you using the HISE convolution module or the convolution node?
- are you using multiple convolution modules? Have all of them set Multithreading on?
- Is the memory increase more or less proportional to the file size of the impulse responses?
-
@Christoph-Hart that seems to have fixed it on my end, thank you!
-
@Christoph-Hart well, I might have been too fast! It works on Windows, but I can't compile the network on a Mac
-
@tomekslesicki yup that is a known issue from one of my last commits. I fixed that now - can you check if the DLL compiles on macOS now?
