Menu

#422 Magick++: Memory leak in image.write()

v1.0_(example)
closed-invalid
1
2017-05-27
2017-05-06
Ryan Cook
No

I don't know the exact cause, so I cannot reliably reproduce the error.

Valgrind output:

==25564==
==25564== HEAP SUMMARY:
==25564== in use at exit: 74,072 bytes in 20 blocks
==25564== total heap usage: 11,955 allocs, 11,935 frees, 28,809,243 bytes allocated
==25564==
==25564== 912 bytes in 3 blocks are possibly lost in loss record 11 of 12
==25564== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==25564== by 0x40136D4: allocate_dtv (dl-tls.c:322)
==25564== by 0x40136D4: _dl_allocate_tls (dl-tls.c:539)
==25564== by 0x74F526E: allocate_stack (allocatestack.c:588)
==25564== by 0x74F526E: pthread_create@@GLIBC_2.2.5 (pthread_create.c:539)
==25564== by 0xB01D99F: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==25564== by 0xB019CB9: GOMP_parallel (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==25564== by 0x7A1968E: PixelIterateMonoModify (in /usr/lib/libGraphicsMagick-Q16.so.3.14.1)
==25564== by 0x79FAC30: SyncImage (in /usr/lib/libGraphicsMagick-Q16.so.3.14.1)
==25564== by 0x7A1DED3: ??? (in /usr/lib/libGraphicsMagick-Q16.so.3.14.1)
==25564== by 0x7A1EC1F: QuantizeImage (in /usr/lib/libGraphicsMagick-Q16.so.3.14.1)
==25564== by 0x7ABDA97: ??? (in /usr/lib/libGraphicsMagick-Q16.so.3.14.1)
==25564== by 0x79CB10B: WriteImage (in /usr/lib/libGraphicsMagick-Q16.so.3.14.1)
==25564== by 0x5A42769: Magick::Image::write(std::__cxx11::basic_string<char, std::char_traits\<char="">, std::allocator\<char> > const&) (in /usr/lib/libGraphicsMagick++-Q16.so.12.0.1)
==25564==
==25564== LEAK SUMMARY:
==25564== definitely lost: 0 bytes in 0 blocks
==25564== indirectly lost: 0 bytes in 0 blocks
==25564== possibly lost: 912 bytes in 3 blocks
==25564== still reachable: 73,160 bytes in 17 blocks
==25564== suppressed: 0 bytes in 0 blocks
==25564== Reachable blocks (those to which a pointer was found) are not shown.
==25564== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==25564==
==25564== For counts of detected and suppressed errors, rerun with: -v
==25564== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)</char></char,>

Discussion

  • Ryan Cook

    Ryan Cook - 2017-05-06

    Forgot to daa: Using version 1.3.23-1build1 on linux 4.10, using build commands GraphicsMagick++-config --cppflags --cxxflags --ldflags --libs

     
    • Bob Friesenhahn

      Bob Friesenhahn - 2017-05-19

      It would be good to re-run with valgrind and using the suggested
      --leak-check=full --show-leak-kinds=all options.

      At first glance, the reported leak is due to the OpenMP implementation
      and not a true leak. It is also common to see that the C library adds
      "leaks" due to thread-specific storage which is never released. Once
      these are understood, valgrind suppressions can be added to make the
      true leaks more clear.

      The reported "73,160 bytes in 17 blocks" seems like a possible concern
      since this is quite a lot of memory. Using the extra options may
      reveal where this memory is being used.

      Bob

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

       
  • Bob Friesenhahn

    Bob Friesenhahn - 2017-05-27
    • status: open --> closed-invalid
    • assigned_to: Bob Friesenhahn
     
  • Bob Friesenhahn

    Bob Friesenhahn - 2017-05-27

    It is common or "normal" for valgrind to report possible leaks due to the behavior of the OpenMP library ("gomp") since it allocates memory for its own use which is never deallocated. The only solution is to add suppressions to valgrind.

    I do see that your program has quite a lot of additional memory allocated, which should be diagnosed as valgrind suggested in its LEAK SUMMARY message.

     

Log in to post a comment.

MongoDB Logo MongoDB