Bug 131416 - digikam segfaults on start
Summary: digikam segfaults on start
Status: RESOLVED INTENTIONAL
Alias: None
Product: digikam
Classification: Applications
Component: Portability-Runtime (show other bugs)
Version: 0.8.2
Platform: Gentoo Packages Linux
: NOR crash
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-07-26 22:44 UTC by David Vogt
Modified: 2022-01-23 05:12 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 7.6.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Vogt 2006-07-26 22:44:39 UTC
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
Comment 1 caulier.gilles 2006-07-27 08:17:40 UTC
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
Comment 2 David Vogt 2006-07-28 18:24:20 UTC
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
Comment 3 Marcel Wiesweg 2006-07-28 21:39:27 UTC
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.