Discussion:
[KPhotoAlbum] Bad News: KPA dies on save
Andreas Schleth
2017-01-28 17:11:26 UTC
Permalink
Hi everybody,

with the latest two revisions I have the problem that KPA immediately
dies without a trace (no oops-message, whatsoever), if I hit "save" or
if the program tries to do it's autosave. The index file remains untouched.

Tested with the latest git master.

Additional test: as all my DBs reside on nfs storage, I copied one
smaller DB to local storage. There, we have the same problem. Called
from the command line the program spits out some additional info:

----

***@wshome5:~/Lokal/tmp/test> kphotoalbum -c index.xml
libkgeomap: "setting backend marble"
libkgeomap: "backend marble is ready!"
libkgeomap: "marble:900"
libkgeomap: located data:
QUrl("file:///usr/share/libkgeomap/marker-00ff00.png")
libkgeomap: located data:
QUrl("file:///usr/share/libkgeomap/marker-00ff00-selected.png")
libkgeomap: located data:
QUrl("file:///usr/share/libkgeomap/marker-00ff00-someselected.png")
libkgeomap: located data:
QUrl("file:///usr/share/libkgeomap/marker-00ffff.png")
libkgeomap: located data:
QUrl("file:///usr/share/libkgeomap/marker-00ffff-selected.png")
libkgeomap: located data:
QUrl("file:///usr/share/libkgeomap/marker-00ffff-someselected.png")
libkgeomap: located data:
QUrl("file:///usr/share/libkgeomap/marker-ff0000.png")
libkgeomap: located data:
QUrl("file:///usr/share/libkgeomap/marker-ff0000-selected.png")
libkgeomap: located data:
QUrl("file:///usr/share/libkgeomap/marker-ff0000-someselected.png")
libkgeomap: located data:
QUrl("file:///usr/share/libkgeomap/marker-ff7f00.png")
libkgeomap: located data:
QUrl("file:///usr/share/libkgeomap/marker-ff7f00-selected.png")
libkgeomap: located data:
QUrl("file:///usr/share/libkgeomap/marker-ff7f00-someselected.png")
libkgeomap: located data:
QUrl("file:///usr/share/libkgeomap/marker-ffff00.png")
libkgeomap: located data:
QUrl("file:///usr/share/libkgeomap/marker-ffff00-selected.png")
libkgeomap: located data:
QUrl("file:///usr/share/libkgeomap/marker-ffff00-someselected.png")
libkgeomap: located data:
QUrl("file:///usr/share/libkgeomap/marker-icon-16x16.png")
libkgeomap: "backend marble is ready!"
libkgeomap: "marble:900"
libkgeomap: "ROADMAP"
libkgeomap: 900 3500 900
libkgeomap: 900 3500 900
libkgeomap: 900 3500 900
libkgeomap: 900 3500 900
libkgeomap: 900 3500 900
libkgeomap: 900 3500 900
libkgeomap: 900 3500 900
libkgeomap: 900 3500 900
libkgeomap: 900 3500 900
libkgeomap: 900 3500 900
libkgeomap: "marble:900"
libkgeomap: ----
QImage::scaled: Image is a null image
QImage::scaled: Image is a null image
libkgeomap: 900 3500 900
libkgeomap: 3400 3500 900
QXcbConnection: XCB error: 3 (BadWindow), sequence: 6107, resource id:
50332017, major code: 40 (TranslateCoords), minor code: 0
Speicherzugriffsfehler (Speicherabzug geschrieben)
***@wshome5:~/Lokal/tmp/test>

----

OK, another test: KPA compiled without KF5KGeoMap.

This just prints one line (the last above) while dying. So, KF5JGeoMap
is not responsible.

Andreas
Johannes Zarl-Zierl
2017-01-28 18:30:00 UTC
Permalink
Hi Andreas,

Unfortunately I can't do any debugging currently because the linker in Debian
unstable is currently broken :(
Post by Andreas Schleth
with the latest two revisions I have the problem that KPA immediately
dies without a trace (no oops-message, whatsoever), if I hit "save" or
if the program tries to do it's autosave. The index file remains untouched.
Can you create a backtrace?
Since your desktop apparently does not automatically create one after the
crash, you can use the following commands on the command line:

gdb --args kphotoalbum
(gdb) run
... crash occurs ...
(gdb) bt
Post by Andreas Schleth
This just prints one line (the last above) while dying. So, KF5JGeoMap
is not responsible.
Since you mentioned that this only occurs since commit 53aa2d91 or so, there's
basically just one thing I could have done wrong. I've added an additional
check into latest master.

Does it still crash in the latest commit?

Cheers,
Johannes
Tobias Leupold
2017-01-28 18:35:13 UTC
Permalink
Post by Johannes Zarl-Zierl
Does it still crash in the latest commit?
At least here, there's no crash with current git master, whereas I also see
the segfault with 53aa2d91. Apparently, you fixed it ;-)
Johannes Zarl-Zierl
2017-01-28 18:39:38 UTC
Permalink
Post by Tobias Leupold
Post by Johannes Zarl-Zierl
Does it still crash in the latest commit?
At least here, there's no crash with current git master, whereas I also see
the segfault with 53aa2d91. Apparently, you fixed it ;-)
Thanks for trying it out, Tobias!

I can't wait to have a working linker/binutils again...

Cheers,
Johannes
Johannes Zarl-Zierl
2017-01-28 19:44:28 UTC
Permalink
Hi Andreas,
the latest commit (v5.1-27-g995ce0a-dirty) does not crash anymore.
Thanks for checking...
With the previous version I got the gdb backtrace.
Would it be greatly useful for testing to have all these debuginfo
packages installed or is the output below good enough to pinpoint the
problem?
In this case, the debuginfo is not needed (but compiling kphotoalbum itself
with CMAKE_BUILD_TYPE of either "Debug" or "RelWithDebInfo") would help in
identifying the exact line of the crash.
----
(gdb) bt
#0 0x00000000004b3bdb in XMLDB::XMLCategory::initIdMap() ()
#1 0x00000000004b2ae0 in XMLDB::XMLCategoryCollection::initIdMap() ()
#2 0x00000000004be84a in XMLDB::FileWriter::save(QString const&, bool) ()
#3 0x00000000004a8607 in XMLDB::Database::save(QString const&, bool) ()
#4 0x00000000005329f9 in MainWindow::Window::slotSave() ()
That confirms that the issue was where I fixed it... ;-)

Cheers,
Johannes

Loading...