Bug 159855

Summary: BUG - while appling tag changes.
Product: [Applications] digikam Reporter: Lars Sadau <lars>
Component: Tags-EngineAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: caulier.gilles, marcel.wiesweg
Priority: NOR    
Version: 0.9.3   
Target Milestone: ---   
Platform: Ubuntu   
OS: Linux   
Latest Commit: Version Fixed In: 5.1.0
Sentry Crash Report:

Description Lars Sadau 2008-03-25 21:21:58 UTC 
Version:            (using KDE 3.5.8)
Installed from:    Ubuntu Packages
Compiler:          not of interest 
OS:                Linux

If you have applied a tag to a lot of pictures and you choose a new one and change those tags too, the changes will apply to all former selected pictures. For seeing this, applying of tags have to be in progress while changing next pictures tags.
Comment 1 Achim Bohnet 2008-03-26 00:07:57 UTC 
Hi Lars,
with digikam version?  That you use kde 3.5.8 seem to indicate that you're
using 7.10 (gutsy) and therefore digikam 0.9.2.   Can you try 0.9.3 pkgs at

       http://www.mpe.mpg.de/~ach/kubuntu/gutsy/Pkgs.php

I use these pkgs (of course ;) and can't reproduce it (maybe I'm too slow or maybe my laptop is too fast or maybe ...).

Achim
Comment 2 Mikolaj Machowski 2008-03-26 19:34:18 UTC 
Are you sure previous selection was deselected? It was my problem
several times.
Comment 3 caulier.gilles 2008-03-27 14:35:32 UTC 
Lars,

Can you test Achim package ?

Gilles Caulier
Comment 4 Lars Sadau 2008-03-27 17:20:01 UTC 
Yes, I am sure.

Mikolaj Machowski schrieb:
[bugs.kde.org quoted mail]
Comment 5 Lars Sadau 2008-03-28 00:09:18 UTC 
I tested the Achim package and it has also the bug. May be it is because
I have activated the automatically update.

Gilles Caulier schrieb:
[bugs.kde.org quoted mail]
Comment 6 Arnd Baecker 2008-04-10 08:47:53 UTC 
I did not succeed to reproduce it with current svn
(I think I was fast enough - progress bar was still moving -
but maybe still not fast enough ... ;-)
Comment 7 caulier.gilles 2008-12-06 08:15:50 UTC 
Lars,

What's new about this report ? it still valid using digiKam 0.9.4 ?

Gilles Caulier
Comment 8 Mikolaj Machowski 2008-12-06 19:01:12 UTC 
Confirming for 0.9.5svn . New action just kicks in while old is still performing.

a) Select 1000 images
b) assign A tag
c) while b) still works assign B tag

First 100 images has A tag, the rest A and B tags.
Comment 9 Mikolaj Machowski 2008-12-06 21:32:29 UTC 
And for 0.10-b7svn also.
Comment 10 Marcel Wiesweg 2008-12-07 21:32:09 UTC 
Very short term solution: Set wait cursor and block user interaction while assigning tags.
Short term solution: Find out why a second drag solution has influence and the other operation. This is currently unclear to me.
Do you use drag&drop and the tag sidebars, or do you use the metadata right sidebar to assign tags? Probably the latter...

As a better solution, I would like to integrate this to Gilles' batch queue manager work-in-progress.
Comment 11 caulier.gilles 2008-12-07 21:37:31 UTC 
Marcel,

This file is open with KDE3 code. Batch Queue Manager is for KDE4...

Gilles
Comment 12 Mikolaj Machowski 2008-12-07 22:59:12 UTC 
> Do you use drag&drop and the tag sidebars, or do you use the metadata right
> sidebar to assign tags?

Yes, using that one.

But tried dragging to the Tag filters panel and it resulted in crash (0.10b7svn):

Application: digiKam (digikam), signal SIGSEGV
 [?1034h[Thread debugging using libthread_db enabled]
[Current thread is 1 (Thread 0xb4be36d0 (LWP 11921))]

Thread 11 (Thread 0xb36b5b90 (LWP 11923)):
#0  0xffffe430 in __kernel_vsyscall ()
#1  0xb6281b95 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0
#2  0xb62df0b2 in QWaitCondition::wait () from /usr/lib/qt4/lib/libQtCore.so.4
#3  0x08265679 in Digikam::ScanController::run ()
#4  0xb62de320 in ?? () from /usr/lib/qt4/lib/libQtCore.so.4
#5  0x09a3ae00 in ?? ()
#6  0x00000000 in ?? ()

Thread 10 (Thread 0xb2452b90 (LWP 11926)):
#0  0xffffe430 in __kernel_vsyscall ()
#1  0xb6281b95 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0
#2  0xb62df0b2 in QWaitCondition::wait () from /usr/lib/qt4/lib/libQtCore.so.4
#3  0xb7788ba2 in Digikam::LoadSaveThread::run () from /home/mikolaj/kde/lib/libdigikamcore.so.1
#4  0xb62de320 in ?? () from /usr/lib/qt4/lib/libQtCore.so.4
#5  0x09a788a0 in ?? ()
#6  0x00000000 in ?? ()

Thread 9 (Thread 0xb2c7fb90 (LWP 11927)):
#0  0xffffe430 in __kernel_vsyscall ()
#1  0xb6281b95 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0
#2  0xb62df0b2 in QWaitCondition::wait () from /usr/lib/qt4/lib/libQtCore.so.4
#3  0xb7788ba2 in Digikam::LoadSaveThread::run () from /home/mikolaj/kde/lib/libdigikamcore.so.1
#4  0xb62de320 in ?? () from /usr/lib/qt4/lib/libQtCore.so.4
#5  0x09b750d0 in ?? ()
#6  0x00000000 in ?? ()

Thread 8 (Thread 0xb00b3b90 (LWP 12011)):
#0  0xffffe430 in __kernel_vsyscall ()
#1  0xb6281ec2 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0
#2  0xb049240b in metronom_sync_loop (this=0x9c8e808) at metronom.c:871
#3  0xb627e315 in start_thread () from /lib/i686/libpthread.so.0
#4  0xb584fdde in clone () from /lib/i686/libc.so.6

Thread 7 (Thread 0xaf452b90 (LWP 12016)):
#0  0xffffe430 in __kernel_vsyscall ()
#1  0xb5848101 in select () from /lib/i686/libc.so.6
#2  0xb04bb435 in xine_usec_sleep (usec=0) at utils.c:457
#3  0xb049fd8b in video_out_loop (this_gen=0x9c939c8) at video_out.c:1246
#4  0xb627e315 in start_thread () from /lib/i686/libpthread.so.0
#5  0xb584fdde in clone () from /lib/i686/libc.so.6

Thread 6 (Thread 0xaec51b90 (LWP 12017)):
#0  0xb627f775 in pthread_mutex_lock () from /lib/i686/libpthread.so.0
#1  0xb516ad04 in ?? () from /usr/lib/libglib-2.0.so.0
#2  0xb516b0a8 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#3  0xb63df717 in QEventDispatcherGlib::processEvents () from /usr/lib/qt4/lib/libQtCore.so.4
#4  0xb63b76fa in QEventLoop::processEvents () from /usr/lib/qt4/lib/libQtCore.so.4
#5  0xb63b78ba in QEventLoop::exec () from /usr/lib/qt4/lib/libQtCore.so.4
#6  0xb62db4c3 in QThread::exec () from /usr/lib/qt4/lib/libQtCore.so.4
#7  0xb1c23879 in Phonon::Xine::XineThread::run () from /home/mikolaj/kde/lib/kde4/plugins/phonon_backend/phonon_xine.so
#8  0xb62de320 in ?? () from /usr/lib/qt4/lib/libQtCore.so.4
#9  0x09c92c18 in ?? ()
#10 0x00000000 in ?? ()

Thread 5 (Thread 0xae1d3b90 (LWP 12028)):
#0  0xaf8981af in ao_alsa_handle_event_thread (data=0xa0a3aa8) at audio_alsa_out.c:176
#1  0xb627e315 in start_thread () from /lib/i686/libpthread.so.0
#2  0xb584fdde in clone () from /lib/i686/libc.so.6

Thread 4 (Thread 0xad9bfb90 (LWP 12030)):
#0  0xffffe430 in __kernel_vsyscall ()
#1  0xb6281b95 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0
#2  0xb04a2980 in ao_loop (this_gen=0xa0b9db8) at audio_out.c:345
#3  0xb627e315 in start_thread () from /lib/i686/libpthread.so.0
#4  0xb584fdde in clone () from /lib/i686/libc.so.6

Thread 3 (Thread 0xad1beb90 (LWP 12279)):
#0  0xffffe430 in __kernel_vsyscall ()
#1  0xb6281b95 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0
#2  0xb62df0b2 in QWaitCondition::wait () from /usr/lib/qt4/lib/libQtCore.so.4
#3  0xb7788ba2 in Digikam::LoadSaveThread::run () from /home/mikolaj/kde/lib/libdigikamcore.so.1
#4  0xb62de320 in ?? () from /usr/lib/qt4/lib/libQtCore.so.4
#5  0x0bcd7c68 in ?? ()
#6  0x00000000 in ?? ()

Thread 2 (Thread 0xac1bcb90 (LWP 12448)):
#0  0xffffe430 in __kernel_vsyscall ()
#1  0xb6281b95 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0
#2  0xb62df0b2 in QWaitCondition::wait () from /usr/lib/qt4/lib/libQtCore.so.4
#3  0xb7788ba2 in Digikam::LoadSaveThread::run () from /home/mikolaj/kde/lib/libdigikamcore.so.1
#4  0xb62de320 in ?? () from /usr/lib/qt4/lib/libQtCore.so.4
#5  0x0c7baa10 in ?? ()
#6  0x00000000 in ?? ()

Thread 1 (Thread 0xb4be36d0 (LWP 11921)):
[KCrash Handler]
#6  0xb63b7619 in QEventLoop::exit () from /usr/lib/qt4/lib/libQtCore.so.4
#7  0xb5cb38b4 in QDragManager::eventFilter () from /usr/lib/qt4/lib/libQtGui.so.4
#8  0xb63b8244 in QCoreApplicationPrivate::sendThroughApplicationEventFilters () from /usr/lib/qt4/lib/libQtCore.so.4
#9  0xb5c3e7a3 in QApplicationPrivate::notify_helper () from /usr/lib/qt4/lib/libQtGui.so.4
#10 0xb5c455e5 in QApplication::notify () from /usr/lib/qt4/lib/libQtGui.so.4
#11 0xb737b62d in KApplication::notify () from /home/mikolaj/kde/lib/libkdeui.so.5
#12 0xb63b8f91 in QCoreApplication::notifyInternal () from /usr/lib/qt4/lib/libQtCore.so.4
#13 0xb5c4697e in QApplicationPrivate::sendMouseEvent () from /usr/lib/qt4/lib/libQtGui.so.4
#14 0xb5ca3b3f in ?? () from /usr/lib/qt4/lib/libQtGui.so.4
#15 0x09b2ad40 in ?? ()
#16 0xbfe3a53c in ?? ()
#17 0x00000000 in ?? ()
Comment 13 Marcel Wiesweg 2008-12-13 20:26:08 UTC 
SVN commit 896546 by mwiesweg:

Operate with a copy of the metadata hub to avoid confusion
when the method is called recursively (from processEvents)

Note: Move metadata writing to threaded batch manager for after 0.10.0

CCBUG: 159855

 M  +12 -7     imagedescedittab.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=896546
Comment 14 Marcel Wiesweg 2008-12-13 20:30:17 UTC 
I am confident that the original bug is fixed with my commit.

Mikolaj, there is this crash you reported. I cannot reproduce it, can you? Anything special to do?
Comment 15 Mikolaj Machowski 2008-12-14 23:20:13 UTC 
Afraid I don't have good news:

Your patch have one - but IMO significant - side effect. After selecting images  and selecting tag in right panel it is applied only after removing of selection. This gives impression that changes weren't applied at all.

And still (rev. 896831, against 4.2) can reproduce crash:
a) Use right Tags panel for assigning
b) select many images and drag them to one of tags
c) quickly - to perform it when previous writing is going - select one image and drag it onto another tag, choose "apply" -> crash

Backtrace is a bit different:

Application: digiKam (digikam), signal SIGSEGV
 [?1034h[Thread debugging using libthread_db enabled]
[Current thread is 1 (Thread 0xb4bdb6d0 (LWP 18650))]

Thread 10 (Thread 0xb36adb90 (LWP 18652)):
#0  0xffffe430 in __kernel_vsyscall ()
#1  0xb635db95 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0
#2  0xb63bb0b2 in QWaitCondition::wait () from /usr/lib/qt4/lib/libQtCore.so.4
#3  0x08263ed9 in Digikam::ScanController::run ()
#4  0xb63ba320 in ?? () from /usr/lib/qt4/lib/libQtCore.so.4
#5  0x09f7a710 in ?? ()
#6  0x00000000 in ?? ()

Thread 9 (Thread 0xb2441b90 (LWP 18655)):
#0  0xffffe430 in __kernel_vsyscall ()
#1  0xb635db95 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0
#2  0xb63bb0b2 in QWaitCondition::wait () from /usr/lib/qt4/lib/libQtCore.so.4
#3  0xb779b622 in Digikam::LoadSaveThread::run () from /home/mikolaj/kde/lib/libdigikamcore.so.1
#4  0xb63ba320 in ?? () from /usr/lib/qt4/lib/libQtCore.so.4
#5  0x09f87d28 in ?? ()
#6  0x00000000 in ?? ()

Thread 8 (Thread 0xb2c42b90 (LWP 18656)):
#0  0xffffe430 in __kernel_vsyscall ()
#1  0xb635db95 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0
#2  0xb63bb0b2 in QWaitCondition::wait () from /usr/lib/qt4/lib/libQtCore.so.4
#3  0xb779b622 in Digikam::LoadSaveThread::run () from /home/mikolaj/kde/lib/libdigikamcore.so.1
#4  0xb63ba320 in ?? () from /usr/lib/qt4/lib/libQtCore.so.4
#5  0x0a06c820 in ?? ()
#6  0x00000000 in ?? ()

Thread 7 (Thread 0xb0083b90 (LWP 18745)):
#0  0xffffe430 in __kernel_vsyscall ()
#1  0xb635dec2 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0
#2  0xb045740b in metronom_sync_loop (this=0xa1c3f38) at metronom.c:871
#3  0xb635a315 in start_thread () from /lib/i686/libpthread.so.0
#4  0xb58f3dde in clone () from /lib/i686/libc.so.6

Thread 6 (Thread 0xaf41fb90 (LWP 18750)):
#0  0xffffe430 in __kernel_vsyscall ()
#1  0xb58ec101 in select () from /lib/i686/libc.so.6
#2  0xb0480435 in xine_usec_sleep (usec=0) at utils.c:457
#3  0xb0464d8b in video_out_loop (this_gen=0xa1c8780) at video_out.c:1246
#4  0xb635a315 in start_thread () from /lib/i686/libpthread.so.0
#5  0xb58f3dde in clone () from /lib/i686/libc.so.6

Thread 5 (Thread 0xaec1eb90 (LWP 18751)):
#0  0xb635cb46 in __pthread_mutex_unlock_usercnt () from /lib/i686/libpthread.so.0
#1  0xb5380474 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#2  0xb5380dc4 in ?? () from /usr/lib/libglib-2.0.so.0
#3  0xb53810a8 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#4  0xb64bb717 in QEventDispatcherGlib::processEvents () from /usr/lib/qt4/lib/libQtCore.so.4
#5  0xb64936fa in QEventLoop::processEvents () from /usr/lib/qt4/lib/libQtCore.so.4
#6  0xb64938ba in QEventLoop::exec () from /usr/lib/qt4/lib/libQtCore.so.4
#7  0xb63b74c3 in QThread::exec () from /usr/lib/qt4/lib/libQtCore.so.4
#8  0xb04a0879 in Phonon::Xine::XineThread::run () from /home/mikolaj/kde/lib/kde4/plugins/phonon_backend/phonon_xine.so
#9  0xb63ba320 in ?? () from /usr/lib/qt4/lib/libQtCore.so.4
#10 0x0a1c7b10 in ?? ()
#11 0x00000000 in ?? ()

Thread 4 (Thread 0xae41db90 (LWP 18807)):
#0  0xffffe430 in __kernel_vsyscall ()
#1  0xb58e9367 in poll () from /lib/i686/libc.so.6
#2  0xaf864e93 in ao_alsa_handle_event_thread (data=0xa5d88b8) at audio_alsa_out.c:150
#3  0xb635a315 in start_thread () from /lib/i686/libpthread.so.0
#4  0xb58f3dde in clone () from /lib/i686/libc.so.6

Thread 3 (Thread 0xadc1cb90 (LWP 18809)):
#0  0xffffe430 in __kernel_vsyscall ()
#1  0xb635db95 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0
#2  0xb0467980 in ao_loop (this_gen=0xa5ee1b0) at audio_out.c:345
#3  0xb635a315 in start_thread () from /lib/i686/libpthread.so.0
#4  0xb58f3dde in clone () from /lib/i686/libc.so.6

Thread 2 (Thread 0xad39fb90 (LWP 19106)):
#0  0xffffe430 in __kernel_vsyscall ()
#1  0xb635db95 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0
#2  0xb63bb0b2 in QWaitCondition::wait () from /usr/lib/qt4/lib/libQtCore.so.4
#3  0xb779b622 in Digikam::LoadSaveThread::run () from /home/mikolaj/kde/lib/libdigikamcore.so.1
#4  0xb63ba320 in ?? () from /usr/lib/qt4/lib/libQtCore.so.4
#5  0x0c1d7e70 in ?? ()
#6  0x00000000 in ?? ()

Thread 1 (Thread 0xb4bdb6d0 (LWP 18650)):
[KCrash Handler]
#6  0xb6493619 in QEventLoop::exit () from /usr/lib/qt4/lib/libQtCore.so.4
#7  0xb5c288b4 in QDragManager::eventFilter () from /usr/lib/qt4/lib/libQtGui.so.4
#8  0xb6494244 in QCoreApplicationPrivate::sendThroughApplicationEventFilters () from /usr/lib/qt4/lib/libQtCore.so.4
#9  0xb5bb37a3 in QApplicationPrivate::notify_helper () from /usr/lib/qt4/lib/libQtGui.so.4
#10 0xb5bba5e5 in QApplication::notify () from /usr/lib/qt4/lib/libQtGui.so.4
#11 0xb698585d in KApplication::notify () from /home/mikolaj/kde/lib/libkdeui.so.5
#12 0xb6494f91 in QCoreApplication::notifyInternal () from /usr/lib/qt4/lib/libQtCore.so.4
#13 0xb5bbb97e in QApplicationPrivate::sendMouseEvent () from /usr/lib/qt4/lib/libQtGui.so.4
#14 0xb5c18b3f in ?? () from /usr/lib/qt4/lib/libQtGui.so.4
#15 0x0cf5fec8 in ?? ()
#16 0xbff5565c in ?? ()
#17 0x00000000 in ?? ()
Comment 16 Marcel Wiesweg 2008-12-15 18:42:15 UTC 
I got the idea: Probably we should not allow making new drags while we still handle the previous drag (and calling processEvents). Can be solved with a timer / queued signal, will do this.

The other problem:
> After selecting images and selecting tag in right panel it is applied only 
> after removing of selection. This gives impression that changes weren't 
> applied at all.
I cannot reproduce this. Which right panel, tags filter or metadata edit? By removing selection you mean you have to click anywhere on the icon view to select another image and cause a repaint?
For me, either using the metadata edit panel or dragging to the tag filter view either way, the new tag appears immediately in the album icon view after the database operation is done.
Comment 17 Mikolaj Machowski 2008-12-15 21:10:17 UTC 
> > After selecting images and selecting tag in right panel it is applied
> > only after removing of selection. This gives impression that changes
> > weren't applied at all.
>
> I cannot reproduce this. Which right panel, tags filter or metadata
> edit? 

Tags filter.

> By removing selection you mean you have to click anywhere on the
> icon view to select another image and cause a repaint?

Yes.

> For me, either using the metadata edit panel or dragging to the tag
> filter view either way, the new tag appears immediately in the album
> icon view after the database operation is done.

For me not.
Comment 18 Marcel Wiesweg 2008-12-16 19:14:27 UTC 
SVN commit 897734 by mwiesweg:

When handling a drag event, calling processEvent() and thus allowing the user
to start a new drag can cause a crash.
In these cases, defer by emitting a queued signal.

Consolidate progress code.

CCBUG: 159855

 M  +29 -39    albumiconview.cpp  
 M  +8 -2      albumiconview.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=897734
Comment 19 Marcel Wiesweg 2008-12-16 19:14:33 UTC 
SVN commit 897735 by mwiesweg:

When handling a drag event, calling processEvent() and thus allowing the user
to start a new drag can cause a crash.
In these cases, defer by emitting a queued signal.

CCBUG: 159855

 M  +45 -30    digikam/tagfilterview.cpp  
 M  +5 -0      digikam/tagfilterview.h  
 M  +41 -25    digikam/tagfolderview.cpp  
 M  +5 -0      digikam/tagfolderview.h  
 M  +37 -26    libs/imageproperties/talbumlistview.cpp  
 M  +5 -0      libs/imageproperties/talbumlistview.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=897735
Comment 20 Mikolaj Machowski 2008-12-16 23:37:51 UTC 
1. Crash isn't reproducible anymore
2. When dragging files into Tag filter tab everything works perfectly
3. Still exists problem with deselection required to start tagging files when using Caption/Tags tab
Comment 21 Mikolaj Machowski 2008-12-16 23:38:40 UTC 
Downgrading severity of bug.
Comment 22 Marcel Wiesweg 2009-01-03 16:51:06 UTC 
Mikolaj, this one is left:
> Still exists problem with deselection required to start tagging files when
> using Caption/Tags tab

Are you sure that you pressed the apply button? Otherwise it is normal that you have to change selection to apply tags.
Comment 23 caulier.gilles 2009-01-23 21:29:08 UTC 
Lars,

What news in this file still valid using digiKam 0.10.0-rc1 ?

Gilles Caulier
Comment 24 caulier.gilles 2009-02-01 15:48:49 UTC 
Lars,

Without a fresh feedback, we will close this file. Please test and report using digiKam 0.10.0-rc1.

Thanks in advance

Gilles Caulier
Comment 25 caulier.gilles 2009-07-22 15:29:58 UTC 
Mik, 

Are you seen comment #22 from Marcel ?

Gilles Caulier
Comment 26 Andi Clemens 2009-10-08 01:14:19 UTC 
Any news here?
Comment 27 caulier.gilles 2009-10-08 08:28:14 UTC 
Please test with digiKam 1.0.0-beta5.

Gilles Caulier
Comment 28 caulier.gilles 2015-07-01 06:03:56 UTC 
New digiKam 4.11.0 is available :

https://www.digikam.org/node/740

Can you reproduce the problem with this release ?
Comment 29 caulier.gilles 2016-07-15 21:17:37 UTC 
With digiKam 5.0.0, this problem is not reproducible.
I close this file now. Don't hesitate to re-open if necessary.
Gilles Caulier