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.
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.
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.
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.
*** Bug 167794 has been marked as a duplicate of this bug. ***
*** Bug 167654 has been marked as a duplicate of this bug. ***
I have yesterdays trunk and Kopete doesn't terminate.
This is related to bug 167459
*** Bug 167459 has been marked as a duplicate of this bug. ***
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.
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
*** Bug 167968 has been marked as a duplicate of this bug. ***
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
The Kopete bug is now fixed (commit 840788) so you can ignore my previous post.
*** Bug 168142 has been marked as a duplicate of this bug. ***
*** Bug 168269 has been marked as a duplicate of this bug. ***
*** Bug 168304 has been marked as a duplicate of this bug. ***
*** Bug 167522 has been marked as a duplicate of this bug. ***
*** Bug 168463 has been marked as a duplicate of this bug. ***
*** Bug 168446 has been marked as a duplicate of this bug. ***
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 ...
*** Bug 168525 has been marked as a duplicate of this bug. ***
*** Bug 168582 has been marked as a duplicate of this bug. ***
*** Bug 168746 has been marked as a duplicate of this bug. ***
*** Bug 168825 has been marked as a duplicate of this bug. ***
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 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
*** Bug 169273 has been marked as a duplicate of this bug. ***
*** Bug 169205 has been marked as a duplicate of this bug. ***
*** Bug 169360 has been marked as a duplicate of this bug. ***
*** Bug 169968 has been marked as a duplicate of this bug. ***
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.
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.
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!
This doesn't happen anymore. Sorry for the noise.
*** Bug 170517 has been marked as a duplicate of this bug. ***
So, will this fix reflect in 4.1.2?
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 close. This stole 100mb of ram
I confirm that the bug still exists as of KDE 4.1.1.
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.
*** Bug 170335 has been marked as a duplicate of this bug. ***
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.
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.
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 :-(
You can't disable javascript in konqueror in any other manner than globally ;)
This bug is already fixed in 4.1.1, what you're seeing now is actually bug 170461. Please follow up there.
(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
Sorry, I'll check behaviour after disabling javascript globally when I am at home. PS I'm not sure atm how to do that ;)
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.
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.
Kde 4.1.2 konqueror finally "dead" when i close it,but all kio_(http,desktop,thumbnail) still alive.
kioslaves are kept for a little bit of time in case they could be reused, no bug there.
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.
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.
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.
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.