#23 Memory leak due to ResizeImage

[nikhil]

Hi, I am using graphicsmagick for resizing the images and I am able to see the resized output images but, later on I found that there is a memory leak which has been introduced due to ResizeImage call. Need your help to remove the memory leak. I am using DestroyImageList, DestroyImageInfo and DestroyMagick at the end. Any other API that need to be called?

[Bob Friesenhahn]

What operating system are you using? Is OpenMP enabled in the GraphicsMagick build? What tool are you using to detect the memory leak? Is more and more memory consumed if ResizeImage() is invoked repeatedly, or does the memory usage hit a peak and then remain the same?

Please note that the C library often performs some singleton allocations which it does not give up and may show up as a "leak" at program exit. Also, the OpenMP implementation often performs some singleton allocations which may cause 4-5k bytes of memory allocation to exist at program exit. There is nothing to be done about these allocations. Tools like valgrind are already trained to ignore these apparent leaks.

[nikhil]

Hi Bob,
Thanks for the reply. I am using CentOS 7 and openmp is disabled. I am using dmalloc library to detect the memory leak. And ResizeImage is being called again and again in my code and on each call, the memory consumed increases significantly (much more than 4-5k bytes). Earlier when I was using DestroyImage to free the image structure, I was getting memory leak which got resolved by using DestroyImageList. But, I am unable to trace this leak introduced after using ResizeImage.

[Bob Friesenhahn]

In my experience, using valgrind's 'memcheck' tool is the most effective at finding memory problems like memory leaks and at pin-pointing where the leaking allocation was made and at detecting problems like overwriting the pointer for ane existing allocation. It is best to use a debug build with -g added to CFLAGS. The leak might be in the GraphicsMagick library, but it is more likely something wrong with the application code which is calling it.

I have not used dmalloc in a great many years. Given the other tools available, I would only turn to something like dmalloc if the other tools are not available to execute on the target.

You did not say what version of GraphicsMagick you are using. We are continually finding and fixing memory leaks but these are usually in seldom-executed error recovery paths. The normal execution paths have been tested for many years already.

[nikhil]

i am using graphics magick 1.3.21, and i am using dmalloc to find the leaks and so far it is working well for me.

[Bob Friesenhahn]

Since yesterday, there is now a GraphicsMagick 1.3.22.

Have you located the cause of the leak?

[nikhil]

when i disable the resizeimage call, it works fine but once it is enabled, i can see the leak. didnt get the chance to dig deep into the resizeimage api. but, i think the issue is with resizeimage only. do u have any suggestion for any alternate api which i could use in place of resizeimage?

[nikhil]

Hi Bob,
I have upgraded to GraphicsMagick-1.3.22. Now, I am using valgrind to check the memory leak. And still I am able to see the leak. Could you please provide me a sample code where you are using ResizeImage and has no memory leaks.

[Bob Friesenhahn]

Duplicate of issue #25, which includes actual source code.