| Summary: | Digikam Crashes When Saving PNG Files, now 1.2.0 also | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Scott <sajmmiller> |
| Component: | Plugin-DImg-PNG | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | caulier.gilles, giuseppe.vinci, jkopare, kde.org, kde, kovariadam, sajmmiller, tliebscher, uwe.haider |
| Priority: | NOR | ||
| Version: | 1.1.0 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 1.2.0 | |
| Sentry Crash Report: | |||
| Attachments: | New crash information added by DrKonqi | ||
|
Description
Scott
2010-03-04 01:22:12 UTC
Bactrace is not suitable. Can you run digiKam in gdb as explained there : http://www.digikam.org/drupal/contrib digiKam debug package need to be installed too... Gilles Caulier (In reply to comment #1) > Bactrace is not suitable. Can you run digiKam in gdb... Followed the linked instructions you sent and ran with gdb -- hopefully this is what you need? Thank you! digikam(2154)/KEXIV2 KExiv2Iface::KExiv2::setImagePreview: JPEG image preview size: ( 1280 x 960 ) pixels - 195027 bytes digikam(2154)/digikam (core) Digikam::PNGLoader::save: DImg quality level: 1 digikam(2154)/digikam (core) Digikam::PNGLoader::save: PNG compression level: 9 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffce37d710 (LWP 2201)] 0x00007ffff194d7c2 in strlen () from /lib/libc.so.6 (gdb) bt #0 0x00007ffff194d7c2 in strlen () from /lib/libc.so.6 #1 0x00007ffff0d6a9fe in png_set_text_2 () from /usr/lib/libpng14.so.14 #2 0x00007ffff0d6ac29 in png_set_text () from /usr/lib/libpng14.so.14 #3 0x00007ffff54028f2 in Digikam::PNGLoader::save(QString const&, Digikam::DImgLoaderObserver*) () from /usr/lib/libdigikamcore.so.1 #4 0x00007ffff53f32dc in Digikam::DImg::save(QString const&, QString const&, Digikam::DImgLoaderObserver*) () from /usr/lib/libdigikamcore.so.1 #5 0x00007ffff54c6b8e in Digikam::SavingTask::execute() () from /usr/lib/libdigikamcore.so.1 #6 0x00007ffff54b498c in Digikam::LoadSaveThread::run() () from /usr/lib/libdigikamcore.so.1 #7 0x00007ffff26ba155 in ?? () from /usr/lib/libQtCore.so.4 #8 0x00007ffff04f181a in start_thread () from /lib/libpthread.so.0 #9 0x00007ffff19a0c7d in clone () from /lib/libc.so.6 #10 0x0000000000000000 in ?? () (gdb) trace said a crash into libpng 1.4. I remember a patch applied to current code from svn (next digiKam 1.2.0) into PNG image loader. I recommend to checkout code from svn trunk and try again. Gilles Caulier Thanks Gilles, I tested for this bug running Digikam 1.1.0 on my Gentoo system running libpng 1.2.40 and everything works fine. So, the problem would seem to be related to the newer libpng version 1.4.0 on my Arch system. I'll try the Digikam SVN version with libpng 1.4.0 on my Arch system as you suggest. (In reply to comment #3) > trace said a crash into libpng 1.4. I remember a patch applied to current code > from svn (next digiKam 1.2.0) into PNG image loader. > > I recommend to checkout code from svn trunk and try again. > > Gilles Caulier Thank you Gilles. I built the SVN version as you suggested and the problem is fixed as you suspected. I appreciate your help. Now I can enjoy all the greatness that Digikam 1.1.0 has to offer. :) I'll go ahead and change the status to resolved. *** Bug 229412 has been marked as a duplicate of this bug. *** Well I'm still having this bug with latest svn code and saving as png in editor. I'm on arch linux 64 bit, kde 4.4.1 (kdemod). Installed digikam from svn today. libpng 1.4.1 is installed. If anyone tells me how to compile the arch package digikam-svn with debug symbols i'd be happy to provide more info. Found a way to compile with debugfull. However i'm now unable to reproduce the bug... Will report here if I get it. I think this bug needs to be re-opened. I have it again using the Arch Linux Digikam 1.2.0 package. I still have SVN build 1.2.0 rev 1099466 from one month ago on my system and it still works fine. So, it would appear that the bug has been reintroduced since then. Do you want gdb output again? Scott: Replace extra/digikam with aur/digikam-svn and see if the bug is there again. A few days ago I had the bug with aur/digikam-svn. I then tried to compile with debug flag and the bug disappeared! Compiling with debug is easily done by editing PKGBUILD and adding -DCMAKE_BUILD_TYPE=debugfull to cmake At least I can continue my work this way and if a bug appears I'm able to submit a proper crash info. Following is the gdb backtrace running Arch Linux extra/digikam 1.2.0-2. I have not tried aur/digikam-svn yet, but will do so. (Thanks François). ----------bt digikam(8174)/digikam (core) Digikam::FileSaveOptionsBox::discoverFormat: Using fallback format 0 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffcbfff710 (LWP 8217)] 0x00007ffff1861842 in strlen () from /lib/libc.so.6 (gdb) bt #0 0x00007ffff1861842 in strlen () from /lib/libc.so.6 #1 0x00007ffff0c7ea04 in png_set_text_2 () from /usr/lib/libpng14.so.14 #2 0x00007ffff0c7ec19 in png_set_text () from /usr/lib/libpng14.so.14 #3 0x00007ffff5344042 in Digikam::PNGLoader::save(QString const&, Digikam::DImgLoaderObserver*) () from /usr/lib/libdigikamcore.so.1 #4 0x00007ffff5338aaf in Digikam::DImg::save(QString const&, QString const&, Digikam::DImgLoaderObserver*) () from /usr/lib/libdigikamcore.so.1 #5 0x00007ffff54830ee in Digikam::SavingTask::execute() () from /usr/lib/libdigikamcore.so.1 #6 0x00007ffff5470b3c in Digikam::LoadSaveThread::run() () from /usr/lib/libdigikamcore.so.1 #7 0x00007ffff25d2155 in ?? () from /usr/lib/libQtCore.so.4 #8 0x00007ffff040588a in start_thread () from /lib/libpthread.so.0 #9 0x00007ffff18b49ed in clone () from /lib/libc.so.6 #10 0x0000000000000000 in ?? () (gdb) François and All, The Arch Linux aur/digikam-svn version is older than the SVN version I had manually compiled a month ago, so I decided not to compile it. Instead, I compiled the /extra/digikam 1.2.0 source (should be same source that was used to build problematic Arch binary package) using Arch abs with -DCMAKE_BUILD_TYPE=debugfull Just like François describes, the bug disappears when compiled with full debugging enabled. Now I'm thinking that I need to recompile the same source with debugging symbols turned off again to see if the bug went away because of compilation on my system or because of the debug settings. What do you mean by the aur package being old. From what I can see it's checking out the source from svn: http://aur.archlinux.org/packages/digikam-svn/digikam-svn/PKGBUILD Don't you confuse with the time the PKGBUILD was last updated? To get back to this bug: is it only back in Arch linux? Are there other distros affected? (In reply to comment #13) > What do you mean by the aur package being old. > From what I can see it's checking out the source from svn: > http://aur.archlinux.org/packages/digikam-svn/digikam-svn/PKGBUILD > Don't you confuse with the time the PKGBUILD was last updated? Yes, you are correct. My mistake--sorry. I'm new to Arch Linux and am still trying to learn how things work. > > To get back to this bug: is it only back in Arch linux? Are there other distros > affected? I don't know. If no one else can confirm the bug in another distro, I have an old computer with Gentoo installed which I could try to update and compile digikam in an attempt to reproduce the bug. Let me know if you want me to try. On my Arch system I've now compiled abs /extra/digikam 1.2.0 with and without debugging: With -DCMAKE_BUILD_TYPE=debugfull (Cannot reproduce bug) Without -DCMAKE_BUILD_TYPE=debugfull (Bug always reproducible) >With -DCMAKE_BUILD_TYPE=debugfull (Cannot reproduce bug) >Without -DCMAKE_BUILD_TYPE=debugfull (Bug always reproducible) That makes it kind of hard to track then! >Let me know if you want me to try. Some kde developer will have to decide, I'm just a user like you. If no other distro is affected we may want to report this against Arch. Maybe I got a decent backtrace this time showing debugging symbols enabled using the following method outlined in the Arch Wiki here: http://wiki.archlinux.org/index.php/Debug_-_Getting_Traces This trace was obtained from source compiled using ABS /extra/digikam 1.2.0 -------------- digikam(7193)/digikam (core) Digikam::FileSaveOptionsBox::discoverFormat: Using fallback format 0 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffd0b3d710 (LWP 7238)] 0x00007ffff1861842 in strlen () from /lib/libc.so.6 (gdb) bt #0 0x00007ffff1861842 in strlen () from /lib/libc.so.6 #1 0x00007ffff0c7ea04 in png_set_text_2 () from /usr/lib/libpng14.so.14 #2 0x00007ffff0c7ec19 in png_set_text () from /usr/lib/libpng14.so.14 #3 0x00007ffff5344042 in Digikam::PNGLoader::save (this=<value optimized out>, filePath=<value optimized out>, observer=<value optimized out>) at /extra/abs/digikam/src/digikam-1.2.0/libs/dimg/loaders/pngloader.cpp:797 #4 0x00007ffff5338aaf in Digikam::DImg::save (this=0x49f86e8, filePath=..., format=<value optimized out>, observer=0x49f86d0) at /extra/abs/digikam/src/digikam-1.2.0/libs/dimg/dimg.cpp:578 #5 0x00007ffff5482ffe in Digikam::SavingTask::execute (this=0x49f86c0) at /extra/abs/digikam/src/digikam-1.2.0/libs/threadimageio/loadsavetask.cpp:418 #6 0x00007ffff5470a4c in Digikam::LoadSaveThread::run (this=0x457e040) at /extra/abs/digikam/src/digikam-1.2.0/libs/threadimageio/loadsavethread.cpp:134 #7 0x00007ffff25d2155 in ?? () from /usr/lib/libQtCore.so.4 #8 0x00007ffff040588a in start_thread () from /lib/libpthread.so.0 #9 0x00007ffff18b49ed in clone () from /lib/libc.so.6 #10 0x0000000000000000 in ?? () (gdb) #ifdef PNG_iTXt_SUPPORTED
// TODO : this code is not yet tested. It require libpng 1.3.0.
case(DImg::COM):
{
png_text comment;
comment.key = const_cast<char*> ("Comment");
comment.text = ba.data();
comment.itxt_length = ba.size();
comment.compression = PNG_ITXT_COMPRESSION_zTXt;
png_set_text(png_ptr, info_ptr, &(comment), 1);
kDebug() << "Writing digiKam comment into iTXt PNG chunk : " << ba;
break;
}
#endif
What is your libpng version?
(In reply to comment #17) > What is your libpng version? Currently 1.4.1 Was 1.4.0 when I first encountered the bug last month. Same version here 1.4.1 Ok, this is the problem. I cannot test this case because I cannot easily upgrade libpng. One thing to try is replacing PNG_ITXT_COMPRESSION_zTXt with PNG_ITXT_COMPRESSION_NONE If this doesn't help I will comment out this section until someone finds the problem. Marcel, Yes, i written this code embeded lead digiKam comments as UTF8 string png chunk. Code have been written when libPNG 1.2.x been in production. In this version libpng do not suport utf8 text chunk. Has now libPNG 1.4.x is out, this code is used as well. Gilles Caulier So would the solution be a compiler flag that controls such feature? Then each distro would be able to compile against their version of libpng. Arch is 1.4.1, Ubuntu 1.3, etc... Also, why does the bug disappear when digikam is compiled with debugfull? Are the resulting PNG safe to use? (In reply to comment #20) > Ok, this is the problem. I cannot test this case because I cannot easily > upgrade libpng. I'm also wondering why -DCMAKE_BUILD_TYPE=debugfull eliminates the bug. Does it cause the problematic section of code to be skipped somehow? > One thing to try is replacing PNG_ITXT_COMPRESSION_zTXt with > PNG_ITXT_COMPRESSION_NONE > If this doesn't help I will comment out this section until someone finds the > problem. I searched for the code string you referenced and found it in pngloader.cpp. I guess I should have been able to figure that out from the trace...this is learning experience for me. Anyway, I replaced PNG_ITXT_COMPRESSION_zTXt with PNG_ITXT_COMPRESSION_NONE, recompiled, and the bug remains. I commented out the problematic code in pngloader.cpp (listed in comment #17 above) and everything seems to work fine. For future reference, I'd still be very interested to know why -DCMAKE_BUILD_TYPE=debugfull bypassed the bug if anyone has the time to explain. Thanks everyone! Gilles, is it ok to comment out this part? Or does any developer have libpng 1.4 for testing? yes, it's ok. In fact Exiv2 will write UTF8 comments to dedicated png text chunk. Gilles I got 1.4 running but I didn't get a crash so far. SVN commit 1111120 by mwiesweg: Comment out section causing crash BUG: 229340 M +3 -2 pngloader.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1111120 Nicolas, Another little patch which can be applied against digiKam 1.2.0 tarball Gilles Caulier *** Bug 247908 has been marked as a duplicate of this bug. *** *** Bug 231631 has been marked as a duplicate of this bug. *** Created attachment 52006 [details]
New crash information added by DrKonqi
Crash happned as I tried to save resized part of picture
*** Bug 256330 has been marked as a duplicate of this bug. *** |