Bug 241307 - KDE hangs if active network device is broken
Summary: KDE hangs if active network device is broken
Status: RESOLVED NOT A BUG
Alias: None
Product: plasma4
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR major
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
: 279316 283659 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-06-10 16:14 UTC by HLS System Design Martin Hofius
Modified: 2011-12-03 19:44 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description HLS System Design Martin Hofius 2010-06-10 16:14:13 UTC
Version:           unspecified (using KDE 4.3.5) 
OS:                Linux

The KDE System didn't respond to any key press or mouse click after the router device (AVM Fritz!Box) lost its internet connection. Nevertheless I could the mouse pointer around and non KDE programs (e.g. firefox) were responsive. I could also switch to other linux consoles (STRG+ALT+Fn).
After stopping the network device with "ifdown eth0" everything worked again - until restarting it with "ifup eth0".
Today I watched a similar (or the same) on a different machine (also KDE 4.3.5) while I had to reset this router over a WLAN connection - the KDE was hanging until networkmanager had disabled the current (and broken) WLAN connection.

In some cases the missing reactions came after some minutes...

Reproducible: Always

Steps to Reproduce:
Login to KDE 4.3.5 and start a non-KDE application (e.g. firefox)
Disconnect the active network connection without stopping the network device first (e.g. by drawing the network cable...)
Try some mouse clicks on KDE parts

Actual Results:  
KDE parts are no more responding to the mouse clicks and key press; the non KDE application (firefox) performs normal

Expected Results:  
All parts should respond normal clicks and key press.

The first machine wich showed this bug is equipped with a nvidia grahpics adapter which is suspected to be involved in such a behaviour. But the second machine mentioned above is a notebook with an old intel graphic chipset (855GM).

I also noticed that after revoking after a suspend to RAM the screen saver and a mouse pionter appear, but mouse clicks or key press (to show up the password entry field) are ignored for about 30 seconds.

I declared this bug as a major because without knowing a workaround (e.g. stopping the network device) most desktop users will not wait for several minutes but switch off the system and therefor loose their data.
Comment 1 Christoph Feck 2010-06-10 20:14:47 UTC
If you are familiar with the console, could you use "gdb --pid `pidof plasma-desktop`" then type "bt" to get a backtrace where it hangs? Maybe also try a simpler KDE program, such as KCalc, and check if it hangs, too. If yes, replace plasma-desktop with kcalc and attach a backtrace.
Comment 2 HLS System Design Martin Hofius 2010-06-12 10:08:57 UTC
(gdb) bt
#0  0xffffe424 in __kernel_vsyscall ()
#1  0xb6059d5e in poll () from /lib/libc.so.6
#2  0xb5ef0cab in g_poll () from /usr/lib/libglib-2.0.so.0
#3  0xb5ee3bc1 in ?? () from /usr/lib/libglib-2.0.so.0
#4  0xb5ee3ebe in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#5  0xb7795011 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#6  0xb63a729a in ?? () from /usr/lib/libQtGui.so.4
#7  0xb776798d in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#8  0xb7767dd9 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#9  0xb776a270 in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4
#10 0xb6305774 in QApplication::exec() () from /usr/lib/libQtGui.so.4
#11 0xb2c06be9 in kdemain () from /usr/lib/libkdeinit4_plasma-desktop.so
#12 0x0804e147 in _start ()
(gdb)
Comment 3 Christoph Feck 2010-06-12 15:29:31 UTC
Thanks for the information. From the backtrace I see that you use plasma-desktop, which possibly uses some widgets that request network connections.

Could you try removing widgets to see which of them does not handle network failure, or blocks on network requests? KDE applications should use KIO for network handling, and this should not block the UI.

I am reassigning to plasma developers, maybe they can verify if there are any remaining widgets that could block on network access.
Comment 4 Alvise 2010-06-16 10:46:09 UTC
In my case I suppose it is due to stockoid. However the situation has dramatically improved from 4.3 to 4.4
Comment 5 Alexander Potashev 2011-01-06 23:39:50 UTC
Duplicate of bug#184062 ?
Comment 6 Lamarque V. Souza 2011-06-04 07:24:47 UTC
Is this still happening?
Comment 7 S. Burmeister 2011-06-04 09:55:25 UTC
bug 184062 states that this is still an issue with KDE 4.6.
Comment 8 Lamarque V. Souza 2011-08-03 22:34:37 UTC
*** Bug 279316 has been marked as a duplicate of this bug. ***
Comment 9 Lamarque V. Souza 2011-10-10 15:02:17 UTC
*** Bug 283659 has been marked as a duplicate of this bug. ***
Comment 10 Aaron J. Seigo 2011-12-03 19:44:34 UTC
stockoid -> not a production widget (still in playground); different issue from the nfs mounts issue in 184062, obviously.