Legacy ImageMagick Discussions Archive

For the past few days, I've been looking into a segfault that happens when running any of the ImageMagick utilities (i.e. even a simple "mogrify foo.gif"). What seems to be happening is that the crash occurs when trying to lock the semaphore mutex (the one that is used internally to semaphore.c and is locked and unlocked during the AcquireSemaphoreInfo() call, for example).

Specifically, this happens when the "curthread" in pthreads changes to a different thread than had been used previously. From looking at the IM code, I cannot tell when/where a new thread would be created. It appears that the mutex data structure (specifically the "first" and "last" values in the mutex linked list internal to the libthr/pthreads stuff) from the point of view of the different thread is different, and this is what causes the crash when the lock is attempted.

Note that when using libpthread, it does *not* crash, but when libpthread is mapped to libthr (which is the trend - i.e. in FreeBSD 7.0, I believe libthr will take over pthread's functionality), it does crash. I am not sure if this is due to libpthread's being more accepting of non-strict use of pthreads or if there might be a bug in libthr. However, it seems that pthreads need to be created in order to be valid, and I do not see any calls to pthread_create() in the code, so that might have something to do with it. It's pretty complicated, which is why I wanted to post here before going too crazy!

Here is the traceback:

#0 0x284f601d in mutex_lock_common (curthread=0x804b300, m=0x282599e8,
abstime=0x0)
at /var/tmp/portage/sys-freebsd/freebsd-lib-6.2-r1/work/lib/libthr/thread/thr_mutex.c:521
#1 0x2818dc74 in my_pthread_mutex_lock (m=0x282599e8)
at magick/semaphore.c:133
#2 0x2818dea0 in AcquireSemaphoreInfo (semaphore_info=0x804d1e4)
at magick/semaphore.c:186
#3 0x28196532 in AddValueToSplayTree (splay_info=0x804d1c0, key=0x804c160,
value=0x804d300) at magick/splay-tree.c:159
#4 0x2814f9ea in OpenModule (module=0xbfbf8228 "GIF", exception=0xbfbfb228)
at magick/module.c:1235
#5 0x2814c0c8 in GetMagickInfo (name=0xbfbf8228 "GIF", exception=0xbfbfb228)
at magick/magick.c:457
#6 0x2813cd06 in SetImageInfo (image_info=0x8055000, rectify=MagickFalse,
exception=0xbfbfe478) at magick/image.c:3095
#7 0x280d4b93 in ReadImage (image_info=0x8050000, exception=0xbfbfe478)
at magick/constitute.c:338
#8 0x282f1e33 in MogrifyImageCommand (image_info=0x8050000, argc=2,
argv=0x804c120, wand_unused_metadata=0x0, exception=0xbfbfe478)
at wand/mogrify.c:3339
#9 0x080489ed in main (argc=2, argv=0xbfbfe4ec) at utilities/mogrify.c:100

If anyone who knows the IM internals can shed some light on how I might delve into this a little further, it would be *really* appreciated.

I'm using IM 6.3.4.

Thanks, Joe

libthr is supposed to be a 1:1 replacement for Posix threads so it should work but perhaps there is a bug in libthr. Our only suggestion is try upgrading ImageMagick to the latest release, 6.3.5-8. In the mean-time we trying to see if there is anything we can do at our end but so far our analysis of the code is that the ImageMagick threading code is correctly implemented.

Try removing this line in magick/.semaphore.c:

• (void) pthread_mutexattr_settype(&mutex_info,PTHREAD_MUTEX_RECURSIVE);

There is a bug report for libthr concerning this attribute.

magick wrote:Try removing this line in magick/.semaphore.c:

• (void) pthread_mutexattr_settype(&mutex_info,PTHREAD_MUTEX_RECURSIVE);

There is a bug report for libthr concerning this attribute.

Hi! I just tried this, and it still crashes.

Tell me this if you can: does simply running mogrify (or other util) create multiple threads? I cannot see in the IM code where this would be done, but I see the curthread pointer change just before the crash (i.e. the pointer in libthr). it appears to be a slightly higher address than the original thread, which makes sense if it is getting allocated after. It would help me to debug further if I knew where a new thread was getting created.

-Thanks! Joe

ImageMagick runs in one thread with one exception. If ImageMagick is built with OpenMP enabled, a few methods spin off threads for certain loops such as in ConvolveImage() (look for the pragma statement in the source distribution).