Version: 0.9 SVN (using KDE KDE 3.5.2)
Installed from: Gentoo Packages
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):
#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 ()
#7 0xa632bb5d in operator delete ()
#8 0xa79e0cfa in Exiv2::ExifData::~ExifData () from /usr/lib/libexiv2-0.9.1.so
#9 0xa7ef3cbd in Digikam::DMetadata::getExif (this=0xa5806c50)
#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)
---Type <return> to continue, or q <return> to quit---
#15 0xa7e8cd5b in Digikam::LoadSaveThread::run (this=Cannot access memory at address 0xa58073b4
Cannot access memory at address 0xa580740c
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.
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.
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.
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.
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.
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"
FLAGS THAT WORK
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
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?
Please use this command line with valgrind :
valgrind --tool=memcheck --leak-check=full --error-limit=no digikam
Thanks in advance
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).
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
#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 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