[Pkg-gmagick-im-team] Bug#622591: crash in ChertVersion::create

[Olly Betts]

retitle 622591 SEGV with libuuid and imagemagick
thanks

On Mon, May 09, 2011 at 05:45:30AM +0100, Olly Betts wrote:
> On Wed, Apr 13, 2011 at 12:22:28PM -0400, Joey Hess wrote:
> > Here is a minimal test case to reproduce this bug. I've gotten all
> > content and ikiwiki out of the picture, we're down to 2 perl modules
> > and perl itself.
> > 
> > #!/usr/bin/perl
> > use Image::Magick;
> > use Search::Xapian;
> > $db=Search::Xapian::WritableDatabase->new("/tmp/xap",
> > 	Search::Xapian::DB_CREATE());
> 
> I've managed to go further, and remove Search::Xapian from the picture:
> 
> $ perl -MImage::Magick -MUUID -e 'UUID::generate($uuid)'
> Segmentation fault
> 
> > Note that order matters. If Search::Xapian is loaded before
> > Image::Magic, no crash. This strongly points to an Image::Magick bug to
> > me, or possibly, multiple interacting bugs.
> 
> And here too the order matters, as this works:
> 
> $ perl -MUUID -MImage::Magick -e 'UUID::generate($uuid)'
> 
> > I can reproduce it on stable and unstable; amd64, and i386.
> 
> Above was on amd64 stable.
> 
> Reassigning to perlmagick, which I agree with Joey is the most likely
> culprit.

We had a Xapian user experiencing a crash in libuuid with Xapian's PHP
bindings, running Ubuntu natty on x86-64.  He discovered the crash went
away when he uninstalled an "imagemagick plugin".

With this clue, I've managed to reproduce this on Debian stable x86-64 by
installing php5-imagick and trying to open a chert database using
Xapian's PHP bindings (which aren't packaged for Debian currently due to
GPL vs PHP licence incompatibility).  If I purge php5-imagick, it works.

I suspect this could be reproduced with any compiled PHP extension which
uses libuuid, but the obvious candidate is php5-uuid which is based on
the OSSP uuid library (not the e2fsprogs one), and I couldn't easily spot
anything else suitable.

Anyway, I think this rather suggests it's more likely to be imagemagick
itself that's to blame here, rather than perlmagick.

I noticed that we're pulling in libuuid1 via imagemagick like so:

$ aptitude why php5-imagick libuuid1
p   php5-imagick   Depends libmagickwand3 (>= 7:6.6.0.4)
i A libmagickwand3 Depends libsm6                       
i A libsm6         Depends libuuid1 (>= 2.16)           

So in all the situations we've seen which cause problems, we are getting
libuuid1 being used by two different dynamically loaded shared objects.
I'm not clear why that's causing a problem, but hopefully someone will
find this extra information useful...

Cheers,
    Olly