[KPhotoAlbum] Problem running in Fedora 28

[Robert Krawitz]

On Wed, 16 May 2018 12:16:49 +0100, =?UTF-8?Q?Constantin_Or=C4=83san?= wrote:
> Hello,
>
> I haven't programmed in C for a very loooooong time, so my gdb stills are
> very rusty (to put it mildly).
>
> After struggling with dnf to get the correct debuginfo for packages (Fedora
> seems to be a bit problematic about this), I managed to produce the
> following backtrace.
>
> (gdb) bt 20
> #0  0x00007ffff2595f4b in __GI_raise (sig=sig at entry=6) at
> ../sysdeps/unix/sysv/linux/raise.c:50
> #1  0x00007ffff2580591 in __GI_abort () at abort.c:79
> #2  0x00007ffff77491a8 in std::__replacement_assert(char const*, int, char
> const*, char const*) (__file=__file at entry=0x7ffff78644b0
> "/usr/include/c++/8/bits/stl_vector.h", __line=__line at entry=950,
> __function=__function at entry=0x7ffff78671a0 <std::vector<std::pair<unsigned
> int, unsigned int>, std::allocator<std::pair<unsigned int, unsigned int> >
>>::operator[](unsigned long) const::__PRETTY_FUNCTION__> "std::vector<_Tp,
> _Alloc>::const_reference std::vector<_Tp,
> _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) const [with _Tp =
> std::pair<unsigned int, unsigned int>; _Alloc = std::allocator<std"...,
> __condition=__condition at entry=0x7ffff7864480 "__builtin_expect(__n <
> this->size(), true)") at
> /usr/include/c++/8/x86_64-redhat-linux/bits/c++config.h:2389
> #3  0x00007ffff7760dab in std::vector<std::pair<unsigned int, unsigned
> int>, std::allocator<std::pair<unsigned int, unsigned int> >
>>::operator[](unsigned long) const (__n=<optimized out>, this=<optimized
> out>) at ../include/exiv2/value.hpp:1719
> #4  0x00007ffff7760dab in Exiv2::ValueType<std::pair<unsigned int, unsigned
> int> >::toRational(long) const (this=<optimized out>, n=<optimized out>)
>     at ../include/exiv2/value.hpp:1719

Above this point we're no longer in KPhotoAlbum, but in exiv2, loading
the EXIF data from one of the images.  What version of exiv2 is
installed (rpm -qi exiv2) is installed?

I'm still wondering if you have a particular image in your collection
that is causing exiv2 to get unhappy.  The fact that it happens at
different points within the import may not be significant, since the
files are imported in arbitrary (and not necessarily reproducible)
order.

It could, of course, be something in kpa corrupting memory, but that
would more likely in my view create really weird-looking errors.

What happens if you run

exiv2 <files>

on the files you're trying to import?

> #5  0x00000000005e7d59 in
> Exif::RationalExifElement::valueFromExif(Exiv2::ExifData&) const ()
> #6  0x00000000005ce1e0 in Exif::Database::insert(QList<QPair<DB::FileName,
> Exiv2::ExifData> >) ()
> #7  0x00000000005cd161 in Exif::Database::add(DB::FileNameList const&) ()
> #8  0x00000000004a435e in XMLDB::Database::forceUpdate(DB::ImageInfoList
> const&) ()
> #9  0x00000000004a46f6 in XMLDB::Database::addImages(DB::ImageInfoList
> const&, bool) ()
> #10 0x000000000057d9fc in DB::NewImageFinder::loadExtraFiles(bool) ()
> #11 0x000000000057cc35 in DB::NewImageFinder::findImages() ()
> #12 0x000000000057a793 in DB::ImageDB::slotRescan() ()

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton