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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
