I have been tasked to update a legacy 32-bit C# application to support converting 4K/UHD images (jpg, tiff, etc.) to an YUV image for further processing. The way we have accomplish converting SD/HD content is by using a DLL in order to invoke an open source tool, FFmpeg, to perform the operation. This is accomplish by doing the following:
- C# application passes the image file to the DLL
- DLL then allocates the required memory needed to capture the new converted image (bytes per frame => 1080p=8.2mb, 2160p=33.2mb)
- DLL then invokes 3rd party tool by passing in pointer to file and the allocated memory buffer
- Once the function call returns, we save the converted image to a file
- Cleanup (closing files, deallocating memory, etc.)
- DLL returns true/false boolean whether it was successful or not.
Anyhow, there is a LOT more to it, but that is it in a nutshell. The problem I am having is after updating the DLL to support 4K/UHD by allocating 33mb, I now get a System.Runtime.InteropServices.SEHException; using the VS debugger, I observed a bad_allocation exception on this unmanaged C++ line
UInt32 *pixGroupFrameBuf = new UInt32[bytesPerFrameHdr/BYTES_PER_INPUT_PIXEL]; //Where UInt32[bytesPerFrameHdr/BYTES_PER_INPUT_PIXEL] is 33177600 bytes=>33mb
If I convert a 1080p jpg image, it works as its only allocates 8mb. If I convert my 4K jpg image to 1080 YUV image, which also only allocates 8mb, it works too; so its not my passed in source file. After some experiments, issue become intermittent when I attempt to allocate 28mb and throws exceptions pass 30mb. Looking at my available Free memory under the Windows Resource Monitor tool I see my system has about 4GB left.
Additionally, because our legacy C# application is very large GUI application, I decided to create a much simpler 32-bit C# application that only invokes the DLL in the same way so I can debug faster and better pinpoint the problem. What I found is my new C# project just works. I can even bump the allocation to much larger amounts and it allocates the requested size without an issue (as long as i keep it under 2GB and have enough Free memory available). Therefore, the problem lies with our much larger C# GUI application invoking the DLL.
With that I am stumped to understand what is going on with our legacy C# application and what to try next. Any chance somebody may have an idea of what could be happening or suggest what I could look at or try next?
...Here is a picture of my system resource so you can see the memory usage between my two C# applications. *_Menu.vshost.exe is our legacy app. convert.vshost.exe is my test app. As you can see our legacy C# is bigger, but not gigabytes bigger.
Final Notes:
- I am not open to convert the 32-bit C# application to 64-bit. I know its old and should be updated, but that's too big of effort to do at the moment. Also, I believe have proven it's not a 32-bit problem since my test application works.
- I am open to allocate memory within the C# application and pass it into the DLL for it to use instead of allocating within. That is my backup plan if I can't resolve it as designed.
- I don't believe I have a memory leak within DLL as I have profile it using Resharper dotMemory
- If you can't help, thanks for just being open to get this far!
The best solution I found was moving the memory allocation from being in the function to defining a global block. Instead of allocating/deallocating a block of memory for every image I converted, I changed it to use/reuse a global block (set to the max size possible). Granted, I know I can still obtain a bad_alloc if I don't have a contiguous block at construction. However, I believe this change works for me because I am not losing my 33MB contiguous block the next time I need it. My guess of what was happening - the Windows Memory Manager took my contiguous block after I freed it and eventually put me in a situation in which the next time needed a 33MB block, there wasn't anything contiguous. Hope this explanation helps someone in future.