Version: 0.8.2 (using KDE KDE 3.5.3) Installed from: Gentoo Packages Compiler: gcc (GCC) 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9) OS: Linux Platform: amd64 Backtrace (even if I don't think its too usable): Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 47715249149136 (LWP 28292)] 0x00002b65925fccf5 in nanosleep () from /lib/libc.so.6 #0 0x00002b65925fccf5 in nanosleep () from /lib/libc.so.6 #1 0x00002b65925fcb60 in sleep () from /lib/libc.so.6 #2 0x00002b658f25dbfc in KCrash::startDrKonqi () from /usr/kde/3.5/lib64/libkdecore.so.4 #3 0x00002b658f27d153 in KCrash::defaultCrashHandler () from /usr/kde/3.5/lib64/libkdecore.so.4 #4 0x00002b659259d7f0 in killpg () from /lib/libc.so.6 #5 0x0000000000000000 in ?? () an "ltrace digikam" gives a lot of lines like the following just before it segfaults: _ZN14QPtrCollection7newItemEPv(0x00000000007e21c8, 0x00000000007e2d20, 0x00000000007e2d20, 33, 0) = 0x00000000007e2d20
To investiguate, we need a full backtrace using GDB. You need to recompile digiKam with all debug info and start it into debugger. Thanks in advance Gilles
Thank you for your fast response! Okay, I now compiled digiKam on my own. Configure was like this: CFLAGS=-ggdb ./configure --prefix=/usr/local --enable-debug --with-qt-dir=/usr/qt/3 --without-arts and here's the gdb backtrace you were asking for, including any information that was printed out while running: $ gdb /usr/local/bin/digikam GNU gdb 6.5 [...] (gdb) run Starting program: /usr/local/bin/digikam [Thread debugging using libthread_db enabled] [New Thread 47702496978128 (LWP 19843)] [New Thread 1082132832 (LWP 19847)] [Thread 1082132832 (LWP 19847) exited] [New Thread 1090525536 (LWP 19848)] [Thread 1090525536 (LWP 19848) exited] digikam: ScanLib: Finding non-existing Albums: 35 ms Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47702496978128 (LWP 19843)] Digikam::readJPEGMetaData (filePath=@0x7fff15cbd200, comments=@0x7fff15cbd210, datetime=@0x7fff15cbd1b8) at jpegmetadata.cpp:113 113 if (marker->marker == M_COM) (gdb) bt #0 Digikam::readJPEGMetaData (filePath=@0x7fff15cbd200, comments=@0x7fff15cbd210, datetime=@0x7fff15cbd1b8) at jpegmetadata.cpp:113 #1 0x00002b62950738ee in ScanLib::storeItemInDatabase (this=0x7ee9d0, albumURL=@0x7fff15cbd380, filename=@0x7fff15cbd300, albumID=4) at scanlib.cpp:380 #2 0x00002b6295074c29 in ScanLib::allFiles (this=0x7fff15cbdbc0, directory=@0x79f990) at scanlib.cpp:341 #3 0x00002b6295074cc4 in ScanLib::allFiles (this=0x7fff15cbdbc0, directory=@0x79bf70) at scanlib.cpp:346 #4 0x00002b6295074cc4 in ScanLib::allFiles (this=0x7fff15cbdbc0, directory=@0x799350) at scanlib.cpp:346 #5 0x00002b6295074cc4 in ScanLib::allFiles (this=0x7fff15cbdbc0, directory=@0x797290) at scanlib.cpp:346 #6 0x00002b629507501f in ScanLib::findMissingItems (this=0x7fff15cbdbc0) at scanlib.cpp:182 #7 0x00002b6295075145 in ScanLib::startScan (this=0x7fff15cbdbc0) at scanlib.cpp:81 #8 0x00002b62950258c5 in AlbumManager::setLibraryPath (this=0x725ba0, path=@0x797f10) at albummanager.cpp:278 #9 0x0000000000402d96 in main (argc=1, argv=0x7fff15cbdd30) at main.cpp:233
Thanks for your backtrace. However, we are currently receiving bug reports for 0.9.0-beta1 from last week, so we probably missed that your report is from 0.8.2. The relevant code indicated by your backtrace has been removed in 0.9.0 and we now use libexiv2 for metadata reading. So chances are good that the problem no longer exists in 0.9.0, or else we will fix it. However, there won't be another 0.8.x release, and the relevant code is gone since a long time, so we probably will not (at least not me) invest time to fix this problem. Try 0.9.0-beta1, there are really a lot of new features.