Bug 163752 - 100% cpu when network goes down (ping timeout)
Summary: 100% cpu when network goes down (ping timeout)
Status: RESOLVED WORKSFORME
Alias: None
Product: konversation
Classification: Applications
Component: general (show other bugs)
Version: 1.0.1
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Konversation Developers
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2008-06-11 05:57 UTC by Maxime Gamboni
Modified: 2018-10-27 03:33 UTC (History)
4 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 Maxime Gamboni 2008-06-11 05:57:29 UTC
Version:           1.0.1 (using 3.5.8, Kubuntu (gutsy) 4:3.5.8-0ubuntu3.4)
Compiler:          Target: x86_64-linux-gnu
OS:                Linux (x86_64) release 2.6.22-14-generic

I use konversation on an unreliable network so this happens quite often to me:

In case I get a ping timeout to the server, konversation shows the message "[error] Closing Link: [...] (Ping timeout)", as expected, but then starts using 100% cpu for about one or two minutes. I can still use it and in particular choosing the "disconnect" option in the "file" menu restores normal cpu usage.

It may not seem a big deal but if I'm working on other tasks and the network keeps coming up and down then the computer can become unusable every ten minutes or so...

Also, sorry if this is a duplicate report - the search function discards the "cpu" keyword as being "too short"..
Comment 1 Eike Hein 2008-06-11 13:33:39 UTC
It would be cool if you could test the SVN version* for whether that problem still occurs for you there, as the connection management- / reconnect-related code has been rewritten. SVN is presently in freeze for an impending release, so it's stable otherwise.

* = http://konversation.kde.org/wiki/SVN
Comment 2 Maxime Gamboni 2008-06-12 05:58:56 UTC
I installed the svn version and the bug still seems to be there. The "about" window now says Konversation 1.0.1+ #3233 (using KDE 3.5.8).

I observed the behaviour more carefully now:

1. I'm logged in an irc channel and the connectivity goes down (pinging the server reports "destination host unreachable")

2. After a while, the latency display in Konversation starts counting seconds

3. Every now and then the status bar changes to say "no answer from server <server name> for more than X time" (for 5, 35, and 65 seconds)

4. When the latency counter hits 128 seconds, the message "[error]  Closing Link: <my handle and ip> (Ping timeout)" appears, and the cpu usage goes up to 100%. The list of people being connected is still visible.

5. The latency counter keeps counting, and the status bar keeps updating the "no answer" message (for 140, 170 and 175 seconds). All this time, cpu usage is at 100%.

6. When the latency counter hits 180, the message "konversation: Connection broken (Socket fd -1) 0!" is sent to stdout (maybe stderr), the nick list on the right is blanked and cpu usage is normal again.

Thanks.
Comment 3 Eike Hein 2008-06-12 13:48:21 UTC
Interesting - thank you very much for your detailed report; we're looking into it.
Comment 4 Jeremy Kerr 2008-09-29 11:36:10 UTC
I'm having the same problem here on vanilla 1.0.1. In particular, it seems to be specific to my connection to irc.oftc.net, to which I connect over SSL. Whenever the connection to oftc times out (eg, after bringing the laptop home from work), CPU goes to 100%.

I can easily reproduce:

1) Start connection to ircs.oftc.net:9999 (with SSL)
2) The 'invalid SSL certificate dialog' will appear
3) Wait a minute or so before clicking 'accept' on dialog
4) Registration with IRC server will time out:

 [error] Closing Link: ppp-xxx.internode.on.net (Registration timed out)
 [Info] Connected; logging in...

5) CPU hits 100%

Occasionally, it'll do this while the dcop server is waiting on a read() from konversation's dcop socket; this blocks all KDE apps, including the window manager. The only way out is to change to a different VT and kill konversation :(
Comment 5 Eike Hein 2008-09-29 11:47:19 UTC
IIRC we tracked down an unfixable blocking issue inside kdelibs/KSSL around timeouts and reconnect earlier this year, although I unfortunately lost my IRC logs of that dev discussion. Unfixable in the sense that we won't rearchitect the KDE 3 codebase to be multithreaded at this point, and there was no other feasible way. That said, iirc it wasn't a permanent block but a minute-long wait of some kind. Since KSSL is gone for our purposes in KDE 4, and Qt 4 makes multi-threading generally a lot easier and more reaslistic to use, things are likely to change in the next version.

Maybe someone else can dig up the IRC logs about the KSSL blocking issue and add them here.
Comment 6 Jeremy Kerr 2008-09-30 01:36:37 UTC
(In reply to comment #5)
> That said, iirc it wasn't a permanent block but a minute-long wait of some
> kind.

I've re-tested, and after 20 minutes it's still spinning...
Comment 7 Yuval Hager 2009-04-20 18:27:53 UTC
I'm getting similar results (I CAN connect, but after a while connection is lost, and CPU reaches high, until I close it - much more than a minute).

I've just tried net-irc/konversation-svn (Gentoo), and I used irc.oftc.net:6697 (SSL). When I do not use SSL connection, all works fine.
Comment 8 Eike Hein 2013-04-15 00:54:32 UTC
Does this still happen with newer versions of Konversation?
Comment 9 klondike 2015-04-07 05:05:37 UTC
Yes it does happen with Konversation 1.5.1 and KDE 4.14.3

When connecting to znc using SSL with a long buffer or losing the connection the CPU usage gets really high (also when connecting messages are received really slowly, I suspect because of this bug).
Comment 10 Andrew Crouthamel 2018-09-25 21:51:45 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 11 Andrew Crouthamel 2018-10-27 03:33:03 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!