| Summary: | Digikam Crash when browsing photos in Image Editor | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | sero4linux |
| Component: | Metadata-Engine | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | ahuggel, caulier.gilles |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 7.3.0 | |
| Sentry Crash Report: | |||
This sounds like a recent Paco like problem. If you use Exiv from svn, and if you have installed last stable release 0.9.1, you need to clean up you system because there is a version conflict. Uninstall properlly Exiv2-0.9.1 and Exiv2-svn (there is 2 differents lib .so files now) and re-install Exiv2-svn. Gilles Strange. I never used exiv2 from SVN. I have only used 0.9.1 (installed with a Gentoo ebuild) since it is a dep in digikam SVN and never changed it. But I have the crashes ~ the last two weeks. Are you sure this is not a problem with digikam itself? Can I provide further information? well, try to uninstall all, and use a fresh checkout of svn. Compile and re-install it. There are a lot of changes in digikam core and binary compatibility is broken. Gilles OK. Did I understand you right that SVN is now binary-INcompatible with exiv2-0.9.1 and DEPENDS on exiv2-0.10.0_SVN? I guess if this is right we will get a version check on compile time once the exiv2-0.10 release is out? Thanks for your help. Sero no, digiKam do not depand of Exiv2 0.10.0 especially. The code must still compatible with oldiers version. I just use Exiv2 0.10.0 because the library have been very improved. Gilles I have finally recompiled exiv2-0.9.1 with more conservative compiler FLAGS and now the problem seems to be gone.
OLD COMPILER FLAGS
******************
CFLAGS="-O3 -march=pentium-m -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"
FLAGS THAT WORK
***************
CFLAGS="-O2 -march=pentium-m"
CHOST="i686-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"
I will contact the Gentoo ebuild author to make sure that the ebuild always uses sane compiler FLAGS.
I guess this bug report is INVALID and it can be closed. Thanks for your patience.
Ok toggle it to invalid. I have contacted the Exiv2 author to have more viewpoints about this subject. The discussion still open Gilles Changing the compiler settings sounds like a workaround to me. There is a bug on the run and we should continue to hunt it... Any chance that you can post a valgrind trace for this crash? Andreas Sebastian, Please use this command line with valgrind : valgrind --tool=memcheck --leak-check=full --error-limit=no digikam Thanks in advance Gilles OK I will do the valgrind thing and report back in an hour or so. If you want to, I can open this bug on the exiv2 bugtracking system if this is easier for you to track down. I have some more off-topic questions though. 1. If anybody of you knows some good knowledge source / HowTos etc. about debugging using gdb/valgrind please let me know. 2. Currently I have to recompile digikam after I changed something on exiv2 cause the gentoo exiv2 ebuild installs to /usr and my manual exiv2 compile installs into /usr/local. Is there a way to avoid the digikam rebuild, just "telling" digikam where exiv2 is located now? (from now on I will install the manual exiv2 install to /usr too in any case). Regards, Sebastian I am sorry but I can not reproduce the crash here with the (always used) gentoo ebuild of exiv2-0.9.1 and todays (2006-06-01) digikam SVN checkout. It seems like the crash was NOT fixed by the changed compiler flags but by a change in digikam code. This would mean that the problem was not caused by exiv2 but by digikam - or maybe something was wrong with my system? Does the valgrind test help even if there is NO crash? In reply to #9: Gilles, the valgrind comment you provide doesn't work - I only get the message "killed" in the console. are you intalled digikam on your system before to use valgrind ? Witch version you use ? At least command line options require 3.0.x Gilles #10 - I find the valgrind doc quite good and you don't need to know much about it to get useful output. #11 - Yes, it may. E.g., if there is a buffer overflow, the program may or may not crash but valgrind will report access to unallocated memory in any case. #12 - For a start you can simpy try a "valgrind digikam" Thanks, Andreas Thanks Gilles and Andreas for your comments. Befor I can continue I have to get a working valgrind. Whatever I do with valgrind, e.g. "valgrind --help" or "valgrind digikam", I get the "killed" message immediately. A quick google search showed that others had the same problem but I didn't found a solution yet. Not reproducible with digiKam 7.3.0 and Exiv2 0.27.4 |
Version: 0.9 SVN (using KDE KDE 3.5.2) Installed from: Gentoo Packages Compiler: i686-pc-linux-gnu-3.4.5 OS: Linux Not much more to say about it. I click on the first picture of an album and when I browse the album in IE view with "page up"/"page down" keys it crashs. Here is the backtrace (recent SVN build of digikam trunk): (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xa6168261 in raise () from /lib/tls/libc.so.6 #2 0xa61699f9 in abort () from /lib/tls/libc.so.6 #3 0xa619c09a in __fsetlocking () from /lib/tls/libc.so.6 #4 0xa61a1fb7 in malloc_usable_size () from /lib/tls/libc.so.6 #5 0xa61a29cb in free () from /lib/tls/libc.so.6 #6 0xa632bb01 in operator delete () from /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/libstdc++.so.6 #7 0xa632bb5d in operator delete[] () from /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/libstdc++.so.6 #8 0xa79e0cfa in Exiv2::ExifData::~ExifData () from /usr/lib/libexiv2-0.9.1.so #9 0xa7ef3cbd in Digikam::DMetadata::getExif (this=0xa5806c50) at dmetadata.cpp:99 #10 0xa7ee56b8 in Digikam::DImgLoader::readMetadata (this=0x0, filePath=@0x0, ff=Digikam::DImg::NONE) at dimgloader.cpp:133 #11 0xa7f01336 in Digikam::JPEGLoader::load (this=0xa5807240, filePath=@0x85c6aa4, observer=0x85c6aa0) at jpegloader.cpp:101 #12 0xa7ed8f05 in Digikam::DImg::load (this=0xa5807370, filePath=@0x85c6aa4, observer=0x85c6aa0, rawDecodingSettings=Cannot access memory at address 0x0 ) at dimg.cpp:300 #13 0xa7edc006 in DImg (this=0xa5807370, filePath=@0x0, observer=0x0, rawDecodingSettings=Cannot access memory at address 0x0 ) at dimg.cpp:73 #14 0xa7e9069d in Digikam::SharedLoadingTask::execute (this=0x85c6a98) at loadsavetask.cpp:162 ---Type <return> to continue, or q <return> to quit--- #15 0xa7e8cd5b in Digikam::LoadSaveThread::run (this=Cannot access memory at address 0xa58073b4 ) at loadsavethread.cpp:134 Cannot access memory at address 0xa580740c (gdb) I hope this backtrace is usable cause I forgot to disable --fomit-framepointer in my CFLAGS. Let me here if I have to compile it again with debug-friendly CFLAGS.