[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