[magick-users] TIFF coder race condition
Cyril VELTER
cyril.velter at metadys.com
Sat Dec 9 08:01:26 CST 2006
I'm using imagemagick in an heavily multi-threaded application. Recently I
started mixing the use of ImageMagick and direct libtiff calls to handle fax
images more efficiently and now I have seen some very strange crash/deadlock
and assertion.
I traced all these problems to the libtiff error handling which is not thread
safe.
When IM read a tiff image it sets it register it's own error/warning handler
in libtiff and set a global variable "tiff_exception" with the current image
exception for the handlers to use.
Here are two scenarios wich lead to race conditions :
Thread1 : Begin to read a tiff image with IM (set errors handlers, set
tiff_exception)
Thread2 : Begin to read a tiff image with IM (set errors handlers, set
tiff_exception)
Thread2 : End image read
Thread2 : Free image
Thread1 : an error or warning occur while reading => Crash, tiff_exception
contain the thread2 image exception which is not valid anymore
The second one involve direct libtiff call :
Thread1 : begin to read a tiff directly with libtiff
Thread2 : begin to read a tiff with IM (set errors handlers, set
tiff_exception)
Thread1 : an error or warning occur while readinf => The direct call use the
Imagemagick callback which lead to bad results.
After thinking about this I thnink the only solution which does not require
libtiff changes is to have all calls (or group of calls) to libtiff protected
by a lock. To allow use of libtiff directly the Acquire/Release lock functions
should also be exported.
On the imagemagick side, its only a matter of acquiring the lock at the
begining of ReadTIFFImage and WriteTIFFImage and releasing it at the end of
these functions.
This will effectively prevent two threads from reading/writing a tiff image
together, but I can't see another option with fixing libtiff error handling.
Comments ?
cyril
More information about the Magick-users
mailing list