CPU load randomly hits 100%; XMPP random reconnects

Bug #218439 reported by Michael Adams
64
This bug affects 5 people
Affects Status Importance Assigned to Milestone
pidgin (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Binary package hint: pidgin

On Ubuntu Hardy, I am seeing the CPU hit 100% load at times, and frequent disconnects/reconnects of my XMPP account in Pidgin. I also have to run Ubuntu in "Normal" visual effects mode to get it to refresh correctly, else at "None," it fails to refresh without changing the actual GNOME theme.

ProblemType: Bug
Architecture: i386
Date: Wed Apr 16 19:05:11 2008
DistroRelease: Ubuntu 8.04
ExecutablePath: /usr/bin/pidgin
Package: pidgin 1:2.4.1-1ubuntu2
PackageArchitecture: i386
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: pidgin
Uname: Linux 2.6.24-16-generic i686

Tags: apport-bug
Revision history for this message
Michael Adams (madams) wrote :
Revision history for this message
sp (brightnesslevels) wrote :

I'm experiencing the same problem with Pidgin, and apparently, this also happens for other people too:
http://ubuntuforums.org/archive/index.php/t-655724.html
http://ubuntuforums.org/showthread.php?t=637172

It's indeed only XMPP problem, ICQ/AOL works fine. I've recently upgraded to Hardy from Gutsy, under 7.10 I didn't experience this problem.

Revision history for this message
kest (kest12) wrote :

Yes, i have similar problems with Pidgin. Sometimes everything works OK, but many times i just got 100% cpu usage, frequent reconnects too.

I am using Google talk and jabber protocols with Pidgin.

2.6.24-17-generic - Hardy
Pidgin 2.4.1

Revision history for this message
mavosaure (mavosaure) wrote :

I've got similar problems :

- CPU came up to 100% untill I kill pidgin
- this problem affects only XMPP (Gmail in fact) account. For MSN, WLM (via msn-pecan), Yahoo, there's no pb.
- sometimes, it works fine, but in many cases, it failes

Description of the bug :
- CPU came up to 100% untill I kill pidgin
- Tray icon disapear, leavin only a empty place.
- if pidgin window is not minimized, it can't be refresh

Workaround :
 - just kill and try again... if you find better...

Debug-logs :
I tried to prompt a ot of debug log for pidgin. I don't see any critical message but I'm not developper or hacker.
At the beginning of the logs, I can read :
            (23:30:35) dbus: Failed to get connection: Failed to execute dbus-launch to autolaunch D-Bus session

I founded an explanation here (http://developer.pidgin.im/wiki/DbusHowto#TroubleshootingD-Bus), but I'm not able to understand what to do. I just can see that the entionned line :
           dbus: okkk
is not in my debug-log.

DistroRelease: Xubuntu 8.04
ExecutablePath: /usr/bin/pidgin
Package: pidgin 1:2.4.1-1ubuntu2
PackageArchitecture: i386
Kernel : 2.6.24-19-generic, 2.6.24-18-generic and maybe 16 and 17... I can't be sure.

Revision history for this message
mavosaure (mavosaure) wrote :

Something interesting to notice :

The other plugins of pigin seem to be continuing to work, even the CPU reched 100%, and the GUI is frozen. I can read other messages in the debug log from the msn plugin, for exemple, but at that time there is no one line of the jabber plugin.

an exemple of the last lines aof the jabber plugin in the debug log :

(12:48:07) jabber: Recv (ssl)(176): <?xml version="1.0" encoding="UTF-8"?><stream:stream from="gmail.com" id="XXXXXXXXXXXXXX version="1.0" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client">
(12:48:08) jabber: Recv (ssl)(166): <stream:features><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>PLAIN</mechanism><mechanism>X-GOOGLE-TOKEN</mechanism></mechanisms></stream:features>
(12:48:08) sasl: Mechs found: PLAIN X-GOOGLE-TOKEN
(12:48:08) jabber: Sending (ssl): <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='PLAIN'>XXXXXXXXXXXXXXXXXXXXXX=</auth>
(12:48:10) jabber: Recv (ssl)(51): <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl"/>
(12:48:10) jabber: Sending (ssl): <stream:stream to='gmail.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
(12:48:12) jabber: Recv (ssl)(176): <?xml version="1.0" encoding="UTF-8"?><stream:stream from="gmail.com" id="XXXXXXXXXXXXXXXXX" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client">
(12:48:12) jabber: Recv (ssl)(137): <stream:features><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"/><session xmlns="urn:ietf:params:xml:ns:xmpp-session"/></stream:features>
(12:48:12) jabber: Sending (ssl): <iq type='set' id='purple4b07dc7'><bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'><resource>Home</resource></bind></iq>

Revision history for this message
Jochen Eisinger (jochen-penguin-breeder) wrote :

If you strace pidgin, you will see that it tries to read from a socket which is closed, but this fact is ignored. When pidgin hangs, strace is an endless repetition of:

[pid 19682] poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=6, events=POLLIN}, {fd=10, events=POLLIN|POLLPRI}, {fd=15, events=POLLIN}, {fd=18, events=POLLIN}, {fd=17, events=POLLIN}, {fd=16, events=POLLIN, revents=POLLIN}], 8, 0) = 1
[pid 19682] recv(16, "", 5, 0) = 0
[pid 19682] read(3, 0x812ebd4, 4096) = -1 EAGAIN (Resource temporarily unavailable)
[pid 19682] gettimeofday({1220648322, 974206}, NULL) = 0

There's a fix in the upstream version for this:

http://developer.pidgin.im/viewmtn/revision/info/1d533cebad7c0dbda8ec8ebee1334d27dcae5f9c

Andreas Moog (ampelbein)
Changed in pidgin:
importance: Undecided → Medium
status: New → Fix Committed
Revision history for this message
Sebastien Bacher (seb128) wrote :

the new version is in jaunty

Changed in pidgin (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
bananaman (ian-c-carpenter) wrote :

I had this problem last night while talking to friends on AIM but not this morning. I noticed my system began running sluggish and I saw my processor graph at 100% so I opened up system monitor and was shocked to see pidgin at 300% and then later 400% processor usage. I could not exit pidgin normally, I had to kill it each time and it would do the same thing every time it was started. I ran strace and saw the same thing as Jochen Eisinger. I also redirected the output to a file and instead of what was displayed in strace, it simply printed the following:
(pidgin:9000): pidgin-libnotify-plugin-DEBUG: Successfully wrote blacklist file to /home/bananaman/.config/indicators/messages/applications-blacklist/pidgin-libnotify

I closed the program named "heart" and everything seemed to return to normal so it seems heart was the trigger.

Ubuntu: 9.10
Kernel: 2.6.31-14-generic
Pidgin: 2.6.2
Motherboard: Asus M4N82 Deluxe
Processor: Phenom II X4 955 Black Edition

Attachment: picture or running processes at the time of incident.

Revision history for this message
bananaman (ian-c-carpenter) wrote :
Revision history for this message
bananaman (ian-c-carpenter) wrote :

Update: This bug occurred again for me today. It seems to be fine when you just have pidgin running idle. When you message somebody or are messaged by somebody it steps up it's processor usage. After a few messages your system is swamped so you have to get out the old bb gun and kill pidgin. It's persistent and will happen over and over when you restart pidgin. Last time, everything was fine the next day and it probably will be fine tomorrow.

Revision history for this message
Wladimir Mutel (mwg) wrote :

This could be related to registered Pidgin bugs 9927, 10192, 11520 (http://developer.pidgin.im/ticket/NNNN)
Long known but who knows when is going to be fixed ...

I also experience this behaviour. Most my chats are in ICQ, and some are in XMPP. In my Pidgin I have persistent history storage turned off. But anyway, after some weeks of continuous Pidgin usage, when a number of long chats are collected in Pidgin windows, it gets really sluggish in GUI redraw and high on CPU usage.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.