[KPhotoAlbum] Problem running in Fedora 28

Constantin Orăsan c.orasan at gmail.com
Wed May 16 15:54:24 BST 2018


Hello,

here is the information about exiv2

Name        : exiv2
Version     : 0.26
Release     : 8.fc28
Architecture: x86_64
Install Date: Wed 25 Apr 2018 07:36:55 BST
Group       : Unspecified
Size        : 4014679
License     : GPLv2+
Signature   : RSA/SHA256, Wed 07 Feb 2018 19:51:01 GMT, Key ID
e08e7e629db62fb1
Source RPM  : exiv2-0.26-8.fc28.src.rpm
Build Date  : Wed 07 Feb 2018 09:10:41 GMT
Build Host  : buildvm-28.phx2.fedoraproject.org
Relocations : (not relocatable)
Packager    : Fedora Project
Vendor      : Fedora Project
URL         : http://www.exiv2.org/
Summary     : Exif and Iptc metadata manipulation library
Description :
A command line utility to access image metadata, allowing one to:
* print the Exif metadata of Jpeg images as summary info, interpreted
values,
  or the plain data for each tag
* print the Iptc metadata of Jpeg images
* print the Jpeg comment of Jpeg images
* set, add and delete Exif and Iptc metadata of Jpeg images
* adjust the Exif timestamp (that's how it all started...)
* rename Exif image files according to the Exif timestamp
* extract, insert and delete Exif metadata (including thumbnails),
  Iptc metadata and Jpeg comments

I reduced my photo collection to one photo and the program still crashes.
(tried with a few photos all that were imported in the past). I can obtain
the metadata with exif2 without a problem, so it does not seem to be caused
by a particular photo.

I also tried when there is a video (but I have no support for generation of
thumbnails from videos) and it still crashes.

(gdb) bt 20
#0  0x0000000000563582 in
ImageManager::ThumbnailBuilder::scheduleThumbnailBuild(DB::FileNameList
const&, ImageManager::ThumbnailBuildStart) ()
#1  0x000000000057cce5 in DB::NewImageFinder::findImages() ()
#2  0x000000000057a793 in DB::ImageDB::slotRescan() ()
#3  0x0000000000533cf9 in MainWindow::Window::delayedInit() ()
#4  0x000000000062c9fe in MainWindow::Window::qt_static_metacall(QObject*,
QMetaObject::Call, int, void**) ()
#5  0x00007ffff34f3a26 in QObject::event(QEvent*) (this=0xa75200,
e=<optimized out>) at kernel/qobject.cpp:1247
#6  0x00007ffff47c804b in QWidget::event(QEvent*) (this=this at entry=0xa75200,
event=event at entry=0x1371510) at kernel/qwidget.cpp:9343
#7  0x00007ffff48dda68 in QMainWindow::event(QEvent*)
(this=this at entry=0xa75200,
event=event at entry=0x1371510) at widgets/qmainwindow.cpp:1342
#8  0x00007ffff661ee2b in KMainWindow::event(QEvent*)
(this=this at entry=0xa75200,
ev=ev at entry=0x1371510) at
/usr/src/debug/kf5-kxmlgui-5.44.0-1.fc28.x86_64/src/kmainwindow.cpp:865
#9  0x00007ffff66684f9 in KXmlGuiWindow::event(QEvent*) (this=0xa75200,
ev=0x1371510) at
/usr/src/debug/kf5-kxmlgui-5.44.0-1.fc28.x86_64/src/kxmlguiwindow.cpp:119
#10 0x00007ffff4787e95 in QApplicationPrivate::notify_helper(QObject*,
QEvent*) (this=<optimized out>, receiver=0xa75200, e=0x1371510) at
kernel/qapplication.cpp:3732
#11 0x00007ffff478f83a in QApplication::notify(QObject*, QEvent*)
(this=0x7fffffffd170, receiver=0xa75200, e=0x1371510) at
kernel/qapplication.cpp:3491
#12 0x00007ffff34ca376 in QCoreApplication::notifyInternal2(QObject*,
QEvent*) (receiver=0xa75200, event=0x1371510) at
kernel/qcoreapplication.cpp:1050
#13 0x00007ffff34cd09b in QCoreApplication::sendEvent(QObject*, QEvent*)
(event=0x1371510, receiver=0x0) at kernel/qcoreapplication.h:234
#14 0x00007ffff34cd09b in
QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*)
(receiver=0x0, event_type=0, data=0x926510) at
kernel/qcoreapplication.cpp:1740
#15 0x00007ffff34cd4ec in QCoreApplication::sendPostedEvents(QObject*, int)
(receiver=receiver at entry=0x0, event_type=event_type at entry=0) at
kernel/qcoreapplication.cpp:1594
#16 0x00007ffff351aec7 in postEventSourceDispatch(GSource*, GSourceFunc,
gpointer) (s=0xa952d0) at kernel/qeventdispatcher_glib.cpp:276
#17 0x00007fffebf677cd in g_main_dispatch (context=0x7fffd0004ff0) at
gmain.c:3177
#18 0x00007fffebf677cd in g_main_context_dispatch
(context=context at entry=0x7fffd0004ff0)
at gmain.c:3830
#19 0x00007fffebf67b98 in g_main_context_iterate
(context=context at entry=0x7fffd0004ff0,
block=block at entry=1, dispatch=dispatch at entry=1, self=<optimized out>) at
gmain.c:3903
#20 0x00007fffebf67c30 in g_main_context_iteration (context=0x7fffd0004ff0,
may_block=may_block at entry=1) at gmain.c:3964

Does it help?

Thank you,

Constantin


On 16 May 2018 at 13:02, Robert Krawitz <rlk at alum.mit.edu> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kphotoalbum/attachments/20180516/7a8bc1ea/attachment.htm>


More information about the Kphotoalbum mailing list