Pidgin is creating zombies

[Chris]

After upgrading to Kubuntu 13.10 pidgin is constantly creating new zombies.

E.g. after an uptime of roughly 4 hours:
$ ps aux | grep Z
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
cm 2589 0.0 0.0 0 0 ? Z 17:46 0:00 [pidgin] <defunct>
cm 3045 0.0 0.0 0 0 ? Z 17:47 0:00 [pidgin] <defunct>
cm 3106 0.0 0.0 0 0 ? Z 17:48 0:00 [pidgin] <defunct>
cm 3236 0.0 0.0 0 0 ? Z 17:50 0:00 [pidgin] <defunct>
cm 5760 0.0 0.0 0 0 ? Z 17:54 0:00 [pidgin] <defunct>
cm 5788 0.0 0.0 0 0 ? Z 18:02 0:00 [pidgin] <defunct>
cm 6405 0.0 0.0 0 0 ? Z 18:12 0:00 [pidgin] <defunct>
cm 6501 0.0 0.0 0 0 ? Z 18:22 0:00 [pidgin] <defunct>
cm 6519 0.0 0.0 0 0 ? Z 18:32 0:00 [pidgin] <defunct>
cm 6543 0.0 0.0 0 0 ? Z 18:42 0:00 [pidgin] <defunct>
cm 6580 0.0 0.0 0 0 ? Z 18:52 0:00 [pidgin] <defunct>
cm 6619 0.0 0.0 0 0 ? Z 19:02 0:00 [pidgin] <defunct>
cm 6645 0.0 0.0 0 0 ? Z 19:12 0:00 [pidgin] <defunct>
cm 6672 0.0 0.0 0 0 ? Z 19:22 0:00 [pidgin] <defunct>
cm 6691 0.0 0.0 0 0 ? Z 19:32 0:00 [pidgin] <defunct>
cm 6757 0.0 0.0 0 0 ? Z 19:42 0:00 [pidgin] <defunct>
cm 6846 0.0 0.0 0 0 ? Z 19:52 0:00 [pidgin] <defunct>
cm 6869 0.0 0.0 0 0 ? Z 20:01 0:00 [pidgin] <defunct>
cm 6889 0.0 0.0 0 0 ? Z 20:11 0:00 [pidgin] <defunct>
cm 6914 0.0 0.0 0 0 ? Z 20:21 0:00 [pidgin] <defunct>
cm 6931 0.0 0.0 0 0 ? Z 20:31 0:00 [pidgin] <defunct>
cm 6948 0.0 0.0 0 0 ? Z 20:41 0:00 [pidgin] <defunct>
cm 6972 0.0 0.0 0 0 ? Z 20:51 0:00 [pidgin] <defunct>
cm 6992 0.0 0.0 0 0 ? Z 21:01 0:00 [pidgin] <defunct>
cm 7015 0.0 0.0 0 0 ? Z 21:11 0:00 [pidgin] <defunct>
cm 7036 0.0 0.0 0 0 ? Z 21:20 0:00 [pidgin] <defunct>
cm 7121 0.0 0.0 0 0 ? Z 21:30 0:00 [pidgin] <defunct>
cm 7223 0.0 0.0 10984 940 pts/0 S+ 21:38 0:00 grep --color=auto Z

[Zdenek (zdenek-redhat-bugs)]

Description of problem:

I'm seeing a lot of defunct zombie pidgin process.

0 S kabi 12940 12849 0 80 0 - 235548 poll_s led03 ? 00:05:50 pidgin
1 Z kabi 13007 12940 0 80 0 - 0 exit led03 ? 00:00:00 [pidgin] <defunct>
1 Z kabi 13011 12940 0 80 0 - 0 exit led03 ? 00:00:00 [pidgin] <defunct>
1 Z kabi 13128 12940 0 80 0 - 0 exit led03 ? 00:00:00 [pidgin] <defunct>
...

in total there are 189 lines of pidgin defunct zombies....

Version-Release number of selected component (if applicable):
pidgin-2.10.6-4.fc19.x86_64

pidgin-privacy-please-0.7.1-4.fc18.x86_64
pidgin-logviewer-0.2-12.20110228svn15.fc18.x86_64
pidgin-libnotify-0.14-10.fc18.x86_64
pidgin-sipe-1.14.1-1.fc19.x86_64
pidgin-guifications-2.16-8.fc18.x86_64
pidgin-otr-3.2.1-2.fc18.x86_64

How reproducible:

Steps to Reproduce:
1. using pidgin
2.
3.

Actual results:

Expected results:

Additional info:

[Fedora (fedora-redhat-bugs)]

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

[Chris (mail-christianmayer)]

To be precise: pidgin is version 2.10.7

[Quinn Balazs (qbalazs)]

Any specific services that you have open/running when this issue presents itself? Trying to duplicate this, but not having much luck.
Using pidgin 2.10.7.

[Quinn Balazs (qbalazs)]

In a further attempt to try to flush out what the issue is, run "pidgin -mddddddddddddm" and attach the output, paying attention particularly to any areas where "LIBDBUSMENU-GLIB-WARNING **: Trying to remove a child that doesn't believe we're it's parent." or any other GLib related messages come up. There have been some issues with GLib spawning zombies in pidgin in 13.10.

[Chris (mail-christianmayer)]

Running pidgin like that for some time (about 10 minutes) I got up to 4 zombies. Then I waitet 3-4 minutes and no update in the log appeared. But then the number increased to 5 zombies and these lines were written in the log (replacing sensitive data by ZZZ):

=========================
(18:34:33) pidgin-libnotify: Conversation Updated (UNSEEN)
(18:35:22) autorecon: do_signon called
(18:35:22) autorecon: calling purple_account_connect
(18:35:22) account: Connecting to account <email address hidden>.
(18:35:22) connection: Connecting. gc = 0x7fd0cdff5a80
(18:35:22) dnsquery: Performing DNS lookup for irc.ZZZ.ZZZ
(18:35:22) autorecon: done calling purple_account_connect
(18:35:22) dns: Created new DNS child 4130, there are now 1 children.
(18:35:22) dns: Successfully sent DNS request to child 4130
dns[4130] Error: getaddrinfo returned -2
(18:35:22) dns: Got response for 'irc.ZZZ.ZZZ'
(18:35:22) dnsquery: Fehler beim Auflösen von irc.ZZZ.ZZZ:
Der Name oder der Dienst ist nicht bekannt
(18:35:22) proxy: Connection attempt failed: Fehler beim Auflösen von irc.ZZZ.ZZZ:
Der Name oder der Dienst ist nicht bekannt
(18:35:22) connection: Connection error on 0x7fd0cdff5a80 (reason: 0 description: Verbinden nicht möglich: Fehler beim Auflösen von irc.ZZZ.ZZZ:
Der Name oder der Dienst ist nicht bekannt)
(18:35:22) account: Disconnecting account <email address hidden> (0x7fd0cd0a3a80)
(18:35:22) connection: Disconnecting connection 0x7fd0cdff5a80
(18:35:22) connection: Destroying connection 0x7fd0cdff5a80
(18:35:27) util: Writing file accounts.xml to directory /home/cm/.purple
(18:35:27) util: Writing file /home/cm/.purple/accounts.xml
=========================

Also interesting: greping the full log, I see exactly 5 attempts to do an DNS lookup for irc.ZZZ.ZZZ...

Do we have the culprit already found?

(I'll disable the account which is trying to connect irc.ZZZ.ZZZ now to see if that helps...)

[Quinn Balazs (qbalazs)]

GLib issues seem to not be in play here. I'm going to let it run for a few hours and see if I can get a few zombies spawned. I've been able to get two zombies, but would really like to be able to conjure a few more in order to figure out a reason for them. Ideally there would be a certain action that triggered the issue, then I could script it and duplicate it on command. It's still doable, but will take a little bit more trial and error to find.

Quinn Balazs

[Chris (mail-christianmayer)]

A short update: after removing the unaccessable domain and restarting the computer, pidgin is still creating zombies.
I'll try a new run with debug logging tomorrow.

[Chris (mail-christianmayer)]

OK, starting pidgin with full debug and w/o the unavailable domain I figured out:

After start I had 3 zobies, after waiting for a long period of time it stayes at the 3 zombies, i.e. no new ones were generated after the start period.

Greping the full log for "DNS":
(12:33:19) dnsquery: Performing DNS lookup for api.login.icq.net
(12:33:19) dnsquery: Performing DNS lookup for irc.freenode.net
(12:33:19) dnsquery: Performing DNS lookup for irc.mozilla.org
(12:33:19) dnsquery: Performing DNS lookup for 192.168.0.1
(12:33:19) dns: Created new DNS child 4517, there are now 1 children.
(12:33:19) dns: Successfully sent DNS request to child 4517
(12:33:19) dns: Created new DNS child 4519, there are now 2 children.
(12:33:19) dns: Successfully sent DNS request to child 4519
(12:33:19) dns: Created new DNS child 4520, there are now 3 children.
(12:33:19) dns: Successfully sent DNS request to child 4520
(12:33:19) dnsquery: Performing DNS lookup for 192.168.0.1
(12:33:19) dnsquery: Performing DNS lookup for 192.168.0.1
(12:33:20) dnsquery: Performing DNS lookup for api.icq.net
(12:33:20) dns: Successfully sent DNS request to child 4517
(12:33:26) dnsquery: Performing DNS lookup for 205.188.11.86
(12:33:27) dnsquery: Performing DNS lookup for 205.188.11.25
(12:33:27) dnsquery: Performing DNS lookup for 64.12.73.194

=> I *guess* it's related to the 3 DNS childs - at least the number is matching perfectly to the number of zombies...

[Serhii Gipsy (serhii-gipsy)]

Same simptoms:

$ ps aux | grep Z|grep -v grep
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 2662 0.0 0.0 0 0 ? Z Feb11 0:00 [blinklight-fixp] <defunct>
xxx 4500 0.0 0.0 0 0 ? Z 14:11 0:00 [pidgin] <defunct>
xxx 5447 0.0 0.0 0 0 ? Z 15:28 0:00 [gmusicbrowser] <defunct>
xxx 28051 0.0 0.0 0 0 ? Z Feb12 0:00 [pidgin] <defunct>
xxx 28054 0.0 0.0 0 0 ? Z Feb12 0:00 [pidgin] <defunct>
xxx 28055 0.0 0.0 0 0 ? Z Feb12 0:00 [pidgin] <defunct>

[Fedora (fedora-redhat-bugs)]

This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.

[Vladimir Rutsky (rutsky)]

I'm noticing sometimes zombie Pidgin processes too on Ubuntu 13.10.

[Benoit (ben-ken-hobbit)]

Just for the record :
The problem as exist on Xubuntu 13.10 witch Pidgin 2.10.7
AND on Xubuntu 13.04 witch Pidgin 2.10.7

[Abhinav Chittora (bijolianabhi)]

I am getting the same issue with Ubuntu 14.04 and Pidgin version 2.10.9 (libpurple 2.10.9). Is there any patch available for this issue?

[Abhinav Chittora (bijolianabhi)]

In my error logs when I run "pidgin -mddddddddddddm" I can see following warnings

"(05:37:47) dnsquery: Performing DNS lookup for talk.google.com
(05:37:47) dns: Created new DNS child 25109, there are now 1 children.
(05:37:47) dns: Successfully sent DNS request to child 25109
(05:37:47) dns: Got response for 'talk.google.com'
(05:37:47) dnsquery: IP resolved for talk.google.com
(05:37:49) dnsquery: Performing DNS lookup for stun.l.google.com
(05:37:49) dns: Successfully sent DNS request to child 25109
(05:37:49) dns: Got response for 'stun.l.google.com'
(05:37:49) dnsquery: IP resolved for stun.l.google.com"

and the zombie process have the same PID as mentioned in logs i.e.

root@ubuntu:~# ps -aux |grep "Z" |grep -v grep
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
abhinav 25109 0.0 0.0 0 0 pts/1 Z+ 05:37 0:00 [pidgin] <defunct>

Let me know if anything else you all need to debug.

--Regards,
Abhinav Chittora

[Ivan (ivan-zderadicka)]

Problem remains in 14.04

Ivan

[Jaime Carpenter (j.carpenter)]

I am seeing the same in Ubuntu 14.04 LTS

[johnstrass (johnstrass)]

I met the same problem in 14.04 LTS, pidgin version 2.10.9

[Fedora (fedora-redhat-bugs)]

This message is a notice that Fedora 19 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 19. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 19 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

[WaDOS (wados)]

I've the same issue which I can reproduce on my laptop.

1. Start system
2. Start pidgin
3. Let the laptop go to hibernate mode
4. Wakeup the laptop
5. Another instance of pidgin is zombie

wados@dell:~/$ uname -a
Linux dell 3.16.0-30-generic #40-Ubuntu SMP Mon Jan 12 22:06:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

wados@dell:~/$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.10
Release: 14.10
Codename: utopic

wados@dell:~/$ dpkg -l | grep pidgin
ii pidgin 1:2.10.9-0ubuntu7.1 amd64 graphical multi-protocol instant messaging client for X
ii pidgin-data 1:2.10.9-0ubuntu7.1 all multi-protocol instant messaging client - data files
ii pidgin-libnotify 0.14-9ubuntu2 amd64 display notification bubbles in pidgin
ii pidgin-sipe 1.13.3-1 amd64 Pidgin protocol plugin to connect to MS Office Communicator
ii pidgin-themes 0.2-1 all Smiley themes collection for pidgin

wados@dell:~/$ ps aux|grep Z
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
wados 9858 0.0 0.0 0 0 ? Z 10:29 0:00 [pidgin.orig] <defunct>

[Fedora (fedora-redhat-bugs)]

Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

[Elvis (return-desender)]

It is much easier to find zombie tasks if you just do:

ps -ef | grep defunct

top - 23:58:49 up 8 days, 23:18, 4 users, load average: 2.36, 2.25, 2.17
Tasks: 628 total, 3 running, 194 sleeping, 0 stopped, 431 zombie

nwayno@bart:~$ ps -ef | grep defunct
nwayno 324 5807 0 Mar31 ? 00:00:00 [pidgin] <defunct>
nwayno 336 5807 0 Mar31 ? 00:00:00 [pidgin] <defunct>
nwayno 343 5807 0 Mar31 ? 00:00:00 [pidgin] <defunct>
nwayno 354 5807 0 Mar31 ? 00:00:00 [pidgin] <defunct>
nwayno 364 5807 0 Mar31 ? 00:00:00 [pidgin] <defunct>
nwayno 368 5807 0 Mar31 ? 00:00:00 [pidgin] <defunct>
nwayno 404 5807 0 Mar31 ? 00:00:00 [pidgin] <defunct>
nwayno 415 5807 0 Mar31 ? 00:00:00 [pidgin] <defunct>
nwayno 418 5807 0 Mar31 ? 00:00:00 [pidgin] <defunct>
nwayno 431 5807 0 Mar31 ? 00:00:00 [pidgin] <defunct>
nwayno 443 5807 0 Mar31 ? 00:00:00 [pidgin] <defunct>
nwayno 447 5807 0 Mar31 ? 00:00:00 [pidgin] <defunct>
nwayno 468 5807 0 Mar31 ? 00:00:00 [pidgin] <defunct>

[StevenD57 (tevend)]

I am running ubuntu 14.04 and pidgin 2.10.11 and I currently have 1539 zombie processes from pidgin after an uptime of 72 days.
I am also experiencing pidgin dropping out of my Sipe connection quite frequently and then having to press the "reconnect" button many times to be able to rejoin my conversations.
Is there actually any solution to this? I see lots of people reporting the same problem but I do not see any actual solutions posted or even any replies from pidgin package maintianers indicating any interest in solving this problem.

[Tom Mittelstaedt (1358-s)]

Same here. Pidgin spwans an enormous amount of zombies. 134 in 5 days

$ uname -a && uptime && ps -ef | grep pidgin | grep defunct | wc -l
Linux 3.19.0-25-generic #26-Ubuntu SMP Fri Jul 24 21:17:31 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
 15:31:56 up 5 days, 21:31, 2 users, load average: 0,18, 0,63, 0,96
134

[winky (fishysolutions-deactivatedaccount)]

bash$ ps -ef | grep [p]idgin\] | cut -d' ' -f2- | sort -k4
   12709 29794 0 Jan05 ? 00:00:00 [pidgin] <defunct>
   12710 29794 0 Jan05 ? 00:00:00 [pidgin] <defunct>
   12712 29794 0 Jan05 ? 00:00:00 [pidgin] <defunct>
   12938 29794 0 Jan05 ? 00:00:00 [pidgin] <defunct>
   10775 29794 0 Jan06 ? 00:00:00 [pidgin] <defunct>
   10776 29794 0 Jan06 ? 00:00:00 [pidgin] <defunct>
   10778 29794 0 Jan06 ? 00:00:00 [pidgin] <defunct>
   32397 29794 0 Jan07 ? 00:00:00 [pidgin] <defunct>
   32398 29794 0 Jan07 ? 00:00:00 [pidgin] <defunct>
   32416 29794 0 Jan07 ? 00:00:00 [pidgin] <defunct>
   21546 29794 0 Jan08 ? 00:00:00 [pidgin] <defunct>
   21551 29794 0 Jan08 ? 00:00:00 [pidgin] <defunct>
   21561 29794 0 Jan08 ? 00:00:00 [pidgin] <defunct>
     639 29794 0 Jan09 ? 00:00:00 [pidgin] <defunct>
     649 29794 0 Jan09 ? 00:00:00 [pidgin] <defunct>
     657 29794 0 Jan09 ? 00:00:00 [pidgin] <defunct>
   11440 29794 0 Jan10 ? 00:00:00 [pidgin] <defunct>
   11441 29794 0 Jan10 ? 00:00:00 [pidgin] <defunct>
   11450 29794 0 Jan10 ? 00:00:00 [pidgin] <defunct>
   30266 29794 0 Jan10 ? 00:00:00 [pidgin] <defunct>
   30267 29794 0 Jan10 ? 00:00:00 [pidgin] <defunct>
   30268 29794 0 Jan10 ? 00:00:00 [pidgin] <defunct>
   14653 29794 0 Jan11 ? 00:00:00 [pidgin] <defunct>
   14654 29794 0 Jan11 ? 00:00:00 [pidgin] <defunct>
   14655 29794 0 Jan11 ? 00:00:00 [pidgin] <defunct>
   14864 29794 0 Jan11 ? 00:00:00 [pidgin] <defunct>
   14868 29794 0 Jan11 ? 00:00:00 [pidgin] <defunct>

bash$ ps -ef | grep [p]idgin\] | cut -d' ' -f2- | sort -k4 | wc -l
27

bash$ lsb_release -d ; uname -r ; uptime -p ; pidgin -v
Description: Ubuntu 16.04.1 LTS
4.4.0-57-generic
up 2 weeks, 5 days, 4 hours, 56 minutes
Pidgin 2.10.12 (libpurple 2.10.12)

bash$ journalctl | grep 'Suspending system\.' | wc -l
22

bash$ journalctl | grep 'Waking up' | wc -l
22

[Tharrrk (tharrrk)]

Same here, Xenial 16.04 LTS (KDE/Neon)

# uname -r; dpkg -l|grep -E '^ii[[:space:]]+(pidgin|libpurple|glib-networking|libglib)'|while read s n v rest; do echo "$n: $v"; done
4.4.0-64-lowlatency
glib-networking:amd64: 2.48.2-1~ubuntu16.04.1
glib-networking-common: 2.48.2-1~ubuntu16.04.1
glib-networking-services: 2.48.2-1~ubuntu16.04.1
libglib2.0-0:amd64: 2.48.2-0ubuntu1
libglib2.0-0:i386: 2.48.2-0ubuntu1
libglib2.0-bin: 2.48.2-0ubuntu1
libglib2.0-data: 2.48.2-0ubuntu1
libglibmm-2.4-1v5:amd64: 2.46.3-1
libpurple-bin: 1:2.10.12-0ubuntu5.1
libpurple0: 1:2.10.12-0ubuntu5.1
pidgin: 1:2.10.12-0ubuntu5.1
pidgin-data: 1:2.10.12-0ubuntu5.1
pidgin-encryption: 3.1-1.1
pidgin-extprefs: 0.7-2ubuntu1
pidgin-hangouts: 1.0+hg20161222-1~webupd8~xenial0
pidgin-hotkeys: 0.2.4-1.2ubuntu1
pidgin-libnotify: 0.14-9ubuntu2
pidgin-plugin-pack: 2.7.0-2
pidgin-privacy-please: 0.7.1-3
pidgin-sipe: 1.20.1-1
pidgin-themes: 0.2-1

[Thomas A. F. Thorne (tafthorne)]

Well I am seeing something odd in Pidgin.

$ ps -elf | grep defunct | wc -l
121
$ ps -elf | grep defunct | grep pidgin | wc -l
120

(One of the 'defunct' hits is the grep)

$ pidgin --version
Pidgin 2.10.12 (libpurple 2.10.12)

I have IRC, and XMPP to GoogleMail (Hangouts / Talk) configured and active in Pidgin at the moment. Someone else mentioned Google Hangouts and I can easily live without for a few days to see if the problem goes away. Account Disabled.

I also have Facebook (XMPP), Skype (D-Bus) and Skype setup with Pidgin but only the IRC and googlemail chat accounts were enabled when this error was noticed. I shall try closing Pidgin to clean up the defuncts.

[Thomas A. F. Thorne (tafthorne)]

Closed down Pidgin. Waited a few seconds for all the defunct processes to go away. Restarted Pidgin. Probably only a minute later before the first defunct process has arrived.

I am signed into 4 IRC channels automatically on startup. I have tried to send my identify command to the NickServ but other than that I have not made any chats yet.

[Thomas A. F. Thorne (tafthorne)]

It has been noted on the developer site for Pidgin that 1 defunct is normal for DNS lookups. https://developer.pidgin.im/ticket/15617#comment:11

The rest I have seen might come from failed attempts to connect to chat services. https://developer.pidgin.im/ticket/15617#comment:13 mentions you get one for every connect attempt. I did have a network issue last night that would have blocked IPv4 access for several hours. That might explain what i have seen. If I get further defunct processes without any signs of network disruption I will report back, else assume that it is provoked by network issues.

[Quinn Balazs (qbalazs)]

Alright, that seems fair. I'd guess much like you guessed that the rest
came from failed connection attempts during that period where the network
was unavailable. Yes, Pidgin having one defunct process for DNS lookups is
totally normal (and honestly something we all wish they'd put in the damn
documentation).

On Wed, Apr 26, 2017 at 7:45 AM, Thomas A. F. Thorne <
<email address hidden>> wrote:

> It has been noted on the developer site for Pidgin that 1 defunct is
> normal for DNS lookups.
> https://developer.pidgin.im/ticket/15617#comment:11
>
> The rest I have seen might come from failed attempts to connect to chat
> services. https://developer.pidgin.im/ticket/15617#comment:13 mentions
> you get one for every connect attempt. I did have a network issue last
> night that would have blocked IPv4 access for several hours. That might
> explain what i have seen. If I get further defunct processes without
> any signs of network disruption I will report back, else assume that it
> is provoked by network issues.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1245666
>
> Title:
> Pidgin is creating zombies
>
> Status in Pidgin:
> Unknown
> Status in pidgin package in Ubuntu:
> Confirmed
> Status in pidgin package in Fedora:
> Unknown
>
> Bug description:
> After upgrading to Kubuntu 13.10 pidgin is constantly creating new
> zombies.
>
> E.g. after an uptime of roughly 4 hours:
> $ ps aux | grep Z
> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
> cm 2589 0.0 0.0 0 0 ? Z 17:46 0:00
> [pidgin] <defunct>
> cm 3045 0.0 0.0 0 0 ? Z 17:47 0:00
> [pidgin] <defunct>
> cm 3106 0.0 0.0 0 0 ? Z 17:48 0:00
> [pidgin] <defunct>
> cm 3236 0.0 0.0 0 0 ? Z 17:50 0:00
> [pidgin] <defunct>
> cm 5760 0.0 0.0 0 0 ? Z 17:54 0:00
> [pidgin] <defunct>
> cm 5788 0.0 0.0 0 0 ? Z 18:02 0:00
> [pidgin] <defunct>
> cm 6405 0.0 0.0 0 0 ? Z 18:12 0:00
> [pidgin] <defunct>
> cm 6501 0.0 0.0 0 0 ? Z 18:22 0:00
> [pidgin] <defunct>
> cm 6519 0.0 0.0 0 0 ? Z 18:32 0:00
> [pidgin] <defunct>
> cm 6543 0.0 0.0 0 0 ? Z 18:42 0:00
> [pidgin] <defunct>
> cm 6580 0.0 0.0 0 0 ? Z 18:52 0:00
> [pidgin] <defunct>
> cm 6619 0.0 0.0 0 0 ? Z 19:02 0:00
> [pidgin] <defunct>
> cm 6645 0.0 0.0 0 0 ? Z 19:12 0:00
> [pidgin] <defunct>
> cm 6672 0.0 0.0 0 0 ? Z 19:22 0:00
> [pidgin] <defunct>
> cm 6691 0.0 0.0 0 0 ? Z 19:32 0:00
> [pidgin] <defunct>
> cm 6757 0.0 0.0 0 0 ? Z 19:42 0:00
> [pidgin] <defunct>
> cm 6846 0.0 0.0 0 0 ? Z 19:52 0:00
> [pidgin] <defunct>
> cm 6869 0.0 0.0 0 0 ? Z 20:01 0:00
> [pid...

[amk (9-launchpad-mikus-sk)]

16.04.3 LTS Pidgin 2.10.12 (libpurple 2.10.12) also impacted.

The notes above consider this situation normal, but it is not. There is no reason for the app to skip collecting the spawned processes after failed DNS or connection attempt.

https://developer.pidgin.im/ticket/15617 is still in new status.

[dx (dx)]

Hi, pidgin dev here, got a report from an ubuntu artful user that it generated a bunch of zombie processes.

I noticed a patch named "hg-remove-SIGCHLD-handler.patch" that only exists in ubuntu and not in debian, and seems to be a backport of https://bitbucket.org/pidgin/main/commits/161320946afdd6bc331026fa774e1f7bc680f12c

It's from the "default" branch (unreleased 3.x) instead of release-2.x.y, and certainly not intended for release-2.x.y.

Quoting the commit, it seems to rely on the assumption that "DNS processes are already reaped in libpurple". This was true for the default branch around 2012 (I asked the author, apparently some queue stuff was introduced a few commits earlier) and is sort-of-true for the default branch now that it uses GResolver which is thread-based instead of fork-based.

It's not a safe assumption for release-2.x.y in its current state, it needs child process reaping.

I recommend removing this patch.

[Gianfranco Costamagna (costamagnagianfranco)]

Hello, thanks! I removed the patch and uploaded the package!

[Launchpad Janitor (janitor)]

This bug was fixed in the package pidgin - 1:2.12.0-1ubuntu4

---------------
pidgin (1:2.12.0-1ubuntu4) bionic; urgency=medium

  * Explicitly enable python3 in rules file
  * Remove hg-remove-SIGCHLD-handler.patch: Useless now
    This patch is now causing an issue with zombie processes.
    LP: #1245666.
    Thanks dx for the hint and patch, and tsimonq2/sarnold for the
    pings!

 -- Gianfranco Costamagna <email address hidden> Thu, 08 Mar 2018 19:29:36 +0100