call to InitializeMagick required on Linux?

[wmann]

I'm using current Debian wheezy with the Debian ImageMagick packages.

A simple test program fails on a particular image with

magick/cache-view.c:477: GetCacheViewAuthenticPixels: Assertion `id < (int) cache_view->number_threads' failed.

if I do not call the InitializeMagick function. Otherwise it works fine. However, the documentation on http://www.imagemagick.org/Magick++/ says that InitializeMagick only needs to be called on "Windows and possibly the Mac". Is this statement still true?

Note that this bug first occurred in pythonmagick, which neither calls InitiaizelMagick itself nor provides an interface to call it, as far is I can see.

The test program boils down to

Image img;
img.read("filename.png");

WM

[magick]

Perhaps a transient bug. We're using ImageMagick 6.7.9-1, the latest release, and your Magick++ code works without complaint when we fail to call InitializeMagick().

[wmann]

I face this problem with the imagemagick packages in version 6.7.7.10-3, which will end up in the next stable debian release. It does not occur with every PNG, but only some. I can only reproduce this bug on two machines with x86 userland and which have at most two cores, but not within x86_64 userland on a machine with 4 cores. Test files:

http://wserver.wm1.at/~willi/debian/ima ... nmp/t1.png
http://wserver.wm1.at/~willi/debian/ima ... p/test.cpp

There are 4 threads active when the assertion fails. The backtrace of the main thread looks like this:

Code: Select all

#0  0xf7327f30 in ?? () from /usr/lib/i386-linux-gnu/libgomp.so.1
#1  0xf7328038 in ?? () from /usr/lib/i386-linux-gnu/libgomp.so.1
#2  0xf7326b2f in ?? () from /usr/lib/i386-linux-gnu/libgomp.so.1
#3  0xf75636bc in SyncImage (image=image@entry=0x8680c88) at magick/image.c:4229
#4  0xf7790e56 in ReadOnePNGImage (mng_info=0x8688908, image_info=image_info@entry=0x8678c48, exception=exception@entry=0xffdf6650)
    at coders/png.c:3233
#5  0xf77914d2 in ReadPNGImage (image_info=0x8678c48, exception=0xffdf6650) at coders/png.c:3694
#6  0xf74bacc7 in ReadImage (image_info=0x866f048, exception=0xffdf6650) at magick/constitute.c:535
#7  0xf774de1a in Magick::Image::read (this=0xffdf66b8, imageSpec_=...) at Magick++/lib/Image.cpp:1592
#8  0x080489e0 in main (argc=1, argv=0xffdf6784) at test.cpp:15

It seems that there are 4 threads forced in SyncImage, while the assertion uses the omp_get_max_threads() function to determine the upper index bound (this by default returns the number of cores). However, the OpenMP documentation says that this function is only right about the largest index as long as no num_threads clause is used - and num_threads is used in SyncImage. See http://www.openmp.org/mp-documents/OpenMP3.1.pdf, Section 3.2.3

[magick]

We believe the problem you reported is fixed in recent releases of ImageMagick. Download the latest source @ http://www.imagemagick.org/download. Download, unpack, configure, and install:

• tar xvfz ImageMagick-6.7.9-1.tar.gz
  cd ImageMagick-6.7.9-1
  ./configure
  make
  make install

Does your program work now? We tried it and it ran without complaint.

[wmann]

Confirmed, was fixed by

http://trac.imagemagick.org/changeset?r ... che-view.c