Bug 237889 - kphotoalbum crashes while scanning for new images
Summary: kphotoalbum crashes while scanning for new images
Status: RESOLVED FIXED
Alias: None
Product: kphotoalbum
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR crash
Target Milestone: ---
Assignee: KPhotoAlbum Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-16 23:52 UTC by Knut Esztermann
Modified: 2012-01-16 23:31 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
image file from an S20 HP scanner under Win 2k (VirtualBox) (58.27 KB, image/jpeg)
2010-09-21 22:40 UTC, denis
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Knut Esztermann 2010-05-16 23:52:38 UTC
Version:           4.1.1 (using KDE 4.4.3)
Compiler:          gcc version 4.4.4 (Debian 4.4.4-1) 
OS:                Linux
Installed from:    Debian testing/unstable Packages

After adding a large amount of new images, kphotoalbum crashed reproducible while scanning for them. I was able to narrow it down to two particular files causing the crash. If needed, I can provide those files.

 -- Backtrace:
Application: KPhotoAlbum (kphotoalbum), signal: Segmentation fault
[KCrash Handler]
#6  0xf71215cc in Exiv2::ValueType<std::pair<unsigned int, unsigned int> >::toRational (this=0x16ca9d70, n=0) at value.hpp:1609
#7  0xf7130a29 in Exiv2::Exifdatum::toRational (this=0x92e4ea0, n=0) at exif.cpp:417
#8  0x081a8291 in Exif::RationalExifElement::bindValues (this=0x111a4568, query=0xffc8abb0, counter=@0xffc8abac, data=...) at /root/kphotoalbum-4.1.1/Exif/DatabaseElement.cpp:96
#9  0x0818fd95 in Exif::Database::insert (this=0x11565de8, filename=..., data=...) at /root/kphotoalbum-4.1.1/Exif/Database.cpp:187
#10 0x0818f7cf in Exif::Database::add (this=0x11565de8, fileName=...) at /root/kphotoalbum-4.1.1/Exif/Database.cpp:151
#11 0x08140cd1 in DB::ImageInfo::readExif (this=0xce562b8, fullPath=..., mode=...) at /root/kphotoalbum-4.1.1/DB/ImageInfo.cpp:352
#12 0x0813fe96 in ImageInfo (this=0xce562b8, relativeFileName=..., type=DB::Image, readExifInfo=true) at /root/kphotoalbum-4.1.1/DB/ImageInfo.cpp:56
#13 0x0815425e in DB::NewImageFinder::loadExtraFile (this=0xffc8ae48, relativeNewFileName=..., type=DB::Image) at /root/kphotoalbum-4.1.1/DB/NewImageFinder.cpp:230
#14 0x08153c1e in DB::NewImageFinder::loadExtraFiles (this=0xffc8ae48) at /root/kphotoalbum-4.1.1/DB/NewImageFinder.cpp:182
#15 0x081530d9 in DB::NewImageFinder::findImages (this=0xffc8ae48) at /root/kphotoalbum-4.1.1/DB/NewImageFinder.cpp:63
#16 0x0814fa0b in DB::ImageDB::slotRescan (this=0x9085370) at /root/kphotoalbum-4.1.1/DB/ImageDB.cpp:108
#17 0x08150e80 in DB::ImageDB::qt_metacall (this=0x9085370, _c=QMetaObject::InvokeMetaMethod, _id=5, _a=0xffc8af4c) at /root/kphotoalbum-4.1.1/obj-i486-linux-gnu/ImageDB.moc:97
#18 0x080b676c in XMLDB::Database::qt_metacall (this=0x9085370, _c=QMetaObject::InvokeMetaMethod, _id=9, _a=0xffc8af4c) at /root/kphotoalbum-4.1.1/obj-i486-linux-gnu/Database.moc:74
#19 0xf6490aea in QMetaObject::metacall (object=0x9085370, cl=4145157530, idx=9, argv=0xffc8af4c) at kernel/qmetaobject.cpp:237
#20 0xf649f0b5 in QMetaObject::activate (sender=0x1adf3e58, m=0xf659e704, local_signal_index=0, argv=0x0) at kernel/qobject.cpp:3293
#21 0xf64f0927 in QTimer::timeout (this=0x1adf3e58) at .moc/release-shared/moc_qtimer.cpp:134
#22 0xf64a733e in QTimer::timerEvent (this=0x1adf3e58, e=0xffc8b480) at kernel/qtimer.cpp:271
#23 0xf649bf34 in QObject::event (this=0x1adf3e58, e=0x0) at kernel/qobject.cpp:1212
#24 0xf59d2bec in QApplicationPrivate::notify_helper (this=0x8fe2a30, receiver=0x1adf3e58, e=0xffc8b480) at kernel/qapplication.cpp:4300
#25 0xf59d975e in QApplication::notify (this=0xffc8b7dc, receiver=0x1adf3e58, e=0xffc8b480) at kernel/qapplication.cpp:3704
#26 0xf6aaa7da in KApplication::notify(QObject*, QEvent*) () from /usr/lib/libkdeui.so.5
#27 0xf648b8eb in QCoreApplication::notifyInternal (this=0xffc8b7dc, receiver=0x1adf3e58, event=0xffc8b480) at kernel/qcoreapplication.cpp:704
#28 0xf64ba946 in QCoreApplication::sendEvent (this=0x8fe57a4) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:215
#29 QTimerInfoList::activateTimers (this=0x8fe57a4) at kernel/qeventdispatcher_unix.cpp:603
#30 0xf64b7604 in timerSourceDispatch (source=0x8fe5770) at kernel/qeventdispatcher_glib.cpp:184
#31 0xf3d542f5 in g_main_dispatch (context=0x8fe4e90) at /build/buildd-glib2.0_2.24.1-1-i386-84Pp4V/glib2.0-2.24.1/glib/gmain.c:1960
#32 IA__g_main_context_dispatch (context=0x8fe4e90) at /build/buildd-glib2.0_2.24.1-1-i386-84Pp4V/glib2.0-2.24.1/glib/gmain.c:2513
#33 0xf3d57fd8 in g_main_context_iterate (context=0x8fe4e90, block=<value optimized out>, dispatch=1, self=0x8fe2550) at /build/buildd-glib2.0_2.24.1-1-i386-84Pp4V/glib2.0-2.24.1/glib/gmain.c:2591
#34 0xf3d581b8 in IA__g_main_context_iteration (context=0x8fe4e90, may_block=1) at /build/buildd-glib2.0_2.24.1-1-i386-84Pp4V/glib2.0-2.24.1/glib/gmain.c:2654
#35 0xf64b72f5 in QEventDispatcherGlib::processEvents (this=0x8fbc330, flags=...) at kernel/qeventdispatcher_glib.cpp:412
#36 0xf5a91255 in QGuiEventDispatcherGlib::processEvents (this=0x8fbc330, flags=...) at kernel/qguieventdispatcher_glib.cpp:204
#37 0xf6489f09 in QEventLoop::processEvents (this=0xffc8b744, flags=) at kernel/qeventloop.cpp:149
#38 0xf648a35a in QEventLoop::exec (this=0xffc8b744, flags=...) at kernel/qeventloop.cpp:201
#39 0xf648e4ef in QCoreApplication::exec () at kernel/qcoreapplication.cpp:981
#40 0xf59d2c87 in QApplication::exec () at kernel/qapplication.cpp:3579
#41 0x0808df1b in main (argc=1, argv=0xffc8ba34) at /root/kphotoalbum-4.1.1/main.cpp:86
Comment 1 Miika Turkia 2010-06-20 09:04:40 UTC
First impression from the backtrace indicates the problem to be in libexiv2 library. If that is the case then the exiv2 library needs fixing. In any case the problematic files would be useful to verify the problem.
Comment 2 Jesper Pedersen 2010-07-03 20:27:50 UTC
Yes, please email me at blackie@kde.org with the bogus files. I agree with thebro that it likely is a bug in the file or in exiv2, but it would be nice to confirm
Comment 3 denis 2010-09-12 04:29:12 UTC
I am running the same version of KPA, KDE 4.4.2 in Ubuntu 10.04 LTS.  I get a seg fault if I click on the "Recreate Exif search database".  I had a similar crash after adding files, so I removed the new files and used my backups to replace exif-info.db and index.xml.  Now I can use KPA, but "Recreate Exif search database" produces a reliable, reproducible crash.  I note that executing "Recreate Exif search database" is what is required when adding new files.

I tried to get the debug libraries for KPA without success.  Where are they?

-Denis
Comment 4 denis 2010-09-12 17:35:50 UTC
Doing more exploration--Ran the demo, quit KPA saving the demo files in /tmp.  Examined exif-info.db in /tmp/kphotoalbum-demo-parents.  It is SQLite 3.  The exif-info.db file in my photo collection is SQLite 2.  Could this be why "Recreate Exif search database" causes a seg fault?  Is there a way to fix this?

-Denis
Comment 5 Miika Turkia 2010-09-13 06:07:59 UTC
Try deleting (make a backup) the exif-info.db.
Comment 6 denis 2010-09-13 16:49:27 UTC
Deleted exif-info.db.  Started KPA.  A new exif-info.db was created--3KB, SQLite3.  KPA crashes as before when trying to Recreate Exif search database.

-Denis
Comment 7 denis 2010-09-13 17:06:15 UTC
I added a .jpg file to the saved demo files.  The demo ran fine; Recreate Exif search database worked as it should.

-Denis
Comment 8 Miika Turkia 2010-09-13 19:19:33 UTC
The recreate db works for me just fine. What is your version of libexiv2? Upgrading that might be the solution. If that does not do it, the problematic file(s) should be identified and used to debug the problem. We cannot do much without means to reproduce the crash...
Comment 9 Denis Heidtmann 2010-09-13 20:05:39 UTC
My version of libexiv2 is 0.19. Synaptic says that is the latest.

Are you saying that one or more of my image data files may be the cause of
the problem?
-Denis

On Mon, Sep 13, 2010 at 10:19 AM, <miika.turkia@gmail.com> wrote:

> https://bugs.kde.org/show_bug.cgi?id=237889
>
>
>
>
>
> --- Comment #8 from  <miika turkia gmail com>  2010-09-13 19:19:33 ---
> The recreate db works for me just fine. What is your version of libexiv2?
> Upgrading that might be the solution. If that does not do it, the
> problematic
> file(s) should be identified and used to debug the problem. We cannot do
> much
> without means to reproduce the crash...
>
> --
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
>
Comment 10 denis 2010-09-21 22:40:37 UTC
Created attachment 51869 [details]
image file from an S20 HP scanner under Win 2k (VirtualBox)

One of many files which cause a crash. Stripping exif data eliminates the problem.
Comment 11 denis 2010-09-21 22:45:41 UTC
I have found that I have 11 proven .jpg files which cause a crash, and perhaps 88 more.  If I strip the exif data using jhead -purejpg <file>, the resulting .jpg does not cause a crash.  The test is to copy the suspect file into the /tmp folder for the demo, then rescan for new images.  The files were generated using an HP scanner running under Windows (VirtualBox). I am running:

kphotoalbum 4.1.1-2ubuntu1 (Synaptic shows this as the Latest Version.)
libexiv2-6  0.19-1 (also shown as Latest Version)
Ubuntu 10.04 LTS

A faulty file is attached.
Comment 12 Miika Turkia 2010-12-22 06:41:37 UTC
This should be fixed now in revision 1208526.