I have been developing an audio plugin with Juce for a while using OpenGL rendering for GUI purposes. However, I was having troubles with memory allocation lately. After digging into my codes a bit, I have just realised that attaching my OpenGLRenderer to my OpenGLContext and displaying it in the editor itself eats up memory continuously. In other words, I noticed that there is a memory leak which makes the allocated memory grows up to 5mb in each minute even when I turn off everything but my gl renderer (with empty functions). Furthermore, I have noticed OpenGL part of Juce Demo has the similar problem as well, if I’m not mistaken.
Hence, I would like to know if it is a known issue, or any of you encountered a similar one. I couldn’t find any thread about this kind of problem though. I am not really good at such memory management in C++, so there might be something I have overlooked. I hope someone could help me out in this one. Thank you.
P.S. : I am testing the application on Windows 7 64-bit in Ableton Live using the VST export.
Not a known issue, but I’d be keen to fix it if it is indeed a real leak!
Would be really helpful if you could post a snippet of code that makes it happen, so we can sanity-check that it’s not your own code that’s leaking…
[quote=“jules”]Not a known issue, but I’d be keen to fix it if it is indeed a real leak!
Would be really helpful if you could post a snippet of code that makes it happen, so we can sanity-check that it’s not your own code that’s leaking…[/quote]
Yeah, I’m kind of hoping that my code produces that leak as well, not the library. On the other hand, I have tested Juce Demo once again, which is provided in the extras folder, by compiling with VS2010 (without any changes). Monitoring the Windows Task Manager, after I have chosen OpenGL tab from the top panel, the memory allocation started about 31MB, and increased around to 39MB in 5 minutes (still growing - around 45MB right now). I will also simplify my code and provide it here as soon as possible for you to check if there are any other related problems. Thank you very much for immediate response by the way!
Hmm. I’m doing a lot of GL at the moment and would like to make sure it’s watertight… Very odd though, all my objects are thoroughly leak-checked.
To be sure, I have downloaded both the latest bleeding-edge release from GitHub and 2.0 stable release from SourceForge, and tested them. Still no luck. Even running the jucedemo that is available as executable here gives a similar result (actually worse). I am not sure if there might be any computer/OS specific problems that would lead to this issue, you might check it as well though to validate whether it is a generic problem or not. Please let me know if there are any further things I can do to resolve the issue. Thanks in advance.
I checked the juce demo running on Windows, and can’t see any leaks… Visual leak detector says nothing is leaking, and even looking at the total memory used in the task manager, it’s staying constant.
Could be your GL driver? Have you run Visual leak detector yourself?
[quote=“jules”]I checked the juce demo running on Windows, and can’t see any leaks… Visual leak detector says nothing is leaking, and even looking at the total memory used in the task manager, it’s staying constant.
Could be your GL driver? Have you run Visual leak detector yourself?[/quote]
Yeah, you are right. I’ve run Visual leak detector on VS and no leak is detected. So, I suppose it is not related to the application at all. Besides, I have tried to update my graphics card driver and all, but the problem remains. Do you know any possible ways to fix it? I have a NVIDIA Geforce GT 630M, not sure how to fix this issue.
Additionally, it’s a bit off-topic question, but is there an efficient way to use Visual Leak Detector or something like that suitable with audio plugins. Since I cannot run the .dll export on Visual Studio, I cannot check if there are any other memory leaks directly from Debug mode.
Probably a driver bug then, or just heap fragmentation… Not sure what to suggest!
Re: leaks in plugins, haven’t got a good answer for that. My general policy is just to not leak in the first place
That makes sense. I’m just starting to be paranoid about my code, as it’s already be leaking in the first place! Anyway, thank you for spending your time on this, and sorry for the “fake” leak thingy…
It may be a real leak - but not necessarily in any code that we have access to…