Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 353599 - dev-python/pygtk main loop uses 100% cpu when apps receive SIGCHLD
Summary: dev-python/pygtk main loop uses 100% cpu when apps receive SIGCHLD
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: All All
: High major (vote)
Assignee: Gentoo Linux Gnome Desktop Team
Depends on:
Reported: 2011-02-03 10:27 UTC by Antoine Martin
Modified: 2011-02-04 09:19 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Antoine Martin 2011-02-03 10:27:55 UTC
A previous patch to pygtk was misapplied in both 2.17 (stable) and 2.22 (~unstable). This causes the main loop to go into a spin.

The upstream bug is here:

It includes a patch which I have successfully tested against pygtk 2.22 on ~amd64.
Debian has aleady applied a patch for 2.17:

This affects many pygtk based applications.
This will affect all platforms that provide HAVE_PYSIGNAL_SETWAKEUPFD (which means every platform gentoo runs on AFAIK)

Reproducible: Always

Steps to Reproduce:
import signal
import gtk

signal.signal(signal.SIGCHLD, lambda *args: None)

Run it, send it SIGCHLD.
Actual Results:  
CPU usage goes to 100%.

Expected Results:  
Not go into a spin!

Simply drop the patch into files/ and add it to the ebuild, problem solved.
Comment 1 Pacho Ramos gentoo-dev 2011-02-03 21:42:25 UTC
+*pygtk-2.22.0-r1 (03 Feb 2011)
+  03 Feb 2011; Pacho Ramos <> +pygtk-2.22.0-r1.ebuild,
+  +files/pygtk-2.22.0-wakeupfd-fix.patch:
+  Fix 100% CPU load when apps receive SIGCHLD, bug #353599 by Antoine Martin.
Comment 2 Antoine Martin 2011-02-04 07:01:20 UTC

Shouldn't this be applied to stable too?
(that's why I included the link to the debian patch which is for 2.17)
Comment 3 Pacho Ramos gentoo-dev 2011-02-04 09:19:10 UTC
I don't think it's needed as pygtk-2.22* will be stabilized with gnome 2.32 (that shouldn't take too much time). Also, our common way for handling these problems is to commit fixes to testing and stabilize fixed packages after a few days for allowing its testing