Bug 167826 - Konqueror, Kate and other KDE processes never terminate
Summary: Konqueror, Kate and other KDE processes never terminate
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: kdelibs bugs
: 167459 167522 167654 167794 167968 168142 168269 168304 168446 168463 168525 168582 168746 168825 169205 169273 169360 169968 170335 (view as bug list)
Depends on:
Reported: 2008-07-31 11:08 UTC by Brendon Higgins
Modified: 2009-07-07 16:58 UTC (History)
33 users (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Brendon Higgins 2008-07-31 11:08:10 UTC
Version:            (using KDE 4.1.0)
Installed from:    Debian testing/unstable Packages
OS:                Linux

Open konsole, and use it to start konqueror. Then close konqueror. The process does not terminate.

If you keep track of the output of ps, it's clear that any invocation of konqueror (not just from konsole) starts a new process that does not terminate - they all stick around, doing... lord knows what.

Well, actually, I did run it in gdb, CTRL-Z to suspend after "quitting" and backtraced, and found that it seems to be stuck in poll() in libc. I guess it's waiting for notification of an event that it'll never get. 

I'm guessing there's a signal/slot connection or two missing somewhere.

This bug seems related to (probably caused by the same fault) 167794 in Kate, but at least Kate will quit on Ctrl-Q.
Comment 1 Eduardo Robles Elvira 2008-07-31 11:14:42 UTC
Are you sure you're using KDE 4.1 final version and not a nightly build? This bug is suppsed to have already been fixed.
Comment 2 George Kiagiadakis 2008-07-31 11:50:51 UTC
I can confirm that on KDE 4.1.0 final from Debian packages. Other people in irc also had this issue. I believe it's a kdelibs bug as it affects many applications including konqueror, kate, kopete, kmail and possibly other appliactions. See bug 167794 (kate), bug 167654 (kopete) and bug 167745 (kmail).

The behavior is a bit different on each application, though.
Comment 3 George Kiagiadakis 2008-07-31 18:10:36 UTC
And this is the solution... http://websvn.kde.org/?view=rev&revision=837355 and http://websvn.kde.org/?view=rev&revision=837380

So, it is fixed in trunk but it is not backported to the 4.1 branch.

I am reassigning this to kdelibs as the fix is actually in kdelibs. I'll also mark the other bugs as duplicates, as after some investigation, they all seem to have the same cause. According to gdb, they all seem to be stuck in the event loop, probably waiting for KGlobal::deref() or QCoreAppliction::quit(). In the case of the kate bug, kate shuts down fine using file->quit because this calls QCoreApplication::quit() directly.

PS: I am not going to mark bug 167745 as a duplicate yet, as I can't reproduce it. It may have a slightly different cause or some other bug in combination with this bug.
Comment 4 George Kiagiadakis 2008-07-31 18:12:22 UTC
*** Bug 167794 has been marked as a duplicate of this bug. ***
Comment 5 George Kiagiadakis 2008-07-31 18:12:57 UTC
*** Bug 167654 has been marked as a duplicate of this bug. ***
Comment 6 Roman Jarosz 2008-07-31 18:26:32 UTC
I have yesterdays trunk and Kopete doesn't terminate.
Comment 7 Dario Andres 2008-07-31 23:24:37 UTC
This is related to bug 167459
Comment 8 George Kiagiadakis 2008-07-31 23:45:44 UTC
*** Bug 167459 has been marked as a duplicate of this bug. ***
Comment 9 Rafael Fernández López 2008-08-01 01:49:52 UTC
After my commit to trunk this is not happening anymore to any application (I also tried with Kopete, application is quitting fine).

This wasn't needed to be backported because the change that produced this failure wasn't backported either... AFAIR.

David probably has better memory than me, so I'm adding him as CC.
Comment 10 Rafael Fernández López 2008-08-01 02:15:21 UTC
SVN commit 840377 by ereslibre:

When the tagging was done, the problematic patch did get into. This is a backport of the fix for this problem. This commit has been into 4.2 (trunk) for several days now, so I am backporting it.

BUG: 167826

 M  +13 -5     kdecore/kernel/kglobal.cpp  
 M  +5 -0      kdeui/widgets/kmainwindow.cpp  

WebSVN link: http://websvn.kde.org/?view=rev&revision=840377
Comment 11 Maksim Orlovich 2008-08-01 16:47:04 UTC
*** Bug 167968 has been marked as a duplicate of this bug. ***
Comment 12 Roman Jarosz 2008-08-01 19:00:52 UTC
At least in Kopete it's not fixed (latest trunk with qt 4.4.1). I can reproduce the freeze if I start Kopete, open chat window, close the opened chat window and then quit Kopete.
(tested with testbed account)

Backtrace from gdb:
#0  0x00007fdb3854867f in poll () from /lib/libc.so.6
#1  0x00007fdb348229d8 in ?? () from /usr/lib/libglib-2.0.so.0
#2  0x00007fdb34822cfb in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#3  0x00007fdb3b2c179f in QEventDispatcherGlib::processEvents (this=0x69c510, flags=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:325
#4  0x00007fdb39adedbf in QGuiEventDispatcherGlib::processEvents (this=0xe7e0e0, flags=<value optimized out>) at kernel/qguieventdispatcher_glib.cpp:204
#5  0x00007fdb3b29bb02 in QEventLoop::processEvents (this=<value optimized out>, flags={i = 1176695440}) at kernel/qeventloop.cpp:149
#6  0x00007fdb3b29bc95 in QEventLoop::exec (this=0x7fff4622f2d0, flags={i = 1176695520}) at kernel/qeventloop.cpp:196
#7  0x00007fdb3b29ddf5 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:849
#8  0x000000000044c23f in main (argc=1, argv=0x7fff46230108) at /home/data/kdesvn/kde4network/kopete/kopete/main.cpp:102
Comment 13 Roman Jarosz 2008-08-01 22:32:34 UTC
The Kopete bug is now fixed (commit 840788) so you can ignore my previous post.
Comment 14 George Kiagiadakis 2008-08-03 11:01:03 UTC
*** Bug 168142 has been marked as a duplicate of this bug. ***
Comment 15 Christophe Marin 2008-08-03 23:37:16 UTC
*** Bug 168269 has been marked as a duplicate of this bug. ***
Comment 16 George Kiagiadakis 2008-08-04 21:08:20 UTC
*** Bug 168304 has been marked as a duplicate of this bug. ***
Comment 17 Harald Sitter 2008-08-05 00:02:19 UTC
*** Bug 167522 has been marked as a duplicate of this bug. ***
Comment 18 George Kiagiadakis 2008-08-06 10:34:55 UTC
*** Bug 168463 has been marked as a duplicate of this bug. ***
Comment 19 George Kiagiadakis 2008-08-06 10:46:31 UTC
*** Bug 168446 has been marked as a duplicate of this bug. ***
Comment 20 Alan Braslau 2008-08-06 11:11:31 UTC
May be related:
1) yakuake is getting killed (SIGKILL?), not quit/exit on logout. The manifestation of this is not saving its options correctly.
2) iceweasel/firefox remains running in the background following a close
Comment 21 Pino Toscano 2008-08-06 17:56:02 UTC
*** Bug 168525 has been marked as a duplicate of this bug. ***
Comment 22 George Kiagiadakis 2008-08-07 09:23:08 UTC
*** Bug 168582 has been marked as a duplicate of this bug. ***
Comment 23 George Kiagiadakis 2008-08-09 00:41:10 UTC
*** Bug 168746 has been marked as a duplicate of this bug. ***
Comment 24 George Kiagiadakis 2008-08-09 22:59:44 UTC
*** Bug 168825 has been marked as a duplicate of this bug. ***
Comment 25 S. Burmeister 2008-08-16 16:26:36 UTC
Is there anything one could do to prevent kde from restarting those dead processes on every login? I bet many users have >25 of them that get restarted, since the fix only stopps adding new ones, if I understood it correctly.
Comment 26 Dario Andres 2008-08-16 16:29:52 UTC
comment 25 : you can disable the auto-saving on session exit in KDE System Settings. In Advanced tab, session manager, "On Login" you can select "Restore manually .." or "Start with an empty session" . So the ghost process that were alive when you closed your KDE session (and thus being saved in the "session") won't appear again when you re-login in your KDE account
Comment 27 Médéric Boquien 2008-08-17 01:20:46 UTC
*** Bug 169273 has been marked as a duplicate of this bug. ***
Comment 28 Pino Toscano 2008-08-19 00:02:52 UTC
*** Bug 169205 has been marked as a duplicate of this bug. ***
Comment 29 Pino Toscano 2008-08-21 01:32:32 UTC
*** Bug 169360 has been marked as a duplicate of this bug. ***
Comment 30 Bram Schoenmakers 2008-08-28 11:15:59 UTC
*** Bug 169968 has been marked as a duplicate of this bug. ***
Comment 31 Rafael Fernández López 2008-08-28 11:41:20 UTC
Actually, this is still happening if you open a link in a new window. After having closed the two windows, the Konqueror process is still running.
Comment 32 Manuel Amador (Rudd-O) 2008-08-29 16:55:25 UTC
Let me confirm this on Fedora 9, same problem, same 4.1.0 stable release.  And some other applications take a long time to start and output something like a DBus timeout.
Comment 33 Manuel Amador (Rudd-O) 2008-08-29 16:57:22 UTC
Yah, Kopete and KMail also fail to terminate.  On an unrelated note, why is Kopete eating up 650 MB of VMSize?  It's almost 300 meg above the shared library load!
Comment 34 Rafael Fernández López 2008-09-02 18:46:08 UTC
This doesn't happen anymore. Sorry for the noise.
Comment 35 Bram Schoenmakers 2008-09-06 16:35:09 UTC
*** Bug 170517 has been marked as a duplicate of this bug. ***
Comment 36 Yogesh Marwaha 2008-09-06 18:48:22 UTC
So, will this fix reflect in 4.1.2?
Comment 37 giuseppe 2008-09-07 06:48:39 UTC
Is not fixed
at least on kde 4.1.1
compiled from sources
on slackware current.
After use konqueror(1h for example)
there are 5 sessions opened and one
konqueror silent...but konqueror is
This stole 100mb of ram
Comment 38 Cláudio da Silveira Pinheiro 2008-09-07 16:22:47 UTC
I confirm that the bug still exists as of KDE 4.1.1.
Comment 39 George Kiagiadakis 2008-09-07 22:47:12 UTC
Hmm, I had opened a new bug report for the 4.1.1 issue (bug 170461) as I think this time it may be a konqueror issue and not a kdelibs one, but well, I am not the right person to judge that...

The fact are that: For me, konqueror does not terminate if it is started with a url as an argument, but it terminates on all other cases. For Yogesh (bug 170517), it's exactly the opposite.

It's important to note, though, that this happens *only* with konqueror and not with other apps like kopete and kmail that had this problem on 4.1.0.
Comment 40 Bram Schoenmakers 2008-09-08 19:58:07 UTC
*** Bug 170335 has been marked as a duplicate of this bug. ***
Comment 41 Christian Schafmeister 2008-09-10 14:09:08 UTC
I compiled KDE 4.1.1 with the backport mentioned by Rafael Fernández López (Comment #10) and the problem still exists.

But when I global disable Javascript the Konqueror processes terminate correctly (even when given an url as a parameter). Would be nice if anyone can check this and perhaps confirm it.

I also disabled all of the performance stuff (loading Konqueror process in the background at startup ...).

Perhaps this is a Konqueror + Javascript problem.
Comment 42 George Kiagiadakis 2008-09-10 14:18:30 UTC
The situation is this: This bug (bug 167826) itself is fixed. What is happening in 4.1.1 is that the javascript debugger opens always without being enabled in the options and holds a KGlobal reference internally (because it is a KMainWindow, just not shown). Unfortunately, there is no way to shut down the js debugger and thus it stays open forever, keeping the konqueror instance active. Disabling javascript will obviously fix the problem. I bet the commit that was supposed to fix bug 169881 caused that behavior.
Comment 43 Christian Schafmeister 2008-09-10 17:26:05 UTC
It's getting stranger. Konqueror processes don't terminate correctly even with Javascript disabled. When I have Javascript disabled and go to a page which uses javascript, I have no restrictions there (as if Javascript is enabled). When I visit such a page, the Konqueror process doesn't terminate correctly (perhaps Javascript is being enabled automatically even if I say "don't globally enable Javascript" in the options). I also compiled kdelibs 4.1.1 with the bugfix mentioned in bug 169881 (I manually patched it in).
Is there no solution for this bug? It's so annoying on a laptop where you use hibernate and don't reboot very often :-(
Comment 44 Anders Lund 2008-09-10 17:39:03 UTC
You can't disable javascript in konqueror in any other manner than globally ;)
Comment 45 Kevin Kofler 2008-09-16 23:25:54 UTC
This bug is already fixed in 4.1.1, what you're seeing now is actually
bug 170461. Please follow up there.
Comment 46 Yogesh Marwaha 2008-09-17 08:01:04 UTC
(In reply to comment #45)
> This bug is already fixed in 4.1.1, what you're seeing now is actually
> bug 170461. Please follow up there.
I'm using 4.1.1, but it is exactly the opposite (to bug 170461) for me.
Please refer to http://bugs.kde.org/show_bug.cgi?id=170517#c3
Comment 47 Yogesh Marwaha 2008-09-17 08:05:33 UTC
Sorry, I'll check behaviour after disabling javascript globally when I am at home.
PS I'm not sure atm how to do that ;)
Comment 48 Kevin Kofler 2008-09-17 08:15:51 UTC
I'm pretty sure your problem is the same as bug 170461 even if the preconditions appear not to match for some reason. It is definitely not the same as this bug, which was fixed in 4.1.1. So it would be nice if you could stop misusing this bug report for an unrelated issue.
Comment 49 Kevin Kofler 2008-09-17 08:22:25 UTC
I just edited the subject to clarify what _this_ bug really is about, because this was _not_ a Konqueror-specific issue, unlike what we're seeing now.
Comment 50 giuseppe 2008-10-10 10:27:58 UTC
Kde 4.1.2
konqueror finally "dead" when
i close it,but all kio_(http,desktop,thumbnail)
still alive.
Comment 51 David Faure 2008-10-10 10:46:41 UTC
kioslaves are kept for a little bit of time in case they could be reused, no bug there.
Comment 52 Cláudio da Silveira Pinheiro 2008-10-10 14:41:51 UTC
If by "a little bit" you mean several days... cause those kioslaves are just sitting here waiting for the rapture. :) I'd rather not having them here wasting memory in their contemplative state for so long.
I don't know the measurable milisecond-saving benefits of having these stray kioslaves in memory (never measured with valgrind), but I'm certainly aware of the burden. I would gladly trade those miliseconds for less memory consumption and less disk thrashing (bad for overall performance and battery) thank you very much.
If the kioslave creation performance is so poor to justify maintaining some of them open in case they can be reused, then the place where optimization is most needed is the kioslave creation method(s) it(them)self(ves). If kioslave creation performace is all-good, then maintaining so many of them open is barely justifiable.
Comment 53 David Faure 2008-10-10 17:35:31 UTC
Stop your horses ;) Idle kioslaves are supposed to be kept along for 30 seconds. Anything else is a bug. Can you open a separate bug (for kdelibs, assigned to me) ? We're getting rather away from the initial problem in this bug report.
Comment 54 Cláudio da Silveira Pinheiro 2008-10-11 05:57:57 UTC
David, your wish is my command! :)

Please check the new bug: https://bugs.kde.org/show_bug.cgi?id=172566
For some unknown reason I was unable to reassign the bug to you. You must do it by yourself.
Comment 55 Nesta Campbell 2009-07-07 16:58:43 UTC
This has not been fix. I am running 4.3 rc1 on Kubuntu 9.04 and this is still happening. Mostly with Kopete and KMail. I also have the kioslaves issue.