[Digikam-users] SOLVED: updated to DK4.3.0 but it crashes and cannot go back to 4.2.0...

Carl McGrath cmcgrath5035 at comcast.net
Sat Sep 27 12:14:18 BST 2014 

Good news for those affected (I was not)

Interesting, but adding to confusion:
When I open DK ,installed from the digikam-4.3.0-24.1x86.64 (KDE 
Extra_Current),
I still see in Help-Components Information that libKExiv2 is version 2.3.1


On 09/26/2014 10:13 PM, Gian Paolo Sanino Vattier wrote:
> Hi, I did an update today and great news!
> I just got DK4.3.0 working like a charm, without crashing at startup 
> or while opening big albums, regardless of how many videos I have 
> together with the photos, nor the heavy use of tags, etc.
> So for those that have the same issues I had on OpenSuSE 13.1 
> (x86_64), here I share the packages I got for DK and libkexiv2:
>
> KDE:Extra_Current
> http://download.opensuse.org/repositories/KDE:/Extra/KDE_Current_openSUSE_13.1/x86_64/digikam-4.3.0-24.1.x86_64.rpm
> KDE:Current
> http://download.opensuse.org/repositories/KDE:/Current/openSUSE_13.1/x86_64/libkexiv2-11-4.14.1-1.1.x86_64.rpm
> /
> //(RE: language: moi aussi j'aimerais bien de pratiquer un peu mon 
> français... /)
>
> I cannot describe how happy I am! Thank you all!
> gps
>
> On 09/19/2014 01:28 PM, Gian Paolo Sanino Vattier wrote:
>> Strange indeed since the fix is stated to be included starting on
>> libkexiv2-4.14.2.
>> I found a source file 4.14.40 (and its devel file as well) from:
>> http://download.opensuse.org/repositories/KDE:/Unstable:/SC/openSUSE_Factory/src/libkexiv2-4.14.40-14.1.src.rpm
>>
>> It seems to be a more recent version, so I got it compiled using
>> rpmbuild and installed it. Initially it did look like finally I got
>> tamed this issue but no. DK4.3.0 crashes anyway.
>>
>> So I downloaded the most recent source version of libkexiv2 from
>> KDE:CURRENT repo (and its devel version as well):
>> http://download.opensuse.org/repositories/KDE:/Current/openSUSE_13.1/src/libkexiv2-4.14.1-1.1.src.rpm
>>
>> I extracted the source file, then replaced its kexiv2previews.cpp  with
>> Gilles's fixed file, compressed again using gzip and renamed it as
>> *.src.rpm but rpmbuild did not recognized it. :-(
>> I tried with several compressed formats but nothing resulted in a file
>> that rpmbuild could recognize as a source rpm package. If what I am
>> doing wrong is easy to correct (the compressing step of the folder into
>> a src.rpm file) it would be great if somebody helps me with, since this
>> could allow confirming that Gille's fix of libkexiv2 can solve this
>> issue and help other OpenSuSE users  with a similar DK4.3.0 situation.
>> gps
>>   
>>
>> On 09/19/2014 09:59 AM, Robert Zeller wrote:
>>> This is strange: I am also running DK 4.3.0 on opensuse 13.1 and haven't
>>> experienced any crashes so far. My version of libkexiv2-11 is 4.12.3-1.1
>>> form obs://build.opensuse.org/KDE
>>>
>>> On 09/18/2014 05:23 PM, Gian Paolo Sanino wrote:
>>>> Hi Gilles, OpenSuSE has its own libkexiv2 package versioning.  I have
>>>> installed the libkexiv2-11 (aka 4.13.2-4.1). I searched for a more
>>>> recent version on the online built service, and found available in
>>>> Factory repo just a source file version 4.14.1. No idea if this already
>>>> includes your fix on it.
>>>>
>>>> http://download.opensuse.org/repositories/KDE:/Distro:/Factory/openSUSE_Factory/src/libkexiv2-4.14.1-122.2.src.rpm
>>>>
>>>> Decompressing the tar file shows folders with one of them containing a
>>>> kexiv2previews.cpp file that I guess I should replace with your fix file
>>>> and try compiling it and installing it. But I have just a preliminary
>>>> idea about how to do it. I recall that in OpenSuSE the "easy" way is
>>>> using as root the command "rpmbuild --rebuild package.src.rpm" and then
>>>> install it later as any rpm package. However, for this I have to install
>>>> also libexiv2-devel (no problem with this) and libkde4-devel that in my
>>>> system needs to downgrade too many kde base and core files just to run.
>>>> The other option, using "./configure" then "make" and "make install" as
>>>> root, did not worked neither (resulted in "no makefile found"). I may
>>>> doing something wrong for sure and I know this is out of Digikam's forum
>>>> scope anyway.
>>>>
>>>> To prevent these issues, I use to install DK as well as its dependencies
>>>> (e.g. libkexiv2) from distro packages rather than compiling them from
>>>> source. But since even on repos with unstable/developing packages for
>>>> OpenSuSE I see not other package to upgrade to libkexiv2 (2.3.2), I have
>>>> no idea how to solve it other than waiting for an "official" rpm that
>>>> upgrades libkexiv2 with the fix. I tried with a second PC that just got
>>>> updated to DK4.3.0 automatically from OpenSuSE's KDE:EXTRA repo and
>>>> experienced the same result. I guess the packagers at OpenSuSE are not
>>>> including your findings about libkexiv2 and many will experience these
>>>> crashes.
>>>>
>>>> Thanks Gilles, at least now I know where is the problem.
>>>> gps
>>>>
>>>> On 09/18/2014 10:06 AM, Gilles Caulier wrote:
>>>>> The crash is in libkexiv2, when preview are get from file to render
>>>>> image on screen.
>>>>>
>>>>> I ready fixed this problem in source code.
>>>>>
>>>>> There is a report which still open about this topic, where i annotate
>>>>> which simple commit i do to fix it in libkexiv2 :
>>>>>
>>>>> https://bugs.kde.org/show_bug.cgi?id=339144
>>>>>
>>>>> I upgraded libkexiv2 version to 2.3.2. If digiKam do not use this
>>>>> version it will crash.
>>>>>
>>>>> digiKam have been released with this version of libkexiv2, but
>>>>> packager drop libkexiv2 source code from tarball and use system based
>>>>> library.
>>>>>
>>>>> The solution from packager is to backport my little commit in libkexiv2 package.
>>>>>
>>>>> Gilles Caulier
>>>>>
>>>>>
>>>>>
>>>>> 2014-09-18 14:36 GMT+02:00 Gian Paolo Sanino Vattier<gpsanino at vtr.net>:
>>>>>> On 09/18/2014 02:15 AM, Remco Viëtor wrote:
>>>>>>
>>>>>> On Wednesday 17 September 2014 21:01:24 Gian Paolo Sanino Vattier wrote:
>>>>>>
>>>>>> Hi, I wonder if other may be experiencing the same as I do.
>>>>>> I have auto-update enabled (I know, It should not), and today my DK
>>>>>> 4.2.0 got updated to DK 4.3.0 (nice dog on the welcome picture btw).
>>>>>> The problem is that this version crashes just a second after its process
>>>>>> is 100% done (when thumbnails should show up). Repeating attempts
>>>>>> produce the same result (crashed) but sometimes it reaches to show some
>>>>>> thumbnails when it crushes.
>>>>>>
>>>>>> I checked the phonon backend and tried with Gstreamer as well as with
>>>>>> VLC, with no difference.
>>>>>>
>>>>>> This is under OpenSuSE 13.1-x86_64 with KDE 4.11.5
>>>>>>
>>>>>> If I try running DK from the konsole, I get this:
>>>>>>
>>>>>> (...)
>>>>>>
>>>>>> I tried cleaning temp files as well as rebooting the PC, and checking
>>>>>> updates with Yast, but nothing seems to solve the problem. I have no
>>>>>> clue how to solve this DK4.3.0 crash, and I use DK for work and this is
>>>>>> urgent for me, so I decided to go back to 4.2.0 however I have not been
>>>>>> able. I only found it on the "Factory" repo, but it request for
>>>>>> kdebase4-runtime  version >=4.14.0 but all my KDE is 4.11.5 (which is
>>>>>> supposed to be up to date "stable" SuSE release). I may try to update to
>>>>>> KDE 4.14.0 but this can result in total mess. I just do not understand
>>>>>> why I cannot go back to the same version of DK 4.2.0 that I had just
>>>>>> hours ago in thi very same KDE... maybe it is a SuSE packaging issue and
>>>>>> not a DK issue, no idea.
>>>>>>
>>>>>> Anybody else with this issue? or any hint where to look for a solution?
>>>>>> Thanks a lot
>>>>>> gps
>>>>>>
>>>>>> I don't know how you use Digikam, and which part of the functionality you
>>>>>> use, but you can go back to Digikam 3.5.0 (which is still in the Yast
>>>>>> repositories for OpenSuse 13.1). I've been switching back and forth between
>>>>>> 3.5 and 4.x a few times without problems, but back up the databases to be
>>>>>> safe(r).
>>>>>>
>>>>>> Remco
>>>>>>
>>>>>>
>>>>>> Hi Remco, I use Digikam a lot, mainly as a graphic database (filtering using
>>>>>> the tagging tools). DK 4.2.0 was a great version for me since many
>>>>>> improvements were achieved on the tagging side. No idea why DK4.2.0 on SuSE
>>>>>> repos are requesting for KDE versions others than those on which it was
>>>>>> running just fine.
>>>>>> I was able to find on the Build Service a repo with DK 4.0.0 to downgrade
>>>>>> from 4.3.0 and check the results. I use SpiderOak to backup constantly the
>>>>>> database.
>>>>>> I got it and regained immediate control over DK and my files as well...
>>>>>> great.
>>>>>>
>>>>>> Then upgraded to 4.3.0 to double test, and again DK crashes but somehow now
>>>>>> they take longer to crash. In fact, DK opens fine with the root Album
>>>>>> selected as default and it can stay there fine until I select other Album
>>>>>> (with images inside). That is when it starts rebuilding the thumbnails
>>>>>> (recently I deleted my thumbnail.db file). The mystery is that it crashed
>>>>>> almost randomly depending on what folder I select.  With some, it does the
>>>>>> job fine but with others no hope, it crashed immediately. So, maybe this is
>>>>>> something related to previews / thumbnails...
>>>>>>
>>>>>> When I restarted DK, I disabled both "include Album.. sub-tree" options
>>>>>> under menu/View/. By disabling these features, I selected the same
>>>>>> folder/album that always produced crashes and this time no crash. Then
>>>>>> selected one of its sub-folders, with images inside and it crashed again...
>>>>>>
>>>>>> I went back to DK4.0.0 and regained control again. Since DK4.3.0 seems to
>>>>>> crash when creating the new thumbnails of large number of images, I used
>>>>>> 4.0.0 to rebuild all thumbnails. Then updated to 4.3.0 to see if it shows
>>>>>> the albums without crashing, but I was not lucky. The folders starts showing
>>>>>> up and DK crash. Some open fine and other not at all. It feels somehow like
>>>>>> albums with larger number of files tend to crash more often than those with
>>>>>> lower amount of files. It am not sure. But then, the thumbnail building
>>>>>> process does not seem to be a key part of the problem... Another difference
>>>>>> with DK4.3.0 is that after the welcoming frame closes (with the nice dog
>>>>>> jumping) it takes about 15 seconds to open digikam's interface (DK4.2.0
>>>>>> takes no time between the two).
>>>>>>
>>>>>> KDE Crash handler reports the event as : "Executable: digikam PID: 2876
>>>>>> Signal: Segmentation fault (11)".
>>>>>> and KDE backtrace report shows this:
>>>>>>
>>>>>> Application: digiKam (digikam), signal: Segmentation fault
>>>>>>
>>>>>> Using host libthread_db library "/lib64/libthread_db.so.1".
>>>>>>
>>>>>> [Current thread is 1 (Thread 0x7fdc3c95a940 (LWP 2876))]
>>>>>>
>>>>>>
>>>>>> Thread 4 (Thread 0x7fdc15107700 (LWP 2877)):
>>>>>>
>>>>>> #0 0x00007fdc330000af inpthread_cond_wait@@GLIBC_2.3.2  () from
>>>>>> /lib64/libpthread.so.0
>>>>>>
>>>>>> #1 0x00007fdc35e95b66 in QWaitCondition::wait(QMutex*, unsigned long) ()
>>>>>> from /usr/lib64/libQtCore.so.4
>>>>>>
>>>>>> #2 0x00000000005fe6ae in ?? ()
>>>>>>
>>>>>> #3 0x00007fdc35e9568f in ?? () from /usr/lib64/libQtCore.so.4
>>>>>>
>>>>>> #4 0x00007fdc32ffc0db in start_thread () from /lib64/libpthread.so.0
>>>>>>
>>>>>> #5 0x00007fdc350ae58d in clone () from /lib64/libc.so.6
>>>>>>
>>>>>>
>>>>>> Thread 3 (Thread 0x7fdc14906700 (LWP 2878)):
>>>>>>
>>>>>> #0 0x00007fdc2cbd2586 in ?? () from /usr/lib64/libglib-2.0.so.0
>>>>>>
>>>>>> #1 0x00007fdc2cbd270c in g_main_context_iteration () from
>>>>>> /usr/lib64/libglib-2.0.so.0
>>>>>>
>>>>>> #2 0x00007fdc35fc1d76 in
>>>>>> QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
>>>>>> () from /usr/lib64/libQtCore.so.4
>>>>>>
>>>>>> #3 0x00007fdc35f93d0f in
>>>>>> QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from
>>>>>> /usr/lib64/libQtCore.so.4
>>>>>>
>>>>>> #4 0x00007fdc35f94005 in
>>>>>> QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from
>>>>>> /usr/lib64/libQtCore.so.4
>>>>>>
>>>>>> #5 0x00007fdc35e92fef in QThread::exec() () from /usr/lib64/libQtCore.so.4
>>>>>>
>>>>>> #6 0x00007fdc35f75513 in ?? () from /usr/lib64/libQtCore.so.4
>>>>>>
>>>>>> #7 0x00007fdc35e9568f in ?? () from /usr/lib64/libQtCore.so.4
>>>>>>
>>>>>> #8 0x00007fdc32ffc0db in start_thread () from /lib64/libpthread.so.0
>>>>>>
>>>>>> #9 0x00007fdc350ae58d in clone () from /lib64/libc.so.6
>>>>>>
>>>>>>
>>>>>> Thread 2 (Thread 0x7fdb83fff700 (LWP 2944)):
>>>>>>
>>>>>> [KCrash Handler]
>>>>>>
>>>>>> #5 0x00007fdc31e12075 in
>>>>>> Exiv2::PreviewManager::getPreviewImage(Exiv2::PreviewProperties const&)
>>>>>> const () from /usr/lib64/libexiv2.so.12
>>>>>>
>>>>>> #6 0x00007fdc3a66dcb2 in KExiv2Iface::KExiv2Previews::data(int) () from
>>>>>> /usr/lib64/libkexiv2.so.11
>>>>>>
>>>>>> #7 0x00007fdc3a66df0b in KExiv2Iface::KExiv2Previews::image(int) () from
>>>>>> /usr/lib64/libkexiv2.so.11
>>>>>>
>>>>>> #8 0x00007fdc39c6650d in
>>>>>> Digikam::ThumbnailCreator::createThumbnail(Digikam::ThumbnailInfo const&,
>>>>>> QRect const&) const () from /usr/lib64/libdigikamcore.so.4.3.0
>>>>>>
>>>>>> #9 0x00007fdc39c691a6 in Digikam::ThumbnailCreator::load(QString const&,
>>>>>> QRect const&, bool) const () from /usr/lib64/libdigikamcore.so.4.3.0
>>>>>>
>>>>>> #10 0x00007fdc39c69af0 in Digikam::ThumbnailCreator::pregenerate(QString
>>>>>> const&) const () from /usr/lib64/libdigikamcore.so.4.3.0
>>>>>>
>>>>>> #11 0x00007fdc39c784a0 in ?? () from /usr/lib64/libdigikamcore.so.4.3.0
>>>>>>
>>>>>> #12 0x00007fdc39c506c6 in Digikam::LoadSaveThread::run() () from
>>>>>> /usr/lib64/libdigikamcore.so.4.3.0
>>>>>>
>>>>>> #13 0x00007fdc39c7e6be in Digikam::DynamicThread::DynamicThreadPriv::run()
>>>>>> () from /usr/lib64/libdigikamcore.so.4.3.0
>>>>>>
>>>>>> #14 0x00007fdc35e8913e in ?? () from /usr/lib64/libQtCore.so.4
>>>>>>
>>>>>> #15 0x00007fdc35e9568f in ?? () from /usr/lib64/libQtCore.so.4
>>>>>>
>>>>>> #16 0x00007fdc32ffc0db in start_thread () from /lib64/libpthread.so.0
>>>>>>
>>>>>> #17 0x00007fdc350ae58d in clone () from /lib64/libc.so.6
>>>>>>
>>>>>>
>>>>>> Thread 1 (Thread 0x7fdc3c95a940 (LWP 2876)):
>>>>>>
>>>>>> #0 0x00007fdc330000af inpthread_cond_wait@@GLIBC_2.3.2  () from
>>>>>> /lib64/libpthread.so.0
>>>>>>
>>>>>> #1 0x00007fdc35e95b66 in QWaitCondition::wait(QMutex*, unsigned long) ()
>>>>>> from /usr/lib64/libQtCore.so.4
>>>>>>
>>>>>> #2 0x00007fdc35e88b52 in ?? () from /usr/lib64/libQtCore.so.4
>>>>>>
>>>>>> #3 0x00007fdc35e89ef5 in QThreadPool::~QThreadPool() () from
>>>>>> /usr/lib64/libQtCore.so.4
>>>>>>
>>>>>> #4 0x00007fdc35e89f29 in QThreadPool::~QThreadPool() () from
>>>>>> /usr/lib64/libQtCore.so.4
>>>>>>
>>>>>> #5 0x00007fdc35fab658 in QObjectPrivate::deleteChildren() () from
>>>>>> /usr/lib64/libQtCore.so.4
>>>>>>
>>>>>> #6 0x00007fdc35fadbff in QObject::~QObject() () from
>>>>>> /usr/lib64/libQtCore.so.4
>>>>>>
>>>>>> #7 0x00007fdc39c7b847 in ?? () from /usr/lib64/libdigikamcore.so.4.3.0
>>>>>>
>>>>>> #8 0x00007fdc34fff059 in __run_exit_handlers () from /lib64/libc.so.6
>>>>>>
>>>>>> #9 0x00007fdc34fff0a5 in exit () from /lib64/libc.so.6
>>>>>>
>>>>>> #10 0x00007fdc36a0a298 in ?? () from /usr/lib64/libQtGui.so.4
>>>>>>
>>>>>> #11 0x00007fdc376b91a0 in KApplication::xioErrhandler(_XDisplay*) () from
>>>>>> /usr/lib64/libkdeui.so.5
>>>>>>
>>>>>> #12 0x00007fdc3359d3fe in _XIOError () from /usr/lib64/libX11.so.6
>>>>>>
>>>>>> #13 0x00007fdc3359aded in _XEventsQueued () from /usr/lib64/libX11.so.6
>>>>>>
>>>>>> #14 0x00007fdc3358cddb in XEventsQueued () from /usr/lib64/libX11.so.6
>>>>>>
>>>>>> #15 0x00007fdc36a403ac in ?? () from /usr/lib64/libQtGui.so.4
>>>>>>
>>>>>> #16 0x00007fdc2cbd2081 in g_main_context_check () from
>>>>>> /usr/lib64/libglib-2.0.so.0
>>>>>>
>>>>>> #17 0x00007fdc2cbd259b in ?? () from /usr/lib64/libglib-2.0.so.0
>>>>>>
>>>>>> #18 0x00007fdc2cbd270c in g_main_context_iteration () from
>>>>>> /usr/lib64/libglib-2.0.so.0
>>>>>>
>>>>>> #19 0x00007fdc35fc1d55 in
>>>>>> QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
>>>>>> () from /usr/lib64/libQtCore.so.4
>>>>>>
>>>>>> #20 0x00007fdc36a40936 in ?? () from /usr/lib64/libQtGui.so.4
>>>>>>
>>>>>> #21 0x00007fdc35f93d0f in
>>>>>> QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from
>>>>>> /usr/lib64/libQtCore.so.4
>>>>>>
>>>>>> #22 0x00007fdc35f94005 in
>>>>>> QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from
>>>>>> /usr/lib64/libQtCore.so.4
>>>>>>
>>>>>> #23 0x00007fdc35f9913b in QCoreApplication::exec() () from
>>>>>> /usr/lib64/libQtCore.so.4
>>>>>>
>>>>>> #24 0x000000000049f870 in ?? ()
>>>>>>
>>>>>> #25 0x00007fdc34fe8be5 in __libc_start_main () from /lib64/libc.so.6
>>>>>>
>>>>>> #26 0x00000000004a1ec1 in _start ()
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Digikam-users mailing list
>>>>>> Digikam-users at kde.org
>>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>>
>>>>> _______________________________________________
>>>>> Digikam-users mailing list
>>>>> Digikam-users at kde.org
>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>> _______________________________________________
>>> Digikam-users mailing list
>>> Digikam-users at kde.org
>>> https://mail.kde.org/mailman/listinfo/digikam-users
>> _______________________________________________
>> Digikam-users mailing list
>> Digikam-users at kde.org
>> https://mail.kde.org/mailman/listinfo/digikam-users
>
>
>
> _______________________________________________
> Digikam-users mailing list
> Digikam-users at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20140927/082f2c68/attachment.html>

More information about the Digikam-users mailing list