Some sections of the ghostscript code still call direct to malloc/free rather than using the ghostscript memory functions. One such example of this is the luratech jbig2 wrappers. We should grep the source for a list of all such places, document it here, then fix it. Initially at least I am assigning this bug to Alex as he 'owns' the luratech wrappers.
Assigning to Alex.
Calls to malloc() have been eliminated in JPX code. http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=6cbb5969cc2edab6417c673194f1c1d019d275ef There are still malloc() calls in OpenJpeg library that has no API to introduce a custom memory allocator.
This is very low priority since the only ones we've seen that really care about controlling the allocator are embedded customers and they use (or should use) the Luratech decoder. About the only impact of not using the gs allocators is that the -K limit and the memory use reporting will not take into account openjpeg allocations (and any leaks in the openjpeg code will not be as evident without using OS tools).
Passing to Henry as openjpeg is a decoder. Not sure of v2 allows us a custom memory allocator or not.
v2 does not fix this. We *could* add some small tweaks in opj_malloc.h to add a new predefine that would force everything through opj_{malloc,calloc,realloc,free,aligned_{malloc,free}} (indeed PERF_MALLOC_OPT almost does this, but ends up mapping aligned_malloc onto opj_malloc), but this doesn't help us as we have no way of getting a gs_memory_t * into those functions. We could fudge it with a static variable, and wrapping all the opj calls in a lock, but that's horrid. The API changes to fix openjpeg are equally horrid though :(
The OpenJpeg library that is bundled with Ghostscript still has no memory allocation callbacks.