#644 Memory leak when using CoalesceImages

[zhuo]

GM version: 1.3.36
GM configure: ./configure --enable-shared
OS: ubunut:18.04

Attachment is the image file 1.gif
My test code, compile by gcc 1.c -lGraphicsMagick -I /usr/local/include/GraphicsMagick

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <magick/api.h>

void main()
{
    FILE *fp = fopen("./1.gif", "rb");
    if(fp==NULL){
        printf("open file error\n");
        return;
    }
    fseek(fp, 0, SEEK_END);
    size_t filesize = ftell(fp);
    rewind(fp);
    unsigned char *buffer = (unsigned char *)malloc(filesize * sizeof(unsigned char));
    size_t readed = fread(buffer, 1, filesize, fp);
    fclose(fp);
    printf("file size: %ld, readed: %ld\n", filesize, readed);

    //important!!!
    void *p = malloc(1024*1024*10);
    free(p);

    InitializeMagick(NULL);
    ExceptionInfo exception;
    GetExceptionInfo(&exception);
    ImageInfo *image_info = CloneImageInfo((ImageInfo *)NULL);
    Image *image = BlobToImage(image_info, buffer, filesize, &exception);
    Image *new_images = CoalesceImages(image, &exception);

    DestroyImageList(image);
    DestroyImageList(new_images);
    DestroyImageInfo(image_info);
    free(buffer);
    DestroyExceptionInfo(&exception);

    printf("done!\n");
    sleep(10000);
}

After printed "done!", using top will see about 1GB RES memory.
I using valgrind found that leaking not by GM, mybe by malloc cache

[Bob Friesenhahn]

On Tue, 6 Apr 2021, zhuo wrote:

After printed "done!", using top will see about 1GB RES memory.
I using valgrind found that leaking not by GM, mybe by malloc cache

The classic C "heap" often does not release all memory to the
operating system when the program programatically releases it. It
retains memory as a "cache". In a multi-threaded program, there is a
cache (an "arena") on a per-thread basis to make re-allocations from
the same thread faster.

Under Linux, the memory mapping/allocations may be viewed via the
/proc/PID/smaps (or /proc/self/smaps file if the program examines
itself). Do 'cat /proc/PID/smaps' where PID is the process id of the
program. The classic heap will be labeled '[heap]'.

You are able to change how GNU libc performs memory allocations using
the mallopt() function (man 3 mallopt).

There is a malloc_trim() function (man 3 malloc_trim) which may be
called in order to attempt to free classic heap memory back to the
operating system. It can only work if there are no remaining memory
allocations referring to high memory locations in the heap. You could
try using this function to see if it is successful at lessening the
remaining consumed memory.

In my experience, the described mallopt functionality is not always
what the implementation does. I have not tried using malloc_trim().

Bob

Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

[Bob Friesenhahn]

No evidence of an actual memory leak has been provided. There have been no follow-up responses from the reporter.