Version: 0.9.0-Beta1 (using KDE KDE 3.5.4) Installed from: Gentoo Packages OS: Linux I know this is an old beta, but maybe the bug has not been discovered yet. How to reproduce: Enter a sub-album that has no thumbnails in the database yet. Immediately press and hold SHIFT and 'Arrow Down' to select images. DigiKam will become sluggish and often crash eventually. There is the backtrace: Using host libthread_db library "/lib/libthread_db.so.1". `system-supplied DSO at 0xffffe000' has disappeared; keeping its symbols. [Thread debugging using libthread_db enabled] [New Thread -1234196288 (LWP 9203)] [KCrash handler] #6 0xffffe410 in __kernel_vsyscall () #7 0xb675a600 in raise () from /lib/libc.so.6 #8 0xb675bc60 in abort () from /lib/libc.so.6 #9 0x50093e3b in __gnu_cxx::__verbose_terminate_handler () from /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libstdc++.so.6 #10 0x50091a75 in __cxa_call_unexpected () from /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libstdc++.so.6 #11 0x50091ab2 in std::terminate () from /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libstdc++.so.6 #12 0x50091c22 in __cxa_throw () from /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libstdc++.so.6 #13 0x50091e7f in operator new () from /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libstdc++.so.6 #14 0xb7cbff03 in std::vector<Exiv2::Entry, std::allocator<Exiv2::Entry> >::operator= () from /usr/lib/libexiv2-0.10.so #15 0xb7cbd235 in Exiv2::CanonMakerNote::CanonMakerNote () from /usr/lib/libexiv2-0.10.so #16 0xb7cbd308 in Exiv2::CanonMakerNote::clone_ () from /usr/lib/libexiv2-0.10.so #17 0xb7ceea74 in Exiv2::MakerNote::clone () from /usr/lib/libexiv2-0.10.so #18 0xb7cd1c2a in Exiv2::ExifData::operator= () from /usr/lib/libexiv2-0.10.so #19 0x42a72fb9 in Digikam::DMetaLoader::loadWithExiv2 (this=0xbfd04bb0, filePath=@0x23f3) at memory:285 #20 0x42a6c624 in Digikam::JPEGMetaLoader::load (this=0x0, filePath=@0x0) at jpegmetaloader.cpp:35 #21 0x42a2f325 in Digikam::DMetadata::load (this=0xbfd04bb0, filePath=@0xbfd04ea0, ff=Digikam::DImg::NONE) at dmetadata.cpp:235 #22 0x42a3b5de in DMetadata (this=0xbfd04e90, filePath=@0x0, ff=Digikam::DImg::NONE) at dmetadata.cpp:70 #23 0x429da0a8 in Digikam::ImagePropertiesTab::setCurrentURL (this=0x8194ab0, url=@0x8192934, itemType=0) at kurl.h:532 #24 0x429c2165 in Digikam::ImagePropertiesSideBarDB::slotChangedTab ( this=0x8192880, tab=0x8194ab0) at imagepropertiessidebardb.cpp:263 #25 0x429c0e9d in Digikam::ImagePropertiesSideBarDB::itemChanged ( this=0x8192880, url=@0x0, rect=0x0, img=0x0, view=0x0, item=0x0, info=0x0, hasPrevious=true, hasNext=true) at imagepropertiessidebardb.cpp:206 #26 0x429c100f in Digikam::ImagePropertiesSideBarDB::itemChanged (this=0x0, url=@0x0, view=0x8171788, item=0x850bb88, rect=0x0, img=0x0) at imagepropertiessidebardb.cpp:165 #27 0x428a06c3 in Digikam::DigikamView::slotImageSelected (this=0x816bc48) at digikamview.cpp:586 #28 0x428a1276 in Digikam::DigikamView::qt_invoke (this=0x816bc48, _id=89, _o=0xbfd051c4) at digikamview.moc:318 #29 0xb6e66810 in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3 #30 0xb6e66f85 in QObject::activate_signal_bool () from /usr/qt/3/lib/libqt-mt.so.3 #31 0x4286bcfe in Digikam::AlbumManager::signalAlbumItemsSelected (this=0x0, t0=64) at qmetaobject.h:261 #32 0x4286bd35 in Digikam::AlbumManager::emitAlbumItemsSelected (this=0x0, val=true) at albummanager.cpp:1248 #33 0x42879a91 in Digikam::AlbumItemHandler::emitItemsSelected ( this=0x8171824, val=true) at albumitemhandler.cpp:39 #34 0x428a9f8c in Digikam::AlbumIconView::slotSelectionChanged ( this=0x8171788) at albumiconview.cpp:1332 #35 0x428b456a in Digikam::AlbumIconView::qt_invoke (this=0x8171788, _id=72, _o=0x826a048) at albumiconview.moc:249 #36 0xb6e668a9 in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3 #37 0xb6e674fd in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3 #38 0x4288a9a9 in Digikam::IconView::signalSelectionChanged (this=0x0) at qmetaobject.h:261 #39 0x4288b97e in Digikam::IconView::selectItem (this=0xbfd05318, item=0x6, select=false) at iconview.cpp:378 #40 0x42890644 in Digikam::IconItem::setSelected (this=0x850bb88, val=true, cb=160) at iconitem.cpp:118 #41 0x4288d388 in Digikam::IconView::keyPressEvent (this=0x8171788, e=0xbfd058d0) at iconview.cpp:1539 #42 0xb6e9eb30 in QWidget::event () from /usr/qt/3/lib/libqt-mt.so.3 #43 0xb6e07f17 in QApplication::internalNotify () from /usr/qt/3/lib/libqt-mt.so.3 #44 0xb6e09206 in QApplication::notify () from /usr/qt/3/lib/libqt-mt.so.3 #45 0xb74cfb86 in KApplication::notify (this=0xbfd05ce0, receiver=0x8171788, event=0xbfd058d0) at kapplication.cpp:550 #46 0xb6da6d58 in QETWidget::translateKeyEvent () from /usr/qt/3/lib/libqt-mt.so.3 #47 0xb6da88f9 in QApplication::x11ProcessEvent () from /usr/qt/3/lib/libqt-mt.so.3 #48 0xb6db883a in QEventLoop::processEvents () from /usr/qt/3/lib/libqt-mt.so.3 #49 0xb6e1e5b0 in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3 #50 0xb6e1e446 in QEventLoop::exec () from /usr/qt/3/lib/libqt-mt.so.3 #51 0xb6e079af in QApplication::exec () from /usr/qt/3/lib/libqt-mt.so.3 #52 0x0804a69c in main (argc=0, argv=0x0) at main.cpp:273
Problem already reported here. Dik, please give us witch Exiv2 and Libc version you use on your system and if you have used some compilation optimizations. Thanks in advance Andreas, this is another Exiv2/libc backtrace for you... Gilles
Dik, Forget to ask you a "valgrind" backtrace when you reproduce the crash. Look at end of the digiKam HACKING file from svn for details. Gilles
exiv2 version 0.10-r1 glibc version 2.4-r3 GCC 4.1.1, using flags: -O2 -g3 -march=athlon -pipe -mmmx -m3dnow -fvisibility-inlines-hidden Pffew.. Valgrind.. I will have a look at that beast if I find some time.
Dik, Others test : - Try to use last Exiv2 stable release 0.11 - Try to disable mmx optimization witch are non sence for me with Athlon processor Gilles
This one comes out of operator new(), which means that memory allocation didn't succeed. A system which is low on memory tends to become "sluggish" as described, so that's consistent. But why does that happen? How many images are in the album and what kind of processing is done? -ahu.
The memory usage is normal when I produce the crash. Only CPU usage is high. The crash is also reproducible using digikam 0.9.0-beta2. I will now try upgrading exiv2.
I have upgraded to exiv2 0.11, but DigiKam is now broken. I tried to re-merge digikam, libkipi and both plugin packages, but I keep getting: digikam: error while loading shared libraries: libexiv2-0.10.so: cannot open shared object file: No such file or directory Even when I completely remove digikam/exiv2/kipi/kipiplugins/imageplugins and re-merge from scratch, DigiKam still wants the old exiv2 library. I double-checked that version 0.10 is not on my system anymore. What to do?
This sounds as if you have old binaries lying around in other places. I would suggest to use "which" to verify which digikam binary you are using, "ldd" to check which libdigikam.so the binary is loading, "ldd" to check which version of libexiv2 libdigikam is linked to, always checking if this one is the newly installed.
Exiv2 0.10 and 0.11 are not binary compatible. 1/ unisntall Exiv2 0.10 from your system. 2/ install Exiv2 0.11 instead 3/ Clean up digikam & co (i recommend you to checkout all source code from scratch) 4/ compile and install digikam & co Gilles
It turned out that the install location had changed between beta1 and beta2, and the ebuild did not remove beta1 at all. I manually removed beta1 and now it runs perfectly. Also, all of my attempts to reproduce the crash have failed. :)
Ok, Dik Let's open this file until you will be sure than it's unreproductible. When you is sure, please close it. Gilles
Dik, Are you updated something on your computer (outside Exiv2 and digikam & co), like libc or other common shared library ? Gilles
No, no nothing related to KDE or any system packages. The old 0.9.0-beta1 libraries that were still wandering about on my system were still linked to GCC 3.4 runtime libraries, while the rest of the system was GCC 4.0. Other than removing these old 0.9.0-beta1 libraries, nothing special happened. I also noted that selecting many images feels MUCH faster now.
>I also noted that selecting many images feels MUCH faster now. This is certainly relevant of Exiv2 0.11 witch use nmap feature now to speed up pictures file acess. Gilles
Dik, We suspect this is a duplicate of bug #136855 and need your feedback to confirm if the problem is solved. If you can still recreate this please try again with the latest Exiv2/digiKam/kipi-plugins from SVN. You need to compile and install Exiv2 first and cleanup digiKam/kipi-plugins before recompiling and installing it. Please report if the problem still occurs. Thanks! -ahu.
I still cannot reproduce the problem. My current version is Exiv2 0.11 and DigiKam/DigiKamImagePlugins 0.9.0-Beta3, latest kipi-plugins release.
Thanks for the report Dik. I close this file now. Gilles