Version: unknown (using 4.3.00 (KDE 4.3.0), Arch Linux) Compiler: gcc OS: Linux (x86_64) release 2.6.30-ARCH Using 4.3.0 from the repos of Arch Linux. On normal operation, sometimes krunner (tack view) is opened but when I hit enter to run the app/tool/etc. It freezes for about 30s which is annoying. It is a complete freeze. I haven't been able to find a sequence to reproduce it. It happens randomly.
about 30s sounds quite close to 25s, which is the default dbus timeout.
can you reproduce using a recent version of kde? thanks
I still have the same/a similar bug in kde: 4.3.90 (KDE 4.3.90 (KDE 4.4 RC1)) qt: 4.6.0 distro: kubuntu 9.10 (with ppa's not default kde) arch: x86_64 gfx-card:radeon (using oss driver) [ATI Technologies Inc RS482 [Radeon Xpress 200M]] linux: 2.6.32(.0) xorg: 7.4+3ubuntu10 xorg: 1.6.5+git20091107+server-1.6-branch.2dbcb06a-0ubuntu0sarvatt~karmic I get pretty much the same problem, the krunner dialog disapears but the program does not start for 20/30 seconds. I'm also suffering from the possibly related https://bugs.kde.org/show_bug.cgi?id=170032
Happens for me with latest KDE SVN. Think it may have something to do with Qt 4.6, although it only seems to happen with KRunner. Note that libdbus hasn't been changed since before this started happening. Backtrace at freeze time: Thread 6 (Thread 0x7f0912be1710 (LWP 5984)): [threadweaver waiting for jobs] Thread 5 (Thread 0x7f090bfff710 (LWP 5985)): [threadweaver waiting for jobs] Thread 4 (Thread 0x7f090b7fe710 (LWP 5986)): [threadweaver waiting for jobs] Thread 3 (Thread 0x7f090affd710 (LWP 5987)): [threadweaver waiting for jobs] Thread 2 (Thread 0x7f090a608710 (LWP 7079)): #0 0x00007f092da98503 in select () from /lib/libc.so.6 #1 0x00007f092fe0e2f3 in QProcessManager::run (this=0x7f093018a7a0) at /home/kde-devel/src/qt/src/corelib/io/qprocess_unix.cpp:245 #2 0x00007f092fd267f0 in QThreadPrivate::start (arg=0x7f093018a7a0) at /home/kde-devel/src/qt/src/corelib/thread/qthread_unix.cpp:248 #3 0x00007f092fa7a81a in start_thread () from /lib/libpthread.so.0 #4 0x00007f092da9ec7d in clone () from /lib/libc.so.6 #5 0x0000000000000000 in ?? () Thread 1 (Thread 0x7f093571c780 (LWP 5365)): #0 0x00007f092fa7f07c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007f092704e900 in _dbus_pthread_condvar_wait () from /usr/lib/libdbus-1.so.3 #2 0x00007f092703268d in _dbus_connection_acquire_io_path () from /usr/lib/libdbus-1.so.3 #3 0x00007f0927034019 in _dbus_connection_handle_watch () from /usr/lib/libdbus-1.so.3 #4 0x00007f0927048bfa in dbus_watch_handle () from /usr/lib/libdbus-1.so.3 #5 0x00007f09301a75bf in q_dbus_watch_handle (watch=0x233ac70, flags=1) at /home/kde-devel/src/qt/src/dbus/qdbus_symbols_p.h:181 #6 0x00007f09301ac731 in QDBusConnectionPrivate::socketRead (this=0x233a1e0, fd=5) at /home/kde-devel/src/qt/src/dbus/qdbusintegrator.cpp:1097 #7 0x00007f09301ec0e5 in QDBusConnectionPrivate::qt_metacall (this=0x233a1e0, _c=QMetaObject::InvokeMetaMethod, _id=4, _a=0x7fff81f8d670) at .moc/debug-shared/moc_qdbusconnection_p.cpp:99 #8 0x00007f092fe3add5 in QMetaObject::metacall (object=0x233a1e0, cl=QMetaObject::InvokeMetaMethod, idx=8, argv=0x7fff81f8d670) at /home/kde-devel/src/qt/src/corelib/kernel/qmetaobject.cpp:237 #9 0x00007f092fe4e7a3 in QMetaObject::activate (sender=0x2874de0, m=0x7f0930184c40, local_signal_index=0, argv=0x7fff81f8d670) at /home/kde-devel/src/qt/src/corelib/kernel/qobject.cpp:3264 #10 0x00007f092fea8e9a in QSocketNotifier::activated (this=0x2874de0, _t1=5) at .moc/debug-shared/moc_qsocketnotifier.cpp:89 #11 0x00007f092fe56b73 in QSocketNotifier::event (this=0x2874de0, e=0x7fff81f8df80) at /home/kde-devel/src/qt/src/corelib/kernel/qsocketnotifier.cpp:317 #12 0x00007f0930b31bea in QApplicationPrivate::notify_helper (this=0x234e9d0, receiver=0x2874de0, e=0x7fff81f8df80) at /home/kde-devel/src/qt/src/gui/kernel/qapplication.cpp:4297 #13 0x00007f0930b2f242 in QApplication::notify (this=0x2342640, receiver=0x2874de0, e=0x7fff81f8df80) at /home/kde-devel/src/qt/src/gui/kernel/qapplication.cpp:3701 #14 0x00007f0931c8f487 in KApplication::notify (this=0x2342640, receiver=0x2874de0, event=0x7fff81f8df80) at /home/kde-devel/src/KDE/kdelibs/kdeui/kernel/kapplication.cpp:302 #15 0x00007f092fe33b55 in QCoreApplication::notifyInternal (this=0x2342640, receiver=0x2874de0, event=0x7fff81f8df80) at /home/kde-devel/src/qt/src/corelib/kernel/qcoreapplication.cpp:704 #16 0x00007f0933bcdea9 in QCoreApplication::sendEvent(QObject*, QEvent*) () from /home/kde-devel/qt/lib/libQtWebKit.so.4 #17 0x00007f092fe6857b in socketNotifierSourceDispatch (source=0x2353a10) at /home/kde-devel/src/qt/src/corelib/kernel/qeventdispatcher_glib.cpp:110 #18 0x00007f092a40326e in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #19 0x00007f092a406c28 in g_main_context_iterate () from /usr/lib/libglib-2.0.so.0 #20 0x00007f092a406d50 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #21 0x00007f092fe69a8d in QEventDispatcherGlib::processEvents (this=0x22f9f80, flags=...) at /home/kde-devel/src/qt/src/corelib/kernel/qeventdispatcher_glib.cpp:412 #22 0x00007f0930c00c84 in QGuiEventDispatcherGlib::processEvents (this=0x22f9f80, flags=...) at /home/kde-devel/src/qt/src/gui/kernel/qguieventdispatcher_glib.cpp:204 #23 0x00007f092fe31370 in QEventLoop::processEvents (this=0x7fff81f8e290, flags=...) at /home/kde-devel/src/qt/src/corelib/kernel/qeventloop.cpp:149 #24 0x00007f092fe314c4 in QEventLoop::exec (this=0x7fff81f8e290, flags=...) at /home/kde-devel/src/qt/src/corelib/kernel/qeventloop.cpp:197 #25 0x00007f092fe3421a in QCoreApplication::exec () at /home/kde-devel/src/qt/src/corelib/kernel/qcoreapplication.cpp:981 #26 0x00007f0930b2edc0 in QApplication::exec () at /home/kde-devel/src/qt/src/gui/kernel/qapplication.cpp:3576 #27 0x00007f09352f8547 in kdemain (argc=2, argv=0x7fff81f8e578) at /home/kde-devel/src/KDE/kdebase/workspace/krunner/main.cpp:65 #28 0x0000000000400936 in main (argc=2, argv=0x7fff81f8e578) at /home/kde-devel/build/KDE/kdebase/workspace/krunner/krunner_dummy.cpp:3
Oh, sometimes the freeze happens when running an application, sometimes simply when typing in search terms. This particular backtrace was from typing in "kmail", and there were no results displayed.
Can you try disabling dbus-intensive runners (such as nepomuk, for instance) and see if they are the culprit? Thanks
Well, after quitting KRunner and starting it again with QDBUS_DEBUG=1 on, I was getting a slightly different pattern of freezes: Alt+F2, then type "kmail", then ESC, then ALT+F2 caused a freeze (before KRunner slides into view) with a similar backtrace. This one went away when I disabled the "control media player" runner. Console output: Adding rule: type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0='org.mpris.amarok' QDBusConnectionPrivate(0x1b56060) sending message (blocking): QDBusMessage(type=MethodCall, service="org.mpris.amarok", path="/Collection", interface="org.kde.amarok.Collection", member="Query", signature="", contents=("<query version="1.0"><limit value="10" /><filters><or><include field="title" value="mail" /><or><include field="artist" value="mail" /><or><include field="album" value="mail" /></or></or></or></filters><includeCollection id="localCollection" /></query>") )
After logging out and in again (to go back to the original state), and playing around some more, it definitely seems to be the Control Audio Player runner causing the problems.
In fact (and sorry for spamming like this), simply disabling Amarok collection searching is enough. Note: I run latest Amarok from git. Is it possible that there is a D-Bus interface mis-match?
'This one went away when I disabled the "control media player" runner.' I came to post the same thing, I'm almost certain both my problems have disappeared after disabling collection searching in that runner (that said it seams the runner doesn't work very well at all here, only pause/stop seam to work at all, but prev/next/play work for http://kde-look.org/content/show.php?action=content&content=109120, which was apparently merged) posibly relevant version infos: amarok 2.2.1.90 libdbus-1-3 1.2.16-0ubuntu9 libdbus-glib-1-2 0.80-4ubuntu1 libdbus-qt-1-1c2 0.62.git.20060814-2build2
I've also been experiencing this (currently 4.4 RC1, but I'm quite sure it also happened in 4.4 Beta 2) and after turning off the control audio player it seems instantly at lot less volatile. On Gentoo, with Qt 4.6.0-r1 and Amarok 2.2.1.90. (actually, it looks as though 2.2.2 is out, but seeing as Alex is running from Git it's probably a problem either still unsolved or existing with Nepomuk instead of Amarok).
UPDATE on the bug: I can confirm this bug in KDE 4.4.0 with the same description.
Have the same problem in Lucid 64bit with kde 4.4.1a from repos. Krunner freezes in the middle of typing for 20-30 secs.
Hey just in case you mixed it the workaround is posted in reply #9 (if it is not working for you then please specify which plugin is causing it for you). I think the best fix is to remove that plug-in competently, until this bug is fixed (It looks like the code is unmaintained)
This is also how i've been "fixing" it for long : most of runners are disabled, i keep the very few very important ones (web, open application).
How disable a runner? uninstalling it?
When you do 'alt-f2', there is a 'configuration' button to select which runners are used.
Disabling runners is not a fix. It's a workaround. Has anybody isolated that this is only due to the Amarok plugin?
On my machine, either disabling the "Control Audio Player" plugin, or unchecking the "Search collection" box in its configuration dialog resolves the issue.
SVN commit 1106768 by alexmerry: Make sure calls over D-Bus to media players do not block the KRunner gui. CCBUG: 203668 M +10 -10 audioplayercontrolrunner.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1106768
SVN commit 1106771 by alexmerry: Backport r1106768 to 4.4: Make sure calls over D-Bus to media players do not block the KRunner gui. CCBUG: 203668 M +10 -10 audioplayercontrolrunner.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1106771
I'm going to close this: the fix above will be in 4.4.2. If anyone still has the problem with 4.4.2 (or after disabling the "Control Audio Player" runner in 4.4.1), re-open, or open a new bug. If you can solve the problem by disabling a particular runner, that would be really useful to know.
the fix is it really in 4.4.2? I'm using kubuntu 10.04, I enabled search collection and the freezes came back. kde4-config --version Qt: 4.6.2 Plataforma de desarrollo de KDE: 4.4.2 (KDE 4.4.2) kde4-config: 1.0
*** Bug 231774 has been marked as a duplicate of this bug. ***