We recently updated our project to use SDK 3.3. Shortly thereafter our application started crashing after running for a while (anywhere from 30 minutes to an hour, depending on what you are doing). It usually happens in a call to glBindBuffer. When viewing the process memory usage in Windows Task Manager, we noticed that there appears to be a significant memory leak. Upon reverting back to SDK 3.2 libraries and .dll, the memory leak went away.
Is there anyone else who has experienced this? I am a bit concerned that it might be something we are doing, since the rate of memory consumption was excessive enough that I have a hard time believing it is in the SDK (about 400MB an hour, depending an what the app is doing).
We haven’t heard of this issue before. I take it you’re referring to our PVRVFrame emulation? Which OS and graphics API are you using?
If you have a minimal reproduction of the issue that you’re happy to share with us, you can attach it or discuss confidential distribution mechanisms with us via our ticketing system.
Thanks for your response. Yes, I am speaking of the emulation. We develop mostly for IOS, but have a PC build of our engine that also runs our tools and editor. While our code base is too large to include, I did a simple test using some of the test code provided with the SDK.
- copy the win32 .dll files from C:ImaginationPowerVRGraphicsSDKSDK_3.3BuildsWindowsx86_32lib into the C:ImaginationPowerVRGraphicsSDKSDK_3.3BinariesWindows_x86_32ExamplesAdvancedEvilSkull directory
- Run OGLESEvilSkull.exe
- Open Task Manager, find process OGLESEvilSkull.exe *32 and watch it’s RAM consumption slowly rise
I even checked with ProcessExplorer to verify that the .dll files that were being used were the ones I copied into that folder, and not some rogue copy from an old path or something, and they are indeed the .dll files from SDK 3.3 that were copied in step #1 above.
EvilSkull is definitely evil, and is leaking about 1MB of RAM every 5-10 minutes. While this isn’t significant, our application is much more complex, and leaks memory much faster because of it.
We are excited to update to 3.3, since it fixed some visual glitches in our editor. I’ve been around long enough to understand that it could be something crazy locally, so I’d appreciate you letting me know if this is reproducible on your end.
Thanks for the clarification. I’ve filed the issue as BRN48027 in our internal tracker. Hopefully, we’ll be able to fix it for our next SDK update.
Awesome, thanks Joe!
We are really looking forward to the next update.