[KPhotoAlbum] Problem running in Fedora 28

Discussion:

Constantin Orăsan

2018-05-14 12:06:34 UTC

Hello,

It seems that after I upgraded to F28 I can no longer start KPA. The crash
happens while it imports about 1000 new images, but it does not seem to be
related to a particular photo/movie because the progress bar reaches
various points (once it even finished).

I get the following error message on 2 different computers. On one of them
I tried KPA 5.2.7 (the version that comes with F28), KPA5.3 and the version
from git. The last two were compiled me.

----
/usr/include/c++/8/bits/stl_vector.h:950: 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::pair<unsigned int, unsigned int> >; std::vector<_Tp,
_Alloc>::const_reference = const std::pair<unsigned int, unsigned int>&;
std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion
'__builtin_expect(__n < this->size(), true)' failed.
Aborted (core dumped)
----

Any idea where to start debugging? KPA is complaining that I have mplayer
installed, but I suppose it should not cause a crash.

Thank you,

Constantin

Tobias Leupold

2018-05-14 12:32:10 UTC

Permalink

Hello Constantin!

I don't see such an error here using Gentoo, Qt 5.9.4 and gcc 6.4.0.

Could you send a complete backtrack (e. g. by using gdb)? Best thing would be
to find out where exactly the problem happens. Try to start the git self-
compiled version using "gdb ./kphotoalbum" and then "run", do whatever causes
the crash and see what's happening. Most probably, you'll find some hint where
we have the problem (cpp file, line).

I'm pretty sure we can fix this, with a bit more information ;-)

Thanks in advance for your effort!

Cheers, Tobias

Post by Constantin OrÄsan
Hello,
It seems that after I upgraded to F28 I can no longer start KPA. The crash
happens while it imports about 1000 new images, but it does not seem to be
related to a particular photo/movie because the progress bar reaches
various points (once it even finished).
I get the following error message on 2 different computers. On one of them
I tried KPA 5.2.7 (the version that comes with F28), KPA5.3 and the version
from git. The last two were compiled me.
----
/usr/include/c++/8/bits/stl_vector.h:950: 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::pair<unsigned int, unsigned int> >; std::vector<_Tp,
_Alloc>::const_reference = const std::pair<unsigned int, unsigned int>&;
std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion
'__builtin_expect(__n < this->size(), true)' failed.
Aborted (core dumped)
----
Any idea where to start debugging? KPA is complaining that I have mplayer
installed, but I suppose it should not cause a crash.
Thank you,
Constantin

Constantin Orăsan

2018-05-14 13:09:32 UTC

Permalink

Hi Tobias,

Thank you for the reply. I will try to debug later today. I need to install
lots of debuginfos and I prefer to do it in a virtual machine. I will get
back to you as soon as I have any hints.

Regards,

Constantin

Post by Tobias Leupold
Hello Constantin!
I don't see such an error here using Gentoo, Qt 5.9.4 and gcc 6.4.0.
Could you send a complete backtrack (e. g. by using gdb)? Best thing would be
to find out where exactly the problem happens. Try to start the git self-
compiled version using "gdb ./kphotoalbum" and then "run", do whatever causes
the crash and see what's happening. Most probably, you'll find some hint where
we have the problem (cpp file, line).
I'm pretty sure we can fix this, with a bit more information ;-)
Thanks in advance for your effort!
Cheers, Tobias

Post by Constantin OrÄsan
Hello,
It seems that after I upgraded to F28 I can no longer start KPA. The

crash

Post by Constantin OrÄsan
happens while it imports about 1000 new images, but it does not seem to

Post by Constantin OrÄsan
related to a particular photo/movie because the progress bar reaches
various points (once it even finished).
I get the following error message on 2 different computers. On one of

them

Post by Constantin OrÄsan
I tried KPA 5.2.7 (the version that comes with F28), KPA5.3 and the

version

Post by Constantin OrÄsan
from git. The last two were compiled me.
----
/usr/include/c++/8/bits/stl_vector.h:950: std::vector<_Tp,
_Alloc>::const_reference std::vector<_Tp,
_Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) const [with _Tp

Post by Constantin OrÄsan
std::pair<unsigned int, unsigned int>; _Alloc =
std::allocator<std::pair<unsigned int, unsigned int> >; std::vector<_Tp,
_Alloc>::const_reference = const std::pair<unsigned int, unsigned int>&;
std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion
'__builtin_expect(__n < this->size(), true)' failed.
Aborted (core dumped)
----
Any idea where to start debugging? KPA is complaining that I have mplayer
installed, but I suppose it should not cause a crash.
Thank you,
Constantin

_______________________________________________
KPhotoAlbum mailing list
https://mail.kdab.com/mailman/listinfo/kphotoalbum

Constantin Orăsan

2018-05-16 11:16:49 UTC

Permalink

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=***@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=***@entry=0x7ffff78644b0
"/usr/include/c++/8/bits/stl_vector.h", __line=***@entry=950,
__function=***@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=***@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

Hi Tobias,
Thank you for the reply. I will try to debug later today. I need to
install lots of debuginfos and I prefer to do it in a virtual machine. I
will get back to you as soon as I have any hints.
Regards,
Constantin

Post by Constantin OrÄsan
Hello,
It seems that after I upgraded to F28 I can no longer start KPA. The

crash

Post by Constantin OrÄsan
happens while it imports about 1000 new images, but it does not seem to

them

Post by Constantin OrÄsan
I tried KPA 5.2.7 (the version that comes with F28), KPA5.3 and the

version

_Tp =

Post by Constantin OrÄsan
std::pair<unsigned int, unsigned int>; _Alloc =
std::allocator<std::pair<unsigned int, unsigned int> >;

std::vector<_Tp,

Post by Constantin OrÄsan
_Alloc>::const_reference = const std::pair<unsigned int, unsigned int>&;
std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion
'__builtin_expect(__n < this->size(), true)' failed.
Aborted (core dumped)
----
Any idea where to start debugging? KPA is complaining that I have

mplayer

Post by Constantin OrÄsan
installed, but I suppose it should not cause a crash.
Thank you,
Constantin

_______________________________________________
KPhotoAlbum mailing list
https://mail.kdab.com/mailman/listinfo/kphotoalbum

Robert Krawitz

2018-05-16 12:02:55 UTC

Permalink

Post by Constantin OrÄsan
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
../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
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"...,
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

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?

Post by Constantin OrÄsan
#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 <***@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

Constantin Orăsan

2018-05-16 14:54:24 UTC

Permalink

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=***@entry=0xa75200,
event=***@entry=0x1371510) at kernel/qwidget.cpp:9343
#7 0x00007ffff48dda68 in QMainWindow::event(QEvent*)
(this=***@entry=0xa75200,
event=***@entry=0x1371510) at widgets/qmainwindow.cpp:1342
#8 0x00007ffff661ee2b in KMainWindow::event(QEvent*)
(this=***@entry=0xa75200,
ev=***@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=***@entry=0x0, event_type=***@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=***@entry=0x7fffd0004ff0)
at gmain.c:3830
#19 0x00007fffebf67b98 in g_main_context_iterate
(context=***@entry=0x7fffd0004ff0,
block=***@entry=1, dispatch=***@entry=1, self=<optimized out>) at
gmain.c:3903
#20 0x00007fffebf67c30 in g_main_context_iteration (context=0x7fffd0004ff0,
may_block=***@entry=1) at gmain.c:3964

Does it help?

Thank you,

Constantin

Post by Constantin OrÄsan

(Fedora

Post by Constantin OrÄsan
seems to be a bit problematic about this), I managed to produce the
following backtrace.
(gdb) bt 20
../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
unsigned

Post by Constantin OrÄsan
int, unsigned int>, std::allocator<std::pair<unsigned int, unsigned

int> >

Post by Constantin OrÄsan

::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 =

Post by Constantin OrÄsan
std::pair<unsigned int, unsigned int>; _Alloc = std::allocator<std"...,
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

Post by Constantin OrÄsan
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?

Post by Constantin OrÄsan
#5 0x00000000005e7d59 in
Exif::RationalExifElement::valueFromExif(Exiv2::ExifData&) const ()
#6 0x00000000005ce1e0 in Exif::Database::insert(QList<

QPair<DB::FileName,

Post by Constantin OrÄsan
Exiv2::ExifData> >) ()
#7 0x00000000005cd161 in Exif::Database::add(DB::FileNameList const&)

()

Post by Constantin OrÄsan
#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() ()

--
*** 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

Tobias Leupold

2018-05-16 19:30:56 UTC

Permalink

Can you recompile with debugging enabled (Tobias, how do you do that)?

That's a good question ... probably, it's enabled by default here, and I
simply don't _dis_able it?! There's a BUILD_TESTING cmake switch, probably
this one?

Probably Johannes knows it - he's the senior dev ;-)

Constantin Orăsan

2018-05-18 09:57:55 UTC

Permalink

Hello,

An update on this: I run KPA5.3 on a machine with ubuntu and I imported all
the new photos. After that I synchronised all the files (including the
index.xml) on my fedora machine and KPA5.3 works without a problem. I will
start tagging photos to see whether there are any issues. Hopefully not. I
am still willing to help find the cause of the crash.

Regards,

Constantin

Post by Tobias Leupold

Can you recompile with debugging enabled (Tobias, how do you do that)?

That's a good question ... probably, it's enabled by default here, and I
simply don't _dis_able it?! There's a BUILD_TESTING cmake switch, probably
this one?

I followed the guidelines from https://www.kphotoalbum.
org/download/compiling/#compiling_kpa-itself and I added
-DCMAKE_BUILD_TYPE=RelWithDebInfo and some other versions I found on the
web, but none seem to give the debugging info I need.
I am really keen to get KPA working again on my computer. One solution is
to run it in a virtual machine which uses a different flavour of linux, but
I wonder whether I am the only F28 user of KPA.
Let me know if you have any ideas how I can help.
Cheers

Johannes Zarl-Zierl

2018-05-18 21:05:19 UTC

Permalink

Hello Constantin,

"RelWithDebInfo" should usually be sufficient to enable debug info. You could also try out
"Debug", but that results in a slower program with assertions enabled.

Can you check if the "-g" flag is used by your build? You can build with "make VERBOSE=1" to
see the build commands as they are run.

Cheers,
Johannes

Constantin Orăsan

2018-05-22 17:18:28 UTC

Permalink

Hello,

I did not get the chance to try this earlier. The first finding is that I
need to run

cmake -DCMAKE_BUILD_TYPE=Debug ..

to have the -g flag at the compilation time.

Below you can find two traces. In the first case I have a number of images
in the directory. In the second case, I have only one video, but I did not
install the support to generate thumbnails from videos. I see that the
traces are different. This is done using the latest version from github. I
hope it helps.

Thank you,

Constantin

Thread 1 "kphotoalbum" received signal SIGABRT, Aborted.
__GI_raise (sig=***@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 return ret;
(gdb) bt 20
#0 0x00007ffff2595f4b in __GI_raise (sig=***@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=***@entry=0x7ffff78644b0
"/usr/include/c++/8/bits/stl_vector.h", __line=***@entry=950,
__function=***@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,

::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
#5 0x00000000005ecceb in
Exif::RationalExifElement::valueFromExif(Exiv2::ExifData&) const
(this=0x1e9b510, data=...) at
/home/dinel/kphotoalbum/Exif/DatabaseElement.cpp:143
#6 0x00000000005d2fbe in Exif::Database::insert(QList<QPair<DB::FileName,
Exiv2::ExifData> >) (this=0x13f5120, map=...) at
/home/dinel/kphotoalbum/Exif/Database.cpp:341
#7 0x00000000005d1f3b in Exif::Database::add(DB::FileNameList const&)
(this=0x13f5120, list=...) at /home/dinel/kphotoalbum/Exif/Database.cpp:244
#8 0x00000000004a5012 in XMLDB::Database::forceUpdate(DB::ImageInfoList
const&) (this=0xd704f0, images=...) at
/home/dinel/kphotoalbum/XMLDB/Database.cpp:203
#9 0x00000000004a53aa in XMLDB::Database::addImages(DB::ImageInfoList
const&, bool) (this=0xd704f0, images=..., doUpdate=true) at
/home/dinel/kphotoalbum/XMLDB/Database.cpp:247
#10 0x0000000000581bc2 in DB::NewImageFinder::loadExtraFiles(bool)
(this=0x7fffffffbfa0, storeExif=false) at
/home/dinel/kphotoalbum/DB/NewImageFinder.cpp:178
#11 0x0000000000580dfb in DB::NewImageFinder::findImages()
(this=0x7fffffffbfa0) at /home/dinel/kphotoalbum/DB/NewImageFinder.cpp:64
#12 0x000000000057e931 in DB::ImageDB::slotRescan() (this=0xd704f0) at
/home/dinel/kphotoalbum/DB/ImageDB.cpp:90
#13 0x000000000053644f in MainWindow::Window::delayedInit() (this=0xa51810)
at /home/dinel/kphotoalbum/MainWindow/Window.cpp:252
#14 0x0000000000633bbe in MainWindow::Window::qt_static_metacall(QObject*,
QMetaObject::Call, int, void**) (_o=0xa51810,
_c=QMetaObject::InvokeMetaMethod, _id=52, _a=0x1235ac0)
at
/home/dinel/kphotoalbum/build/kphotoalbum_autogen/WCPGUQ57CZ/moc_Window.cpp:429
#15 0x00007ffff34f3a26 in QObject::event(QEvent*) (this=0xa51810,
e=<optimized out>) at kernel/qobject.cpp:1247
#16 0x00007ffff47c804b in QWidget::event(QEvent*) (this=***@entry=0xa51810,
event=***@entry=0xebff70) at kernel/qwidget.cpp:9343
#17 0x00007ffff48dda68 in QMainWindow::event(QEvent*)
(this=***@entry=0xa51810,
event=***@entry=0xebff70) at widgets/qmainwindow.cpp:1342
#18 0x00007ffff661ee2b in KMainWindow::event(QEvent*)
(this=***@entry=0xa51810,
ev=***@entry=0xebff70) at
/usr/src/debug/kf5-kxmlgui-5.44.0-1.fc28.x86_64/src/kmainwindow.cpp:865
#19 0x00007ffff66684f9 in KXmlGuiWindow::event(QEvent*) (this=0xa51810,
ev=0xebff70) at
/usr/src/debug/kf5-kxmlgui-5.44.0-1.fc28.x86_64/src/kxmlguiwindow.cpp:119
#20 0x00007ffff4787e95 in QApplicationPrivate::notify_helper(QObject*,
QEvent*) (this=<optimized out>, receiver=0xa51810, e=0xebff70) at
kernel/qapplication.cpp:3732

#0 0x00007ffff2595f4b in __GI_raise (sig=***@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff2580591 in __GI_abort () at abort.c:79
#2 0x00007ffff32e2ea3 in qt_message_fatal (context=..., message=<synthetic
pointer>...) at global/qlogging.cpp:1716
#3 0x00007ffff32e2ea3 in QMessageLogger::fatal(char const*, ...) const
(this=***@entry=0x7fffffffbe90, msg=***@entry=0x7ffff3578f80 "ASSERT:
\"%s\" in file %s, line %d") at global/qlogging.cpp:822
#4 0x00007ffff330479c in qt_assert(char const*, char const*, int)
(assertion=<optimized out>, file=<optimized out>, line=<optimized out>) at
global/qglobal.cpp:3126
#5 0x00000000005666d4 in ImageManager::ThumbnailBuilder::instance() () at
/home/dinel/kphotoalbum/ImageManager/ThumbnailBuilder.cpp:71
#6 0x0000000000580e94 in DB::NewImageFinder::findImages()
(this=0x7fffffffbfa0) at /home/dinel/kphotoalbum/DB/NewImageFinder.cpp:76
#7 0x000000000057e931 in DB::ImageDB::slotRescan() (this=0xd2f4e0) at
/home/dinel/kphotoalbum/DB/ImageDB.cpp:90
#8 0x000000000053644f in MainWindow::Window::delayedInit() (this=0xa7a800)
at /home/dinel/kphotoalbum/MainWindow/Window.cpp:252
#9 0x0000000000633bbe in MainWindow::Window::qt_static_metacall(QObject*,
QMetaObject::Call, int, void**) (_o=0xa7a800,
_c=QMetaObject::InvokeMetaMethod, _id=52, _a=0x13a2180)
at
/home/dinel/kphotoalbum/build/kphotoalbum_autogen/WCPGUQ57CZ/moc_Window.cpp:429
#10 0x00007ffff34f3a26 in QObject::event(QEvent*) (this=0xa7a800,
e=<optimized out>) at kernel/qobject.cpp:1247
#11 0x00007ffff47c804b in QWidget::event(QEvent*) (this=***@entry=0xa7a800,
event=***@entry=0x139c050) at kernel/qwidget.cpp:9343
#12 0x00007ffff48dda68 in QMainWindow::event(QEvent*)
(this=***@entry=0xa7a800,
event=***@entry=0x139c050) at widgets/qmainwindow.cpp:1342
#13 0x00007ffff661ee2b in KMainWindow::event(QEvent*)
(this=***@entry=0xa7a800,
ev=***@entry=0x139c050) at
/usr/src/debug/kf5-kxmlgui-5.44.0-1.fc28.x86_64/src/kmainwindow.cpp:865
#14 0x00007ffff66684f9 in KXmlGuiWindow::event(QEvent*) (this=0xa7a800,
ev=0x139c050) at
/usr/src/debug/kf5-kxmlgui-5.44.0-1.fc28.x86_64/src/kxmlguiwindow.cpp:119
#15 0x00007ffff4787e95 in QApplicationPrivate::notify_helper(QObject*,
QEvent*) (this=<optimized out>, receiver=0xa7a800, e=0x139c050) at
kernel/qapplication.cpp:3732
#16 0x00007ffff478f83a in QApplication::notify(QObject*, QEvent*)
(this=0x7fffffffd1b0, receiver=0xa7a800, e=0x139c050) at
kernel/qapplication.cpp:3491
#17 0x00007ffff34ca376 in QCoreApplication::notifyInternal2(QObject*,
QEvent*) (receiver=0xa7a800, event=0x139c050) at
kernel/qcoreapplication.cpp:1050
#18 0x00007ffff34cd09b in QCoreApplication::sendEvent(QObject*, QEvent*)
(event=0x139c050, receiver=0x0) at kernel/qcoreapplication.h:234
#19 0x00007ffff34cd09b in
QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*)
(receiver=0x0, event_type=0, data=0x93e510) at
kernel/qcoreapplication.cpp:1740
#20 0x00007ffff34cd4ec in QCoreApplication::sendPostedEvents(QObject*, int)
(receiver=***@entry=0x0, event_type=***@entry=0) at
kernel/qcoreapplication.cpp:1594

Hello Constantin,

I followed the guidelines from
https://www.kphotoalbum.org/download/compiling/#compiling_kpa-itself and
I added -DCMAKE_BUILD_TYPE=RelWithDebInfo and some other versions I

found

on the web, but none seem to give the debugging info I need.

"RelWithDebInfo" should usually be sufficient to enable debug info. You
could also try out "Debug", but that results in a slower program with
assertions enabled.
Can you check if the "-g" flag is used by your build? You can build with
"make VERBOSE=1" to see the build commands as they are run.
Cheers,
Johannes
_______________________________________________
KPhotoAlbum mailing list
https://mail.kdab.com/mailman/listinfo/kphotoalbum

Johannes Zarl-Zierl

2018-05-22 22:47:39 UTC

Permalink

Hi,

Post by Constantin OrÄsan
Below you can find two traces. In the first case I have a number of images
in the directory.

The crash is happening in libexiv2, apparently.

Post by Constantin OrÄsan
In the second case, I have only one video, but I did not
install the support to generate thumbnails from videos.

The second crash has triggered an assertion. Is there any output on the console?

Post by Constantin OrÄsan
I see that the
traces are different. This is done using the latest version from github. I
hope it helps.

I find github to be a little confusing as to which repository is the right one. Just to be sure,
you mean this one?
-> https://github.com/KDE/kphotoalbum
This one is the github mirror of the official repository.
The official repository itself can be found at https://phabricator.kde.org/source/
kphotoalbum/ or https://cgit.kde.org/kphotoalbum.git/.

Post by Constantin OrÄsan
Thread 1 "kphotoalbum" received signal SIGABRT, Aborted.
#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

This basically means that the ThumbnailBuilder was called before it was initialized.

Maybe it's worthwhile for you to check out Roberts branch "Load-performance". He did find
(and fix) some threading issues in the thumbnail builder.

Cheers,
Johannes

Robert Krawitz

2018-05-23 00:43:02 UTC

Permalink

It's definitely reading the EXIF data more than it should (three
times, to be precise). The code's messy, but I do want to fix
that...

Robert Krawitz

2018-05-23 02:55:42 UTC

Permalink

Post by Robert Krawitz
It's definitely reading the EXIF data more than it should (three
times, to be precise). The code's messy, but I do want to fix
that...

I got rid of two of the three EXIF reads during image load. Tested
that the EXIF data in fact is present, that the index.xml file
contains the correct angle and times, and that there's no problem with
images that don't contain EXIF data.

I didn't expect this to make much of a difference performance-wise,
but rather to my surprise it looks like it did, to the tune of 1-2% on
the SSD, and perhaps 3-5% when I uppped the scout threads.

I also capped the progress bar update to no more than every second. I
can load about 70 files/second (20MP JPEG) from the SSD, and maybe
15/sec from the HDD.