Legacy ImageMagick Discussions Archive

Thank you. Looking forward to getting 6.8.1-10 into production.

Your domain doesn't like Gmail ("554 554 5.7.1 Rejected 209.85.215.49 found in dnsbl.sorbs.net (state 12)"), so I have sent you a PM here with the link.

Thanks. Sent.

I have packaged everything I could think of in a tarball for you. The tarball includes a gdb coredump (usable with "gdb -c") as well as separate dumps of each memory-mapped process region. If you can give me your email, I can send you a link. I'd rather not divulge the data in public in case it ...

Well, our system is currently processing about 8000 images per hour, and we have ImageMagick processes hanging pretty much every day. What is different from your system may be that we are forking "convert" for each image. I'm going to wait for a hanging process and see if I can get some more ...

Does the API go through the same exception-handling and exiting path as exemplified by my stack trace? Does the API dump errors to stderr?

Does MagickStudio use any of the libmagick* libraries directly, or does it invoke the command line tools such as identify and convert? We also ping the image (identify -ping) to determine the original format, size, colour space, etc. before processing. However, we don't have a limit on image sizes ...

We've been using this same code for about 10 years now To be fair, though, operating systems and external library dependencies change. We have had ridiculous amounts of trouble with ImageMagick crashing, hanging and allocating huge amounts of memory on our multicore boxes, which is why we ...

Could do, although I would rather find who's locking the mutex. Any way to list known mutexes and locks, similar to the ipcs command for shared memory and semaphores?

Also: I haven't read the code, but from the stack trace it looks like it's quitting because of an exception. Is this the case?

According to the changelog, there are no pertinent fixes (related to threading, locking, SMP) between our version and the newest. As I said, the image seems to be unimportant. The locking issue happens randomly, which suggests that it's a systematic race condition, not image-related. Will try ...

Stack trace from gdb: #0 0x00007f98d5fc889c in __lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007f98d5fc4065 in _L_lock_858 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x00007f98d5fc3eba in pthread_mutex_lock () from /lib/x86_64-linux-gnu/libpthread.so.0 #3 ...