Discussion:
[KPhotoAlbum] Problems with libkgeomap - again
Matthias Heukäufer
2016-02-12 13:35:48 UTC
Permalink
Hi!

I have again a problem with building kphotoalbum 4.6.2 and 4.7. on
Debian jessie.
Thanks to Johannes, I was finally able to get it working with libkgeomap
on my laptop computer (64-bit).
I have now been trying to achieve the same on my old desktop, running
the same Debian version. The only obvious difference is this machine
beeing 32-bit.
I have tried all possible combinations: version 4.6.2 versus 4.7,
libkgeomap installed locally versus globally, but nothing helps.
Whenever I start kphotoalbum (both with my real database or the demo
database), the program crashes a few seconds after I open the thumbnail
viewer.
On the terminal I get the following error message:
ASSERT: "!fileName.isNull()" in file
/home/matthias/temp/kphotoalbum-4.7/ThumbnailView/ThumbnailModel.cpp,
line 179

When I build the program without kgeomap, it runs fine.
Does anybody have an idea how I could solve this?

Thank you - Matthias
Johannes Zarl-Zierl
2016-02-13 20:16:41 UTC
Permalink
Hi Matthias,
Post by Matthias Heukäufer
Whenever I start kphotoalbum (both with my real database or the demo
database), the program crashes a few seconds after I open the thumbnail
viewer.
ASSERT: "!fileName.isNull()" in file
/home/matthias/temp/kphotoalbum-4.7/ThumbnailView/ThumbnailModel.cpp,
line 179
I did a quick look into possible connections between this failed assert and
kgeomap, but I couldn't find anything obvious.
If you can provide a full stack trace (from the KDE crash handler), this would
be easier to debug.
Post by Matthias Heukäufer
When I build the program without kgeomap, it runs fine.
Does anybody have an idea how I could solve this?
The most valuable info is probably a stack trace. To get a good stack trace,
it's a good idea to set the CMAKE_BUILD_TYPE to Debug when you run cmake...

HTH,
Johannes


P.S.: I probably won't be able to get into this before next weekend, so please
be patient ;-)
Matthias Heukäufer
2016-02-14 09:40:43 UTC
Permalink
Hi Johannes,

thank you for your help. Here is the stack trace from a freshly compiled
KPhotoalbum 4.7:

Application: KPhotoAlbum (kphotoalbum), signal: Aborted
Using host libthread_db library
"/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1".
[Current thread is 1 (Thread 0xafc947c0 (LWP 9560))]

Thread 2 (Thread 0xac48eb40 (LWP 9565)):
#0 0xb77dcd40 in __kernel_vsyscall ()
#1 0xb138cc4b in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/i386-linux-gnu/i686/cmov/libpthread.so.0
#2 0xb4bad7fc in pthread_cond_wait () from
/lib/i386-linux-gnu/i686/cmov/libc.so.6
#3 0xb4f0fcbb in QWaitCondition::wait(QMutex*, unsigned long) () from
/usr/lib/i386-linux-gnu/libQtCore.so.4
#4 0x081224ac in ImageManager::AsyncLoader::next (this=0x9e39600) at
/home/matthias/temp/kphotoalbum-4.7/ImageManager/AsyncLoader.cpp:143
#5 0x08121e29 in ImageManager::ImageLoaderThread::run (this=0x9e3b030)
at /home/matthias/temp/kphotoalbum-4.7/ImageManager/ImageLoaderThread.cpp:56
#6 0xb4f0f70e in ?? () from /usr/lib/i386-linux-gnu/libQtCore.so.4
#7 0xb1388efb in start_thread () from
/lib/i386-linux-gnu/i686/cmov/libpthread.so.0
#8 0xb4ba0c6e in clone () from /lib/i386-linux-gnu/i686/cmov/libc.so.6

Thread 1 (Thread 0xafc947c0 (LWP 9560)):
[KCrash Handler]
#7 0xb77dcd40 in __kernel_vsyscall ()
#8 0xb4ae3347 in raise () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
#9 0xb4ae4a03 in abort () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
#10 0xb4f04224 in qt_message_output(QtMsgType, char const*) () from
/usr/lib/i386-linux-gnu/libQtCore.so.4
#11 0xb4f045e6 in ?? () from /usr/lib/i386-linux-gnu/libQtCore.so.4
#12 0xb4f04b69 in qFatal(char const*, ...) () from
/usr/lib/i386-linux-gnu/libQtCore.so.4
#13 0xb4f04bc7 in qt_assert(char const*, char const*, int) () from
/usr/lib/i386-linux-gnu/libQtCore.so.4
#14 0x080cb507 in ThumbnailView::ThumbnailModel::indexOf
(this=0x9d9bcb0, fileName=...) at
/home/matthias/temp/kphotoalbum-4.7/ThumbnailView/ThumbnailModel.cpp:179
#15 0x080cb702 in ThumbnailView::ThumbnailModel::updateCell
(this=0x9d9bcb0, fileName=...) at
/home/matthias/temp/kphotoalbum-4.7/ThumbnailView/ThumbnailModel.cpp:400
#16 0x080ca194 in
ThumbnailView::MouseTrackingInteraction::handleCursorOverNewIcon
(this=0x9da0b18) at
/home/matthias/temp/kphotoalbum-4.7/ThumbnailView/MouseTrackingInteraction.cpp:62
#17 0x080ca244 in
ThumbnailView::MouseTrackingInteraction::mouseMoveEvent (this=0x9da0b18,
event=0xbfea5904) at
/home/matthias/temp/kphotoalbum-4.7/ThumbnailView/MouseTrackingInteraction.cpp:34
#18 0x080c7d8d in ThumbnailView::ThumbnailWidget::mouseMoveEvent
(this=0x9da0ab8, event=0xbfea5904) at
/home/matthias/temp/kphotoalbum-4.7/ThumbnailView/ThumbnailWidget.cpp:169
#19 0xb576bbe9 in QWidget::event(QEvent*) () from
/usr/lib/i386-linux-gnu/libQtGui.so.4
#20 0xb5b7637a in QFrame::event(QEvent*) () from
/usr/lib/i386-linux-gnu/libQtGui.so.4
#21 0xb5c07b7d in QAbstractScrollArea::viewportEvent(QEvent*) () from
/usr/lib/i386-linux-gnu/libQtGui.so.4
#22 0xb5cad117 in QAbstractItemView::viewportEvent(QEvent*) () from
/usr/lib/i386-linux-gnu/libQtGui.so.4
#23 0xb5c07e03 in ?? () from /usr/lib/i386-linux-gnu/libQtGui.so.4
#24 0xb50295a3 in
QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*,
QEvent*) () from /usr/lib/i386-linux-gnu/libQtCore.so.4
#25 0xb57104e8 in QApplicationPrivate::notify_helper(QObject*, QEvent*)
() from /usr/lib/i386-linux-gnu/libQtGui.so.4
#26 0xb57191b6 in QApplication::notify(QObject*, QEvent*) () from
/usr/lib/i386-linux-gnu/libQtGui.so.4
#27 0xb62d7cdc in KApplication::notify(QObject*, QEvent*) () from
/usr/lib/libkdeui.so.5
#28 0xb502942a in QCoreApplication::notifyInternal(QObject*, QEvent*) ()
from /usr/lib/i386-linux-gnu/libQtCore.so.4
#29 0xb5716b4c in QApplicationPrivate::sendMouseEvent(QWidget*,
QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool)
() from /usr/lib/i386-linux-gnu/libQtGui.so.4
#30 0xb579a3d9 in ?? () from /usr/lib/i386-linux-gnu/libQtGui.so.4
#31 0xb57990f5 in QApplication::x11ProcessEvent(_XEvent*) () from
/usr/lib/i386-linux-gnu/libQtGui.so.4
#32 0xb57c4441 in ?? () from /usr/lib/i386-linux-gnu/libQtGui.so.4
#33 0xb109fda4 in g_main_context_dispatch () from
/lib/i386-linux-gnu/libglib-2.0.so.0
#34 0xb10a00c9 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#35 0xb10a0196 in g_main_context_iteration () from
/lib/i386-linux-gnu/libglib-2.0.so.0
#36 0xb505b839 in
QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
() from /usr/lib/i386-linux-gnu/libQtCore.so.4
#37 0xb57c4516 in ?? () from /usr/lib/i386-linux-gnu/libQtGui.so.4
#38 0xb5027d9f in
QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from
/usr/lib/i386-linux-gnu/libQtCore.so.4
#39 0xb502812e in
QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from
/usr/lib/i386-linux-gnu/libQtCore.so.4
#40 0xb502e2b6 in QCoreApplication::exec() () from
/usr/lib/i386-linux-gnu/libQtCore.so.4
#41 0xb570e614 in QApplication::exec() () from
/usr/lib/i386-linux-gnu/libQtGui.so.4
#42 0x08080393 in main (argc=1, argv=0xbfea6034) at
/home/matthias/temp/kphotoalbum-4.7/main.cpp:89

libkgeomap is from git
(http://quickgit.kde.org/?p=libkgeomap.git&a=snapshot&h=c864ef7131ecb69a0c0859b0c6cbb371fbc65841).

It would be great if you found the time to look into this, but since it
seems to be a problem that affects only me, you shuld not spend too much
time on it. After all, I can use KPHotoalbum. It is sometimes just very
convienent to see where a picture was taken while annotating it.

Thank you - Matthias
Post by Johannes Zarl-Zierl
Hi Matthias,
Post by Matthias Heukäufer
Whenever I start kphotoalbum (both with my real database or the demo
database), the program crashes a few seconds after I open the thumbnail
viewer.
ASSERT: "!fileName.isNull()" in file
/home/matthias/temp/kphotoalbum-4.7/ThumbnailView/ThumbnailModel.cpp,
line 179
I did a quick look into possible connections between this failed assert and
kgeomap, but I couldn't find anything obvious.
If you can provide a full stack trace (from the KDE crash handler), this would
be easier to debug.
Post by Matthias Heukäufer
When I build the program without kgeomap, it runs fine.
Does anybody have an idea how I could solve this?
The most valuable info is probably a stack trace. To get a good stack trace,
it's a good idea to set the CMAKE_BUILD_TYPE to Debug when you run cmake...
HTH,
Johannes
P.S.: I probably won't be able to get into this before next weekend, so please
be patient ;-)
_______________________________________________
KPhotoAlbum mailing list
https://mail.kdab.com/mailman/listinfo/kphotoalbum
Matthias Heukäufer
2016-02-14 13:08:47 UTC
Permalink
It is more than a bit embarrassing, but it seems that my problem has
disappeared. I was absolutely sure that I had tried every possible
combination of different KPhotoalbum/ KGeomap-versions and installation
paths, but it seems that I have missed something.
Anyway, I compiled 4.6.2 again from a freshly downloaded source and now
it works (well, sort of: I have to reload EXIF-information a couple of
times for every picture to have it shown at the correct location, but at
least KPhotoalbum runs stable again).
Maybe 'make clean' had not taken care of all relevant files.
Since I have already wasted so much of everybody's time, I will stick
with what I have for now and wait for kgeomap to become available as a
regular Debian package.

Thank you and please apologize the confusion - Matthias
Post by Johannes Zarl-Zierl
Hi Matthias,
Post by Matthias Heukäufer
Whenever I start kphotoalbum (both with my real database or the demo
database), the program crashes a few seconds after I open the thumbnail
viewer.
ASSERT: "!fileName.isNull()" in file
/home/matthias/temp/kphotoalbum-4.7/ThumbnailView/ThumbnailModel.cpp,
line 179
I did a quick look into possible connections between this failed assert and
kgeomap, but I couldn't find anything obvious.
If you can provide a full stack trace (from the KDE crash handler), this would
be easier to debug.
Post by Matthias Heukäufer
When I build the program without kgeomap, it runs fine.
Does anybody have an idea how I could solve this?
The most valuable info is probably a stack trace. To get a good stack trace,
it's a good idea to set the CMAKE_BUILD_TYPE to Debug when you run cmake...
HTH,
Johannes
P.S.: I probably won't be able to get into this before next weekend, so please
be patient ;-)
_______________________________________________
KPhotoAlbum mailing list
https://mail.kdab.com/mailman/listinfo/kphotoalbum
Johannes Zarl-Zierl
2016-02-20 22:16:55 UTC
Permalink
Hello Matthias,

Glad to hear that the problem disappeared for you!

Thanks for the stack trace - it allowed me to find a possible root cause of
the crash. This should be fixed in commit 8dbfadf.

Cheers,
Johannes
Post by Matthias Heukäufer
It is more than a bit embarrassing, but it seems that my problem has
disappeared. I was absolutely sure that I had tried every possible
combination of different KPhotoalbum/ KGeomap-versions and installation
paths, but it seems that I have missed something.
Anyway, I compiled 4.6.2 again from a freshly downloaded source and now
it works (well, sort of: I have to reload EXIF-information a couple of
times for every picture to have it shown at the correct location, but at
least KPhotoalbum runs stable again).
Maybe 'make clean' had not taken care of all relevant files.
Since I have already wasted so much of everybody's time, I will stick
with what I have for now and wait for kgeomap to become available as a
regular Debian package.
Thank you and please apologize the confusion - Matthias
Post by Johannes Zarl-Zierl
Hi Matthias,
Post by Matthias Heukäufer
Whenever I start kphotoalbum (both with my real database or the demo
database), the program crashes a few seconds after I open the thumbnail
viewer.
ASSERT: "!fileName.isNull()" in file
/home/matthias/temp/kphotoalbum-4.7/ThumbnailView/ThumbnailModel.cpp,
line 179
I did a quick look into possible connections between this failed assert and
kgeomap, but I couldn't find anything obvious.
If you can provide a full stack trace (from the KDE crash handler), this
would be easier to debug.
Post by Matthias Heukäufer
When I build the program without kgeomap, it runs fine.
Does anybody have an idea how I could solve this?
The most valuable info is probably a stack trace. To get a good stack
trace, it's a good idea to set the CMAKE_BUILD_TYPE to Debug when you run
cmake...
HTH,
Johannes
P.S.: I probably won't be able to get into this before next weekend, so
please be patient ;-)
_______________________________________________
KPhotoAlbum mailing list
https://mail.kdab.com/mailman/listinfo/kphotoalbum
Loading...