| Summary: | digikam segfaults on start | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | David Vogt <kde> |
| Component: | Portability-Runtime | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | crash | CC: | caulier.gilles |
| Priority: | NOR | ||
| Version: | 0.8.2 | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 7.6.0 | |
| Sentry Crash Report: | |||
|
Description
David Vogt
2006-07-26 22:44:39 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 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. |