Bug 232054 - Dolphin often hangs since the KMetaData merge
Summary: Dolphin often hangs since the KMetaData merge
Status: RESOLVED FIXED
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: 16.12.2
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Peter Penz
URL:
Keywords:
: 233838 240939 246020 249990 250030 250036 250165 250293 250295 252342 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-03-25 01:26 UTC by Christoph Feck
Modified: 2010-10-08 14:59 UTC (History)
29 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.5.1


Attachments
backtrace while it hung (7.53 KB, text/plain)
2010-03-29 05:50 UTC, Christoph Feck
Details
another backtrace while it hung (6.49 KB, text/plain)
2010-04-11 16:30 UTC, Christoph Feck
Details
Make MpegAnalyzer respect the max stream read size (6.86 KB, patch)
2010-07-28 16:20 UTC, Sebastian Trueg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Feck 2010-03-25 01:26:08 UTC
Version:           1.4 (using 4.4.69 (KDE 4.4.69 (KDE 4.5 >= 20100324)), compiled sources)
Compiler:          gcc
OS:                Linux (i686) release 2.6.31.12-0.2-desktop

Since the KMetaData merge in the recent days, I experience great hangs/lags when using Dolphin, sometimes when just hovering a file, sometimes when clicking on a file. These hangs have a duration of several seconds, probably more than 10 seconds, after that time Dolphin continues working normally, until the next hang starts. This is even when I am in a folder with no large Videos or other large files.

I have the Information Panel open, and have KDE compiled with full Nepomuk support, but have Nepomuk services and Strigi indexing disabled.

The issue cannot reproduced, but happens frequently.
Comment 1 Peter Penz 2010-03-25 07:44:32 UTC
Strange... I had to introduce a QThread::wait(), when the KFileMetaDataWidget gets destroyed, but this should not be executed in combination with the Information Panel (only when closing Dolphin).

Do you have tooltips enabled in your environment? Because of the wait() I've to adjust the Dolphin code slightly.

I'll do some tests next week, by temporary adding a very expensive, blocking loop in the KLoadFileMetaDataThread. Even in this case Dolphin may never hang...
Comment 2 Christoph Feck 2010-03-25 13:02:32 UTC
Neither tooltips nor the "Preview" image on the Information panel is enabled. I use the Information Panel only to display additional Meta Data.
Comment 3 Christoph Feck 2010-03-29 05:50:55 UTC
Created attachment 42332 [details]
backtrace while it hung

I catched a backtrace while it hung when I clicked on a small image (2K file size) to view it. While this backtrace indicates a DBus hang when called from KToolInvokation, I also see the same hangs when just hovering over icons, but not reproducable. I am sure it is DBus related also, as the 15 sec timeout seems to resolve the lock.
Comment 4 Peter Penz 2010-03-29 11:15:49 UTC
Thanks Christoph for the update! I also did some investigations in the meantime. After doing some minor fixes in KFileMetaDataWidget & related classes I locally added an expensive loop in the KLoadFileMetaDataThread, which blocks the thread for around 7 seconds and results in 100 % CPU load. After this I turned on tooltips and the Information Panel to check, whether there is a thread related blocking of the Dolphin UI. Result after a few days of testing: No blocking of the user interface is done by the KFileMetaDataWidget thread code. Of course everything gets slower because of the 100 % CPU load, but no blocking is done. So I hope, that the recent locks are not directly related to the KFileMetaWidget code... If you plan to turn on tooltips, please update kdelibs + Dolphin in parallel, as quite some fixes have been done there.

But I also faced some locks on trunk, which sometimes where not view-related at all. E. g. when opening the Dolphin preferences recently, the UI was blocked for around 10 seconds - very strange... I'll leave my "blocking code" there locally and will try to get a backtrace too if the next lock occurs.
Comment 5 Christoph Feck 2010-04-11 16:30:04 UTC
Created attachment 42686 [details]
another backtrace while it hung

This backtrace does not involve KRun, it apparently hung while receiving a timer event during normal browsing.
Comment 6 Peter Penz 2010-04-28 20:43:21 UTC
SVN commit 1120270 by ppenz:

Tag related fixes:
- Restore click-on-tags functionality
- Assure that the tags-widget state gets applied to the resources

General fixes:
- Don't start a massupdate-job if an internal data change has been done (this might be the root cause of bug #232054)
- Don't invoke ResourceManager::init() in the context of the load-meta-data thread

CCBUG: 232054
CCMAIL: frank78ac@googlemail.com

 M  +43 -26    kfilemetadataprovider.cpp  
 M  +1 -1      kfilemetadataprovider_p.h  
 M  +12 -0     kfilemetadatawidget.cpp  
 M  +2 -0      kfilemetadatawidget.h  
 M  +1 -2      kloadfilemetadatathread.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1120270
Comment 7 Christoph Feck 2010-04-28 23:22:59 UTC
Thanks for the update, Peter. Unfortunately, with kdelibs r1120299, kdebase r1120300, the D-Bus hangs still happen.
Comment 8 Wilco 2010-05-24 10:00:14 UTC
Same problem here on Arch Linux, using KDE 4.4.3
Comment 9 Christoph Feck 2010-06-07 13:12:53 UTC
*** Bug 240939 has been marked as a duplicate of this bug. ***
Comment 10 Clemens Eisserer 2010-06-07 13:35:22 UTC
Still in 4.4.80
Comment 11 Peter Penz 2010-06-07 14:05:26 UTC
http://randomguy3.wordpress.com/2010/06/01/d-bus-threading-issues/ has some infos about this issue
Comment 12 Christoph Feck 2010-06-11 02:52:12 UTC
I just downloaded D-Bus packages which are supposed to be build with the patch mentioned in comment #11, restarted the session, and I still experience the 15 second hangs when browsing and clicking on files.

As far as I understand, the patch should only fix thread-related crashes with Soprano, but I have Strigi and Nepomuk disabled.
Comment 13 Peter Penz 2010-06-11 08:22:12 UTC
Thanks Christoph for testing the D-Bus related issues!

> As far as I understand, the patch should only fix thread-related
> crashes with Soprano, but I have Strigi and Nepomuk disabled.

In KDE 4.5 Dolphin also gets the meta data for files, if Strigi (to be more precise: the Strigi indexer) and Nepomuk are disabled. This is done by using KFileMetaInfo in a separate thread. KFileMetaInfo uses Strigi internally (only the indexer got disabled) and my guess is, that Strigi might be affected too.

However looking at the backtraces, the issue seems to be not related to Strigi/Nepomuk at all. Does disabling tooltips and the Information Panel in Dolphin "fix" the 15 second hangs? If this is the case, then this issue is not related to the KFileMetaData classes...

I've set Sebastian Trüg to CC, as is more familiar with this issue.
Comment 14 Clemens Eisserer 2010-06-12 17:03:51 UTC
just have experienced it with 4.5-Beta2
Comment 15 Clemens Eisserer 2010-06-28 19:55:07 UTC
still in 4.4.90
Comment 16 Peter Penz 2010-06-28 22:24:05 UTC
*** Bug 243077 has been marked as a duplicate of this bug. ***
Comment 17 Christoph Feck 2010-06-28 22:38:51 UTC
Peter, bug 243077 is not a duplicate. During the hangs I experience, Dolphin does not use the CPU, it just waits for the D-Bus timeouts.
Comment 18 Peter Penz 2010-06-29 09:12:24 UTC
Thanks Christoph, I've adjusted the state of bug 243077 to NEW now. In this case bug 243077 might be a Strigi issue...
Comment 19 Giovanni M. 2010-06-29 10:21:09 UTC
maybe is the same, investigating the 100% CPU I see that almost is IOWait and, thanks to the kde forum guys, with iotop I can see   
 TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND             
 4675 be/4  gio      87.03 M/s  0.00 B/s  ?unavailable?       dolphin -icon system-file-manager -caption Dolphin

and the time that the access to the disk seems to be the same for reading all the 1GB file (the video file that mouse overing; about 12 sec with 1.1GB file, so with 90.00 M/s average in 12 seconds he reads 1.1 GB, the file size). The issue becomes dramatic when you mouse over more than one big file, because the IO is duplicated, triplicated and so on.  I notice that if I wait the IO reading, the second time I mouse over the file there isn't IO read anymore and the system remains stable. Strigi is disabled.
Comment 20 Peter Penz 2010-06-29 10:50:28 UTC
@Giovanni: Thanks for the update! Disabling strigi in the system settings only disables the "strigi indexer", when reading meta data kdelibs internally still uses the Strigi API. My guess is that the root cause is this: http://sourceforge.net/tracker/?func=detail&aid=2830904&group_id=171000&atid=856302 The fix should not be too tricky, but I did not have the time yet to investigate into this issue :-(
Comment 21 Cédric Bellegarde 2010-07-17 14:32:24 UTC
Same bug here with kde 4.5 rc2...

Dolphin hangs when single clicking on images/videos/...

ArchLinux.
Comment 22 Cédric Bellegarde 2010-07-26 17:41:00 UTC
Same with kde 4.5 rc3...

Really annoying bug... Dolphin became unusable...
Comment 23 Clemens Eisserer 2010-07-26 19:08:58 UTC
This should be marked as BLOCKER.

4.5 was defintivly the last cycles I did beta-testing for, there are already enough testers but bugs rot their way into releases regulary.
Comment 24 Marc Payne 2010-07-28 02:23:12 UTC
I am able to consistently reproduce this bug in 4.4.95 by either mousing over several documents to generate a preview in the Information panel, or by right-clicking a file and choosing Properties. Dolphin will freeze for about 15-20 seconds, then continue on, or crash. This behavior only occurs with the Information panel open. When it is closed, Dolphin seems stable.

Unfortunately, I can't provide any useful backtraces, so I am not much help.
Comment 25 Tomasz Czapiewski 2010-07-28 10:56:32 UTC
I'm having the same problem with Gwenview and opening JPG files on KDE 4.4.92 (4.5RC2) - it like one for few files freezes Gwenview for at least 10 seconds then it gets back to normal for another few files. I don't use Dolphin only occasionally so I haven't checked the problem there.

I'm getting the log output from Gwenview:
gwenview(10439) Gwenview::SemanticInfoDirModel::setData: Semantic info cache for KUrl("file:///media/disk-1/Zdjecia-2010_07_21/CZERWIEC 2010/S6303089.JPG") is invalid 
QPainter::begin: Paint device returned engine == 0, type: 2
QPainter::begin: Paint device returned engine == 0, type: 2

gwenview(10439) Gwenview::SemanticInfoDirModel::setData: Semantic info cache for KUrl("file:///media/disk-1/Zdjecia-2010_07_21/CZERWIEC 2010/S6303056.JPG") is invalid 
gwenview(10439) Gwenview::SemanticInfoDirModel::setData: Semantic info cache for KUrl("file:///media/disk-1/Zdjecia-2010_07_21/CZERWIEC 2010/S6303055.JPG") is invalid
...

I have Nepomuk and Strigi enabled but these files are on external USB disk (which condition is good, it's not read error or sth).
Comment 26 jeffrey.scherling 2010-07-28 11:45:40 UTC
Program received signal SIGSEGV, Segmentation fault.
0x00007fffecb65939 in ?? () from /usr/lib64/libdbus-1.so.3
(gdb) bt
#0  0x00007fffecb65939 in ?? () from /usr/lib64/libdbus-1.so.3
#1  0x00007fffecb46add in ?? () from /usr/lib64/libdbus-1.so.3
#2  0x00007fffecb5845d in ?? () from /usr/lib64/libdbus-1.so.3
#3  0x00007fffecb4a49e in ?? () from /usr/lib64/libdbus-1.so.3
#4  0x00007ffff45ab8e3 in ?? () from /usr/lib64/qt/lib/libQtDBus.so.4
#5  0x00007ffff4288953 in QObject::event(QEvent*) () from /usr/lib64/qt/lib/libQtCore.so.4
#6  0x00007ffff511d79c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/qt/lib/libQtGui.so.4
#7  0x00007ffff5123c8b in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/qt/lib/libQtGui.so.4
#8  0x00007ffff5e45086 in KApplication::notify(QObject*, QEvent*) () from /usr/lib64/libkdeui.so.5
#9  0x00007ffff4278f0c in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib64/qt/lib/libQtCore.so.4
#10 0x00007ffff42a5c82 in ?? () from /usr/lib64/qt/lib/libQtCore.so.4
#11 0x00007ffff42a27f8 in ?? () from /usr/lib64/qt/lib/libQtCore.so.4
#12 0x00007fffef554f9e in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#13 0x00007fffef558958 in ?? () from /usr/lib64/libglib-2.0.so.0
#14 0x00007fffef558a80 in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#15 0x00007ffff42a24c3 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/qt/lib/libQtCore.so.4
#16 0x00007ffff51cc6ce in ?? () from /usr/lib64/qt/lib/libQtGui.so.4
#17 0x00007ffff4277832 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/qt/lib/libQtCore.so.4
#18 0x00007ffff4277c0c in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/qt/lib/libQtCore.so.4
#19 0x00007ffff427c89b in QCoreApplication::exec() () from /usr/lib64/qt/lib/libQtCore.so.4
#20 0x00007ffff7b8b98f in kdemain () from /usr/lib64/libkdeinit4_dolphin.so
#21 0x00007ffff29e2b6d in __libc_start_main () from /lib64/libc.so.6
#22 0x0000000000400789 in _start ()
(gdb)
Comment 27 jeffrey.scherling 2010-07-28 11:48:10 UTC
(In reply to comment #26)
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007fffecb65939 in ?? () from /usr/lib64/libdbus-1.so.3
> (gdb) bt
> #0  0x00007fffecb65939 in ?? () from /usr/lib64/libdbus-1.so.3
> #1  0x00007fffecb46add in ?? () from /usr/lib64/libdbus-1.so.3
> #2  0x00007fffecb5845d in ?? () from /usr/lib64/libdbus-1.so.3
> #3  0x00007fffecb4a49e in ?? () from /usr/lib64/libdbus-1.so.3
> #4  0x00007ffff45ab8e3 in ?? () from /usr/lib64/qt/lib/libQtDBus.so.4
> #5  0x00007ffff4288953 in QObject::event(QEvent*) () from
> /usr/lib64/qt/lib/libQtCore.so.4
> #6  0x00007ffff511d79c in QApplicationPrivate::notify_helper(QObject*, QEvent*)
> () from /usr/lib64/qt/lib/libQtGui.so.4
> #7  0x00007ffff5123c8b in QApplication::notify(QObject*, QEvent*) () from
> /usr/lib64/qt/lib/libQtGui.so.4
> #8  0x00007ffff5e45086 in KApplication::notify(QObject*, QEvent*) () from
> /usr/lib64/libkdeui.so.5
> #9  0x00007ffff4278f0c in QCoreApplication::notifyInternal(QObject*, QEvent*)
> () from /usr/lib64/qt/lib/libQtCore.so.4
> #10 0x00007ffff42a5c82 in ?? () from /usr/lib64/qt/lib/libQtCore.so.4
> #11 0x00007ffff42a27f8 in ?? () from /usr/lib64/qt/lib/libQtCore.so.4
> #12 0x00007fffef554f9e in g_main_context_dispatch () from
> /usr/lib64/libglib-2.0.so.0
> #13 0x00007fffef558958 in ?? () from /usr/lib64/libglib-2.0.so.0
> #14 0x00007fffef558a80 in g_main_context_iteration () from
> /usr/lib64/libglib-2.0.so.0
> #15 0x00007ffff42a24c3 in
> QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
> from /usr/lib64/qt/lib/libQtCore.so.4
> #16 0x00007ffff51cc6ce in ?? () from /usr/lib64/qt/lib/libQtGui.so.4
> #17 0x00007ffff4277832 in
> QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from
> /usr/lib64/qt/lib/libQtCore.so.4
> #18 0x00007ffff4277c0c in
> QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from
> /usr/lib64/qt/lib/libQtCore.so.4
> #19 0x00007ffff427c89b in QCoreApplication::exec() () from
> /usr/lib64/qt/lib/libQtCore.so.4
> #20 0x00007ffff7b8b98f in kdemain () from /usr/lib64/libkdeinit4_dolphin.so
> #21 0x00007ffff29e2b6d in __libc_start_main () from /lib64/libc.so.6
> #22 0x0000000000400789 in _start ()
> (gdb)

in kde 4.5. RC3 Dolphin 1.5, i want delete a folder with shift+del
Comment 28 Clemens Eisserer 2010-07-28 12:15:29 UTC
Jeffrey: I don't think this is related to this issue. Please search for another appropriate bug-report or open a new one.
Comment 29 Amine Roukh 2010-07-28 13:56:56 UTC
Same issue here, but closing the information panel solve the problem temporary, just like Marc.
Comment 30 Sebastian Trueg 2010-07-28 16:20:07 UTC
Created attachment 49586 [details]
Make MpegAnalyzer respect the max stream read size

This patch applies to strigi svn trunk in kde's kdesupport module. It would help a lot if one of you could test if it solves your problems with video files.
Comment 31 Peter Penz 2010-07-28 17:16:10 UTC
@Sebastian: Thanks a lot for the patch, I owe you a beer the next time we meet (hopefully soon at a Nepomuk workshop?). I've less time during the next days to test the patch, but can do this at the weekend (of course it would be great, if somebody else could verify this also before ;-)) I hope I'll find some time to fix some related Strigi crashes too: As Dolphin now uses KFileMetaInfo as fallback when Nepomuk is disabled, those Strigi issues (that have been there always) popup up a lot more frequently now...
Comment 32 Panagiotis Papadopoulos 2010-07-28 18:57:20 UTC
*** Bug 246020 has been marked as a duplicate of this bug. ***
Comment 33 Panagiotis Papadopoulos 2010-07-28 19:40:10 UTC
as you can read in https://bugs.kde.org/show_bug.cgi?id=246020 I’m affected by this bug too…
Btw: I do not have Nepomuk nor Strigi activated. Both are disabled in the systemsettings.
Comment 34 Sebastian Trueg 2010-07-29 12:07:05 UTC
@Panagiotis: this has nothing to do with Nepomuk or its strigi integration. This is Dolphin's own strigi integration which you cannot disable. But we now have a way to fix it and if all goes well that fix will be in 4.5.1.
Comment 35 Clemens Eisserer 2010-07-29 12:23:05 UTC
So all the 4.5 users will have to work with Dolphin freezing every now and then for 10-20s until 4.5.1 comes out?

Its just a personal opinion, but KDE's beta/rc stages are way too short.
Do you think Microsoft would ship windows with one of its core-componnets broken like this? Well, they also take more than 2 month for stabilization.
Comment 36 Cédric Bellegarde 2010-07-29 12:51:19 UTC
>This behavior only occurs with the
>Information panel open. When it is closed, Dolphin seems stable.

I don't use "Information panel" and dolphin freeze/crash...

But at work, i can't reproduce this bug :(
Comment 37 Peter Penz 2010-07-29 13:02:58 UTC
A short update, as in the meantime 3 different issues are reported here:

- There is an issue in libdbus, that is one root cause for the freeze in
Dolphin and also other applications (see
https://bugs.freedesktop.org/show_bug.cgi?id=17754). The issue is fixed already
and I hope that the packagers will provide an updated package, as the whole KDE
SC is affected by this, not only Dolphin. In Dolphin the issue gets triggered
more often in KDE SC 4.5, as Dolphin asynchronously fetches meta data also for
non-indexed files as soon as tooltips are enabled or the Information Panel is
enabled.

- Dolphin uses KFileMetaInfo from kdelibs to retrieve meta data of non-indexed
files (= if Nepomuk and Strigi are turned off). A limit of 64 KB is set in
KFileMetaInfo, so that all meta information analyzers never read more than 64
KB of a file to get the meta information. However there are some analyzers,
that don't respect this size limit, which of course gets problematic for a 2 GB
video file. In this case the UI of Dolphin should not completely freeze, as the
analyzes is done asynchronously. But I observed that some of the analyzers go
completely mad and decrease the performance of the whole system until it feels
like frozen. The analyzers are part of Strigi (they are used also by
KFileMetaInfo if Strigi is turned off, as turning off Strigi only turns off the
indexing functionality of Strigi). I'm not very familiar with the Strigi code
yet, but I'll try to fix those issues with a high priority.

- Dolphin will crash if a Strigi analyzer crashes. Similar like before: The
analyzer must be fixed.

I'm very unhappy with the current situation, as of course Dolphin will get
blamed for this. But from looking at the bug reports, most of the freezes are
related to the libdbus issue and I hope that the recent fix there will improve
the situation.
Comment 38 Peter Penz 2010-07-29 13:04:00 UTC
@Bellegarde:
> I don't use "Information panel" and dolphin freeze/crash...

Did you enable tooltips? If turning off tooltips does not help, then this should be a completely different issue.
Comment 39 Peter Penz 2010-07-30 17:42:02 UTC
*** Bug 246136 has been marked as a duplicate of this bug. ***
Comment 40 Vishesh Handa 2010-08-01 21:40:20 UTC
The DBus issues are a major pain.

I've tested Sebastian's patch. It stops the crashes on my system.

There are a couple of issues with KLoadFileMetadataThread. I'll email you ( Peter & Trueg ) about them. I think I might even be able to patch them up.
Comment 41 Clemens Eisserer 2010-08-01 21:53:37 UTC
Would it be possible to delay KDE-4.5 until this issue is solved?
Its really a huge problem with crashes and hangs, kde-4.5.0 shouldn't be shipped broken like that.
Comment 42 Sebastian Trueg 2010-08-02 15:15:26 UTC
SVN commit 1158299 by trueg:

Make sure we never let libstreamanalyzer (Strigi) read more than 64k in quick analysis mode.
This is necessary since many Strigi plugins simply ignore the config.
While at it I started cleaning up the whole KFileMetaInfo code. Classes were scattered over
different files, KDE style guides were not followed, things were unnecessarily complicated.
This is only the first step mainly to make the Dolphin freeze go away. Next steps include
replacing PredicateProperties. It was never implemented and is not necessary now since we have
Nepomuk::Types::Property. Whatever features PredicateProperties wanted to expose at some point
in time (as I said: nothing besides the name is implemented) we should rather do that in
Nepomuk::Types::Property.

BUG: 232054
FIXED-IN: 4.5.1

 M  +157 -83   kfilemetainfo.cpp  
 M  +2 -2      kfilemetainfo.h  
 D             kfilemetainfo_p.h  
 M  +24 -24    kfilemetainfoitem.cpp  
 M  +8 -5      kfilemetainfoitem.h  
 A             kfilemetainfoitem_p.h   kfilemetainfo_p.h#1158298 [License: LGPL (v2+)]
 M  +3 -1      kfilewriteplugin.cpp  
 A             kfilewriteplugin_p.h   [License: LGPL (v2+)]
 M  +16 -56    predicateproperties.cpp  
 M  +4 -2      predicateproperties.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1158299
Comment 43 Stefan Fleckenstein 2010-08-02 17:49:51 UTC
I agree with Clemens Eisserer: Shipping KDE 4.5.0 with an unstable filemanager is not a good idea, IMHO it is a showstopper. Tagging for 4.5.0 seems not to be finished, can this fix be included there as well?
Comment 44 Tomasz Czapiewski 2010-08-03 07:21:27 UTC
I agree with Clemens Eisserer and Stefan Fleckenstein, too. It should be considered as showstopper for 4.5.0. Many KDE users will upgrade from 4.4.x to 4.5.0 expecting stable and polished desktop and can be frustrated about this bug.
Comment 45 Luca Tomat 2010-08-04 11:22:11 UTC
I agree with Clemens Eisserer, Stefan Fleckenstein and Tomasz Czapiewski. This problem should be fixed in 4.5.0
This version of KDE is very stable and good, unfortunately this bug affects an important desktop component making it very little usable. Releasing KDE 4.5 with this bug would give a bad taste to the user making it seem unstable and broken. Should we pay this price just to respect a planned releasing date?
Comment 46 Frank Reininghaus 2010-08-04 18:05:32 UTC
We've notified the release team and the kde-packager mailing list to make sure that the patches find their way into the distributions' 4.5.0 packages.

But there was a recent decision to delay the 4.5.0 release anyway, see

http://mail.kde.org/pipermail/release-team/2010-August/004050.html
Comment 47 Tomasz Czapiewski 2010-08-05 08:49:40 UTC
I'd like to thank you for delaying KDE 4.5 release for getting fixes for these bugs to 4.5.
Comment 48 Christoph Feck 2010-08-05 10:43:16 UTC
I do not have time right now to compile trunk to test the new version, so I cannot confirm if the changes fix the hangs. Can someone that could reproduce them confirm? What if the user still has the unpatched D-Bus version? From just looking at the patch, it only enforces a file size limit.
Comment 49 Christoph Feck 2010-08-07 12:00:16 UTC
Are there any patches applied to 4.5 branch that are not in trunk? Because with todays trunk (kdelibs 1160128, kdebase 1160144) I still got the hang twice in a short time. Once when clicking on an image (about 100K in size), once when clicking on a folder. I have to disable information panel again :(
Comment 50 Christoph Feck 2010-08-08 17:02:44 UTC
Reenabled the Information Panel after a fresh compilation/installation of trunk (kdelibs r1160350, kdebase r1160534), and the hangs are still there. So far I got them when
- right clicking on a folder
- clicking on a small text file to drag it
- by hovering over a small .diff file

Reopening the bug until someone clarifies if there are fixes in 4.5 branch which are not forward ported to trunk.
Comment 51 Christoph Feck 2010-08-08 17:03:51 UTC
Adding blocker keyword, as requested by multiple commenters.
Comment 52 Peter Penz 2010-08-08 21:56:09 UTC
@Christoph: I can confirm that all related fixes to this issue from the 4.5 branch also have been ported to trunk. As mentioned in comment #37 the dbus-related hangs require a recent version of libdbus. Can somebody else still reproduce hangs with a recent trunk version or the tagged 4.5.0 version? I did a lot of tests during the last days and also have run a test program which opens several instances of KFileMetaDataWidget in parallel for verification, but everything runs fine here.
Comment 53 Dirk Mueller 2010-08-10 10:59:39 UTC
as it seems unconfirmed (comment #52), ignoring the 4.5.0 release blocker. please investigate/fix for 4.5.1
Comment 54 Salvatore 2010-08-10 11:51:21 UTC
Kde 4.5 (from repository) - Opensuse 11.3
libDBus 1.3.2 (from repository)

In my system, this bug seems resolved.

Thanks
Comment 55 Christoph Feck 2010-08-11 00:47:24 UTC
I updated to D-Bus 1.3.2 and it worked without a freeze so far. Either the patches for D-Bus 1.2.24 mentioned in comment #11 were not sufficient alone, or were not really part of the packages that were advertised/created for this purpose. Sorry for the confusion and thanks for all the dolphins.

(On a side note, the official pages say that 1.3.x are unstable D-Bus versions, and users should use 1.2.24 instead. How ironic.)
Comment 56 Peter Penz 2010-08-11 08:42:02 UTC
*** Bug 233838 has been marked as a duplicate of this bug. ***
Comment 57 Clemens Eisserer 2010-08-31 12:14:27 UTC
so people need an unstable dbus version in order to get a working file manager?
Comment 58 Christoph Feck 2010-09-03 12:49:24 UTC
*** Bug 249990 has been marked as a duplicate of this bug. ***
Comment 59 Peter Penz 2010-09-03 16:29:43 UTC
*** Bug 250030 has been marked as a duplicate of this bug. ***
Comment 60 Peter Penz 2010-09-03 16:48:37 UTC
*** Bug 250036 has been marked as a duplicate of this bug. ***
Comment 61 Peter Penz 2010-09-04 15:23:11 UTC
*** Bug 250165 has been marked as a duplicate of this bug. ***
Comment 62 Peter Penz 2010-09-05 20:17:52 UTC
*** Bug 250293 has been marked as a duplicate of this bug. ***
Comment 63 Peter Penz 2010-09-05 20:17:58 UTC
*** Bug 250295 has been marked as a duplicate of this bug. ***
Comment 64 Frank Reininghaus 2010-09-25 23:41:08 UTC
*** Bug 252342 has been marked as a duplicate of this bug. ***
Comment 65 Clemens Eisserer 2010-09-27 15:43:12 UTC
I still experience those hangs - even after updating to libdbus-1.4.0 :/
Comment 66 nucleo 2010-09-27 15:46:30 UTC
(In reply to comment #65)
> I still experience those hangs - even after updating to libdbus-1.4.0 :/

I am noticed too that dolphin hangs with dbus 1.3.1 but not so often.
Comment 67 Weng Xuetian 2010-09-27 15:50:11 UTC
Not happened to me though, I'm using 1.4.0.

Actually the dbus bug seems fixed after 1.3.1, so it maybe normal as you are using 1.3.1.
Comment 68 Clemens Eisserer 2010-09-27 16:01:58 UTC
As I said, I still see this bug with dbus-1.4.0!
It is now a lot better than it has been with 1.2.?, but its still annoying to have dolphin/plasma freeze from time to time for ~20s.
Comment 69 ultr 2010-09-27 16:23:32 UTC
Installing libdbus 1.4.0 solved issues with Konqueror for me.
I have not experienced any similar problems with Dolphin as well, though I rarely use it.

Debian testing, KDE 4.5.1 from external repository, libdbus 1.4.0 from Debian's experimental.

Also I have Nepomuk disabled in SystemSettings.