Handmade C++: custom memory manager for libjpeg-turbo

This is actually part 3 of my stream series about integrating libjpeg-turbo for decoding PDF data streams. I was flailing around a lot in the first two parts, so I'll upload them only if somebody asks for them.
In this part, I create my own implementation of the abstract memory manager interface of libjpeg(-turbo) in order to get full control over memory allocation in the library.
Follow my stream: / edwinst

[@27harishvk]

I am newbie to libjpeg.. i am trying to understand this library as in WPE web browser we are seeing leaks when memory is analysed using heaptrack. My observations are for a specific test, with older version of WPE i don't see leaks but with latest version of WPE we see leaks... all leaks are pointing to alloc_large in libjpeg, and alloc_large done with POOL_PERMANENT my.. dump question to you use.. can i safely change alloc_large from not allocating memory from POOL_PERMANENT and instead always use POOL_IMAGE.. do you see any functionality impacted apart from system becoming slow?.

[@EdwinSteiner]

Short answer: No, I think you should not do that.
Long answer: JPOOL_IMAGE is only meant for data that can be safely thrown away when the library is done with the particular image or when it aborts the processing of the image due to an error, etc.. In contrast, JPOOL_PERMANENT is used for data than can potentially live longer than a single image. libjpeg-turbo uses it, for example, to allocate some tables which are used for multiple images. You could get crashes when decoding a second image if you throw all this stuff away after the first image. (Note: In my copy of libjpeg-turbo I see only alloc_small being used with JPOOL_PERMANENT. Does your version also use alloc_large with JPOOL_PERMANENT?)
Suggestions:
1) Check that you are calling all necessary APIs to close down libjpeg after you are done with all images e.g. call jpeg_destroy(...) which calls "self_destruct" on the memory manager which also frees the JPOOL_PERMANENT pool.
2) If you still leak, put per-pool debug counters in the allocation / freeing functions to see clearly where the leaks come from.

[@27harishvk]

@@EdwinSteiner Thanks for your reply.

[@27harishvk]

@@EdwinSteiner To answer to your question which i didn't understand to start with, i am not using libjpeg-turbo i am using libjpeg.so.9.4.0. And in my case i do see alloc_large using JPOOL_PERMANENT.