Re: [GM-core] Fwd: Magick++ Bug Report
Swiss army knife of image processing
Brought to you by:
bfriesen
From: Bob F. <bfr...@si...> - 2015-02-18 04:01:52
|
On Tue, 17 Feb 2015, Hyrum Wright wrote: > See below for a bug in ImageMagick that Dirk thinks may also be in GraphicsMagick. Thanks for the heads-up. If the locking was not actually working, then one would think that a problem with locking would have been reported during the 16+ years this code has been in use. Indeed, I do not recall any bug reports regarding locking issues in Magick++. Have the object lifetime/scoping rules/behavior changed in more modern C++? Bob > > ---------- Forwarded message ---------- > From: Dirk Lemstra <di...@le...> > Date: Tue, Feb 17, 2015 at 6:28 PM > Subject: Re: Magick++ Bug Report > To: Hyrum Wright <hw...@go...> > > > Hyrum, > > You might also want to contact the maintainer of GraphicsMagick. Their code has the same issue. > > Dirk > > On 18-02-2015 00:07, Lexie Parsimoniae wrote: > > From: Hyrum Wright <hw...@go...> > Reply-To: Hyrum Wright <hw...@go...> > X-Mailer: PHP/5.3.3 > Origin: 72.14.228.1 > > On the 6.9.0 branch, Magick++/lib/Blob.cpp and Magick++/lib/Image.cpp don't do proper locking. > Specifically, the line of the form: > > Lock(&_imgRef->_mutexLock); > > or > > Lock(&_blobRef->_mutexLock); > > are wrong. These lines look like they are attempting to use RAII to ensure the mutex is unlocked when the > relevant functions return, but instead these lines create a *temporary* unnamed lock that is immediately > released. The proper fix looks something like: > > Lock lock(&_imgRef->_mutexLock); > > I count 6 instances of this bug in Blob.cpp and 8 in Image.cpp. These were found using the > misc-unused-raii check from clang-tidy. > > It doesn't look like this problem exists on trunk, since the locking has been moved to BlobRef.cpp and > ImageRef.cpp and made manual. > > -Hyrum > > > > -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |