Bug 128104

Summary: Digikam Crash when browsing photos in Image Editor
Product: digikam Reporter: sero4linux
Component: Metadata-EngineAssignee: 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

Description sero4linux 2006-05-27 00:59:40 UTC
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.
Comment 1 caulier.gilles 2006-05-27 11:26:27 UTC
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
Comment 2 sero4linux 2006-05-27 22:16:28 UTC
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?  
Comment 3 caulier.gilles 2006-05-27 22:52:38 UTC
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
Comment 4 sero4linux 2006-05-28 17:00:57 UTC
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 
Comment 5 caulier.gilles 2006-05-28 21:10:06 UTC
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
Comment 6 sero4linux 2006-06-01 12:03:26 UTC
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.
Comment 7 caulier.gilles 2006-06-01 12:08:39 UTC
Ok toggle it to invalid.

I have contacted the Exiv2 author to have more viewpoints about this subject. The discussion still open

Gilles
Comment 8 Andreas Huggel 2006-06-01 13:03:40 UTC
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
Comment 9 caulier.gilles 2006-06-01 13:11:32 UTC
Sebastian,

Please use this command line with valgrind :

valgrind --tool=memcheck --leak-check=full --error-limit=no digikam

Thanks in advance

Gilles
Comment 10 sero4linux 2006-06-01 19:46:52 UTC
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
Comment 11 sero4linux 2006-06-01 21:50:47 UTC
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?
Comment 12 sero4linux 2006-06-01 21:54:04 UTC
In reply to #9: Gilles, the valgrind comment you provide doesn't work - I only get the message "killed" in the console.
Comment 13 caulier.gilles 2006-06-01 22:11:00 UTC
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
Comment 14 Andreas Huggel 2006-06-02 04:33:19 UTC
#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
Comment 15 sero4linux 2006-06-02 10:06:31 UTC
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.
Comment 16 caulier.gilles 2021-05-04 06:07:07 UTC
Not reproducible with digiKam 7.3.0 and Exiv2 0.27.4