Maybe memory-management bug (Magick++/6.3.3-10)

Post any defects you find in the released or beta versions of the ImageMagick software here. Include the ImageMagick version, OS, and any command-line required to reproduce the problem. Got a patch for a bug? Post it here.
Post Reply
casey.marshall

Maybe memory-management bug (Magick++/6.3.3-10)

Post by casey.marshall »

I have been trying to use Magick++, version 6.3.3, with a debug malloc implementation from http://www.cs.berkeley.edu/~smcpeak/memory-errors/. This malloc/free does some very strict checks, and aborts at approximately this place in my code, which is creating reduced-size JPEG from an arbitrary image:

Code: Select all

	Magick::Image *image = new Magick::Image(imagepath);

        // ...code here figures out reduced dimensions, scales 'image'

	image->magick("JPEG");
	//image->write(imgdata);
	size_t length = 2048;
	MagickLib::ExceptionInfo excep;
	unsigned char *data = ImageToBlob(image->imageInfo(),
					  image->image(),
					  &length, &excep);
	fprintf(stderr, "got blob for image: %p\n", data);
	MagickLib::GetExceptionInfo(&excep);
	Magick::throwException(excep);
	MagickLib::DestroyExceptionInfo(&excep);

        // ...code here memcpy's 'data' to its destination...

	MagickLib::RelinquishMagickMemory(data);  // aborts here in free()
In my current test, the input image is also a JPEG.

This is based on what (I think) the Magick++ API does -- I first tried using Magick::Image::Write to a Magick::Blob, and was getting an error in free(); I 'expanded' what 'write', and the BlobRef destructor was doing, and got the above, and am still getting an error in free().

I also traced my malloc implementation (print every malloc() return value and every free()), and the pointer I'm being returned by ImageToBlob is never returned from any call to malloc().

Is RelinquishMagickMemory the correct call to dispose of a blob returned by ImageToBlob? If not, it looks like Magick++ is incorrect here.

Any help is appreciated.
casey.marshall

Re: Maybe memory-management bug (Magick++/6.3.3-10)

Post by casey.marshall »

Also, some info about my setup: this is a Linux 2.6.12.6 system on ARM; glibc-2.3.6. GCC 3.4.4 (release) (CodeSourcery ARM 2005q3-2). I'm configuring ImageMagick with:

Code: Select all

./configure --prefix=/usr --host=arm-none-linux-gnueabi --without-perl --without-x --bindir=${destdir}/do-not-install
I'm installing jpeg-6b, libpng-1.2.18, and libtiff-3.8.2 before ImageMagick, and am using all three as delegates.
User avatar
magick
Site Admin
Posts: 11064
Joined: 2003-05-31T11:32:55-07:00

Re: Maybe memory-management bug (Magick++/6.3.3-10)

Post by magick »

Only use MagickCore API methods as a last resort. Magick++ supports reading/writing blobs. Download the source and take a look at ImageMagick 6.3.6/Magick++/tests/readWriteBlob.cpp.

We did try your program with ImageMagick 6.3.6-1 and checked it with valgrind. Valgrind had no complaints about memory so we're not sure why your debugger is complaining.
casey.marshall

Re: Maybe memory-management bug (Magick++/6.3.3-10)

Post by casey.marshall »

Fair enough about not using MagickCore; I'd prefer not to, anyway. I was only using those methods to make debugging easier. I'm still getting a similar error if the code looks like this:

Code: Select all

	Magick::Image *image = new Magick::Image(imagepath.toString().c_str());

	// ...scale image...

	image->magick("JPEG");
	Magick::Blob *imgdata = new Magick::Blob();
	image->write(imgdata);

	// ...copy imgdata->data()...

 	delete imgdata;
FWIW, this is the stack trace from gdb (I inserted a breakpoint just before the failed assertion):

Code: Select all

#0  free (mem=0x40c00000) at malloc.c:3894
#1  0x4034739c in RelinquishMagickMemory () from /usr/lib/libMagick.so.10
#2  0x401ff960 in ~BlobRef (this=0x25cb0) at Magick++/lib/BlobRef.cpp:46
#3  0x401ff3f4 in ~Blob (this=0x25d98) at Magick++/lib/Blob.cpp:54
#4  0x400884f8 in <elided>
#5  0x00009b18 in <elided>
I mean, I wouldn't put it past this malloc implementation to have a bug of some kind, but it seems very stable otherwise, and I had previously seen glibc complain about its memory state getting trashed before linking in this malloc implementation. Valgrind doesn't work on my target, so I'm left with using an alternative malloc to debug this.

Also, if you think this works in 6.3.6 -- again, fair enough. I'll try updating to that.

Thanks.
User avatar
magick
Site Admin
Posts: 11064
Joined: 2003-05-31T11:32:55-07:00

Re: Maybe memory-management bug (Magick++/6.3.3-10)

Post by magick »

We just ran with the debugging malloc() you recommended and tried efence as well against close to 1500 regression tests and not one memory complaint was posted. As mentioned, we're using ImageMagick 6.3.6-1.
Post Reply