Bug 167522

Summary: Konqueror process doesn't stop after close (keeps running iddle)
Product: [Applications] konqueror Reporter: Eduardo Robles Elvira <edulix>
Component: generalAssignee: Konqueror Developers <konq-bugs>
Status: RESOLVED DUPLICATE    
Severity: normal    
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Compiled Sources   
OS: All   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Eduardo Robles Elvira 2008-07-27 11:20:23 UTC 
Version:            (using Devel)
Installed from:    Compiled sources

The problem is that when closing the last konqueror window, the window gets closed, but the konqueror process keeps running and doesn't stop unless I kill it. I'm using revision 838176 (trunk ~4.2) and yes, I have konqueror preloading disable (and anyway I'm launching it from a tty andd thus I get the message "Running from tty, not keeping for preloading" which is quite descriptive :-). 

Note that the problem is happening to me also in kwrite and kate for example, but in other programs like kfind or kmail the process finish correctly.

This is the gdb backtrace when konqueror keeps running after having closed it:

konqueror(19880) KonqMainWindow::checkPreloadResourceUsage: Running from tty, not keeping for preloading

Program received signal SIGINT, Interrupt.
[Switching to Thread 0x7f7b00d9a780 (LWP 19880)]
0x00007f7af9d9ec3f in poll () from /lib/libc.so.6
(gdb) bt
#0  0x00007f7af9d9ec3f in poll () from /lib/libc.so.6
#1  0x00007f7af8d61542 in ?? () from /usr/lib/libglib-2.0.so.0
#2  0x00007f7af8d61bcb in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#3  0x00007f7afe54b3cf in QEventDispatcherGlib::processEvents (this=0x61ea90, flags=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:325
#4  0x00007f7afb83c68f in QGuiEventDispatcherGlib::processEvents (this=0x886130, flags=<value optimized out>) at kernel/qguieventdispatcher_glib.cpp:204
#5  0x00007f7afe5263d5 in QEventLoop::processEvents (this=<value optimized out>, flags=@0x7fff08dd42a0) at kernel/qeventloop.cpp:149
#6  0x00007f7afe526547 in QEventLoop::exec (this=0x7fff08dd42e0, flags=@0x7fff08dd42f0) at kernel/qeventloop.cpp:196
#7  0x00007f7afe528551 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:845
#8  0x00007f7b00972224 in kdemain (argc=1, argv=0x7fff08dd4db8) at /home/edulix/proyectos/kde4/kdesvn/kdebase/apps/konqueror/src/konqmain.cpp:227
#9  0x0000000000400943 in main (argc=1, argv=0x7fff08dd4db8) at /home/edulix/proyectos/kde4/kdesvn/build/kdebase/apps/konqueror/src/konqueror_dummy.cpp:3
Comment 1 Rafael Fernández López 2008-07-27 14:07:36 UTC 
This was a bug that David and me triggered bug short time ago (almost 2 days ago). However, the fix was done on kdelibs, so make sure you have a your kdelibs updated too. Commit link: http://websvn.kde.org:80/?view=rev&revision=837683.

If bug persists after updating, compiling and installing kdelibs, please reopen this bug.
Comment 2 Eduardo Robles Elvira 2008-07-27 22:55:53 UTC 
I'm afraid that the problem still persist. I was using rev 838176 in kdelibs when reporting the bu, which already contains your fix. Just in case I've updated kdelibs and now I'm using 838422 and the problem is still there.
Comment 3 Eduardo Robles Elvira 2008-07-27 23:03:37 UTC 
Uhm my fault, I was compiling kdelibs but not installing it...
Comment 4 Harald Sitter 2008-07-31 14:07:29 UTC 
I did some research.
This is actually happening on Kubuntu AND Windows 4.1.0 for
* kate
* kwrite
* konqueror
* kopete
* kmail

Another interesting aspect is that for kate File -> Quit actually quits but using the window decoration's close button does not.

...changing OS to All since it happens at least on Linux and Windows... I guess this bug should be moved to KDELibs?
Comment 5 Sean Wilson 2008-08-01 00:46:30 UTC 
Confirmed, I've noticed this in the final RC revisions just before final and made it into 4.1 final as well.

Konqueror, Kopete process stay alive when the apps are closed.

4.1 final, compile from sources.
Comment 6 Harald Sitter 2008-08-05 00:02:17 UTC 

*** This bug has been marked as a duplicate of 167826 ***