Free memory?

[spatialminds]

Is there a method that will free ImageMagick resources?

I've removed all IM calls except where the Image class is instantiated. E.g.

Code: Select all

Magick::Image symbol;

I am seeing a lot of leaks, but most of them seem to be pointint to semaphore.c.

Before I dig deeper, is there some sort of Free or Release method available to clean up after Image Magick?

Vista 64, Visual Studio 8 (2005), Magick++ version 6.4.5 dynamic.

Thanks,
Craig

[magick]

Magick++ uses standard C++ constructors / destructors. When the problem exits, the MagickCleanUp destructor is called which in turn calls MagickPlusPlusMagickCoreTerminus() which in turn calls MagickCore::MagickCoreTerminus() which cleans up all allocated memory. You should be able to call MagickPlusPlusMagickCoreTerminus() directly.

Note, we're always interested in memory leaks if you find them. Post code and a method to reproduce the leak so we can investigate.

Our regression tests include memory leak detection. Before each release we run thousands of tests and the release is not made if any leaks are revealed.

[spatialminds]

Thanks for the reply. I'll do my best to help isolate the problem.

I was able to create a very simple MFC project that reproduces the problem. You can download it from http://cid-b65b5474ac45b749.skydrive.li ... kTest2.zip

The project include/lib paths are relative, and assume that it is installed parallel to the IM directory. E.g. the following would be in the same sub-directory.

ImageMagick-6.4.5
MagickTest2


Notes:
- The leak seems related to the fact that I'm using MFC. I was unable to reproduce the problem when MFC wasn't in use.

- In this project the class MyTestClass calls Magick::InitializeMagick(NULL); in it's constructor, but the constructor is never executed because I never instantiate MyTestClass. There are no other Magick references, variables, etc anywhere in the project.

- I'm running this 32bit build under Windows Vista 64, IM 6.4.5 Dynamic w/ X11 stubs, Built under Visual Studio 2005.

- The output from Visual Studio that indicates there is a memory leak is available in a text file from http://cid-b65b5474ac45b749.skydrive.li ... |_leak.txt

[spatialminds]

Magick++ uses standard C++ constructors / destructors. When the problem exits, the MagickCleanUp destructor is called which in turn calls MagickPlusPlusMagickCoreTerminus() which in turn calls MagickCore::MagickCoreTerminus() which cleans up all allocated memory. You should be able to call MagickPlusPlusMagickCoreTerminus() directly.

Note, we're always interested in memory leaks if you find them. Post code and a method to reproduce the leak so we can investigate.

Our regression tests include memory leak detection. Before each release we run thousands of tests and the release is not made if any leaks are revealed.

I've been unable to determine how to call any of these methods from within a Magick++ application. E.g. Magick:: or Magick::Image namespaces don't appear to contain any of these methods. I'm guessing that I'm missing something obvious.

I have no doubt that you guys do a great job of testing. It's why I assumed that I was doing something incorrectly and made the post in the Developers forum instead of the Bug forum. You guys do a *great* job with IM.

[magick]

The leak seems related to the fact that I'm using MFC. I was unable to reproduce the problem when MFC wasn't in use.

Its possible the Magick++ destructor is not being called. We use valgrind under Linux to track memory leaks. If you can produce a stand alone Magick++ program that leaks we would be interested. We're using

Code: Select all

#include <Magick++.h>
#include <iostream>

using namespace std;
using namespace Magick;

int main( int /*argc*/, char ** argv)
{

  // Initialize ImageMagick install location for Windows
  InitializeMagick(*argv);
  
  try {
    Image logo("logo:");

  }
  catch( exception &error_ )
    {
      cout << "Caught exception: " << error_.what() << endl;
      return 1;
    }

  return 0;
}

And valgrind returns:

• ==4340== LEAK SUMMARY:
  ==4340== definitely lost: 0 bytes in 0 blocks.
  ==4340== possibly lost: 160 bytes in 1 blocks.
  ==4340== still reachable: 3,819 bytes in 14 blocks.
  ==4340== suppressed: 0 bytes in 0 blocks.

The possible leak is within the dynamic loader (libltdl), not ImageMagick.

[spatialminds]

OK... I did some more digging today. It turns out that the Memory Check/Dump gets called when MFC exits. Since the IM DLLs haven't unloaded already, it thinks there is a memory leak.

This is pure and simple a bug in the MFC libraries.

There is additional information about this, and how to work around it at:
http://www.eggheadcafe.com/software/asp ... rtdum.aspx
http://groups.google.com/group/microsof ... 44da9c619d