Pidgin 2.4.1 (Hardy): proper closed connection handling patch from upstream

[rojer]

Binary package hint: pidgin

the following patch needs to be brought in from upstream to fix "Pidgin uses 100% CPU" problem on hardy:

http://developer.pidgin.im/viewmtn/revision/diff/4d5c3b5ef59ce60e98576ffc7edf6ebb0960fff1/with/1d533cebad7c0dbda8ec8ebee1334d27dcae5f9c/libpurple/protocols/jabber/jabber.c

it appears to cause at least the following bug:

https://bugs.launchpad.net/pidgin/+bug/223443

and a number of other complaints where pidgin gets stuck in a loop reading from a closed socket.
my strace looks something like:

poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=6, events=POLLIN}, {fd=10, events=POLLIN|POLLPRI}, {fd=15, events=POLLIN}, {fd=20, events=POLLIN}, {fd=21, events=POLLIN}, {fd=17, events=POLLIN}, {fd=16, events=POLLIN, revents=POLLIN}], 9, 0) = 1
read(16, "", 4095) = 0
read(3, 0x812ebd4, 4096) = -1 EAGAIN (Resource temporarily unavailable)
gettimeofday({1222605234, 242155}, NULL) = 0
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=6, events=POLLIN}, {fd=10, events=POLLIN|POLLPRI}, {fd=15, events=POLLIN}, {fd=20, events=POLLIN}, {fd=21, events=POLLIN}, {fd=17, events=POLLIN}, {fd=16, events=POLLIN, revents=POLLIN}], 9, 0) = 1
read(16, "", 4095) = 0
read(3, 0x812ebd4, 4096) = -1 EAGAIN (Resource temporarily unavailable)
gettimeofday({1222605234, 242261}, NULL) = 0

here's a relevant discussion on pidgin developer list:

http://www.nabble.com/Pidgin-freezes-when-XMPP-server-silently-disappears-td18560831.html

[Rich Wareham (richwareham)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please answer these questions:

* Is this reproducible?
* If so, what specific steps should we take to recreate this bug?

In this specific case, what do w need to do to trigger Pidgin's 100% CPU usage? This will help us to find and resolve the problem.

[rojer (rojer9)]

* Is this reproducible?
* If so, what specific steps should we take to recreate this bug?

this happens often when wifi connecton goes away, but i can't say i can reproduce it at will. i guess it depends on how exactly connection is terminated (my guess is that it it is write that fails then it's ok, but if it happens to be in this poll, then it starts looping).

description at the nabble.com link matches my symptoms exactly.
and if you look at the patch it's pretty clear what's going on: reading 0 bytes only happens when connection has gone away and should be treated as an error.

[Pedro Villavicencio (pedro)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Could you try to reproduce the same with Ubuntu 8.10 or 9.04? Thanks in advance.

[Rojer (p-launchpad-rojer-pp-ru)]

i understand the last one is a (semi) automated reply.

*come on people*! just look at the patch, read the relevant thread and you'll see. it's so simple it's frustrating to see it not being fixed this long.

this is not an issue for 8.10 or 9.04 - those already have the fix. i myself have moved to 8.10.
it still makes sense to patch it in 8.04 though as it is an LTS release, and this bug is *extremely* annoying.

[Rojer (p-launchpad-rojer-pp-ru)]

this bug is *not* incomplete, it contains everything needed to fix the issue. someone just needs to apply the patch.

(direct link to diff: http://developer.pidgin.im/viewmtn/revision/diff/4d5c3b5ef59ce60e98576ffc7edf6ebb0960fff1/with/1d533cebad7c0dbda8ec8ebee1334d27dcae5f9c/libpurple/protocols/jabber/jabber.c)

[Id2ndR (id2ndr)]

Duplicate of bug #218439 (that have been fixed upstream). Need backporting

[J. Austin Rodriguez (jeanaustinr)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. This particular bug has already been reported and is a duplicate of bug 218439, so it is being marked as such. Please look at the other bug report to see if there is any missing information that you can provide, or to see if there is a workaround for the bug. Additionally, any further discussion regarding the bug should occur in the other report. Feel free to continue to report any other bugs you may find.