Magick++ writeImages (STL.h) has memory leak ? ^_^;;

[blue0sky]

this is my test code

Code: Select all

#include <list>
#include <string>
#include <Magick++.h>

int main(int argc, char** argv) {
        std::string filename = argv[1];
        std::list<Magick::Image> imageList;
        readImages(&imageList, filename);
        
        Magick::Geometry size;
        size.width(100);
        size.width(100);

        std::list<Magick::Image>::iterator iter;
        for(iter = imageList.begin(); iter != imageList.end(); ++iter) {
                (*iter).sample(size);
        }

        writeImages(imageList.begin(), imageList.end(), filename + ".gif", true);

        return 0;
}

valgrind --leak-check=full ./a.out lg_naver_v3.gif
(test image : http://wstatic.naver.com/w9/lg_naver_v3.gif)
(Linux 2.6.18-53.1.14.el5 x86_64 GNU/Linux, ImageMagick 6.5.6-0)

this is valgrind report

Code: Select all

==26565== Memcheck, a memory error detector.
==26565== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==26565== Using LibVEX rev 1658, a library for dynamic binary translation.
==26565== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==26565== Using valgrind-3.2.1, a dynamic binary instrumentation framework.
==26565== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==26565== For more details, rerun with: -v
==26565==
==26565== My PID = 26565, parent PID = 26300.  Prog and args are:
==26565==    ./a.out
==26565==    lg_naver_v3.gif
==26565==
==26565==
==26565== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 1)
==26565== malloc/free: in use at exit: 45,990 bytes in 1,456 blocks.
==26565== malloc/free: 1,758 allocs, 302 frees, 580,479 bytes allocated.
==26565== For counts of detected errors, rerun with: -v
==26565== searching for pointers to 1,456 not-freed blocks.
==26565== checked 11,688,744 bytes.
==26565==
==26565== 128 (64 direct, 64 indirect) bytes in 1 blocks are definitely lost in loss record 9 of 23
==26565==    at 0x4A05809: malloc (vg_replace_malloc.c:149)
==26565==    by 0x4C9FF2: NewLinkedList (hashmap.c:1409)
==26565==    by 0x4B4C11: GetExceptionInfo (exception.c:423)
==26565==    by 0x417DFF: void Magick::writeImages<std::_List_iterator<Magick::Image> >(std::_List_iterator<Magick::Image>,
    std::_List_iterator<Magick::Image>, std::string const&, bool) (in /home1/irteam/src/nivfs/a.out)
==26565==    by 0x417389: main (in /home1/irteam/src/nivfs/a.out)
==26565==
==26565==
==26565== 304 bytes in 1 blocks are possibly lost in loss record 12 of 23
==26565==    at 0x4A04B32: calloc (vg_replace_malloc.c:279)
==26565==    by 0x3B0260FDF2: _dl_allocate_tls (in /lib64/ld-2.5.so)
==26565==    by 0x3B03606A33: pthread_create@@GLIBC_2.2.5 (in /lib64/libpthread-2.5.so)
==26565==    by 0x505F7D0: (within /usr/lib64/libgomp.so.1.0.0)
==26565==    by 0x51BC15: SampleImage (resize.c:2281)
==26565==    by 0x4245B5: Magick::Image::sample(Magick::Geometry const&) (Image.cpp:1740)
==26565==    by 0x417327: main (in /home1/irteam/src/nivfs/a.out)
==26565==
==26565== LEAK SUMMARY:
==26565==    definitely lost: 64 bytes in 1 blocks.
==26565==    indirectly lost: 64 bytes in 1 blocks.
==26565==      possibly lost: 304 bytes in 1 blocks.
==26565==    still reachable: 45,558 bytes in 1,453 blocks.
==26565==         suppressed: 0 bytes in 0 blocks.
==26565== Reachable blocks (those to which a pointer was found) are not shown.
==26565== To see them, rerun with: --show-reachable=yes

Magick++ writeImages (STL.h) has memory leak ? ^_^a

[blue0sky]

i test something

writeImages method (STL.h)

Code: Select all

if ( errorStat != false )
{
   MagickCore::DestroyExceptionInfo( &exceptionInfo ); // add 
   return;
}

i think that is one of reason

[magick]

Your patch appears to fix the problem. If you find other leaks, let us know. Thanks.

[rputtick]

I have also had severe leak problems with the ImageMagick library. Specifically I have a large set of images for which Image::ping throws a warning exception that I have to ignore. In reading the DestroyExceptionInfo code that it calls through the throwException method I'm at a loss as to how DestroyExceptionElement is called on the input parameter. It is called on the member linked list via DestroyLinkedList but never on the input pointer itself. It would appear that this would leak the reason and description members of the structure.