Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#3981 defect closed invalid (invalid)

bug in glib2/gtk2 reactor

Reported by: tdelaet Owned by:
Priority: high Milestone:
Component: core Keywords:
Cc: Branch:
Author: Launchpad Bug:

Description

In attach you find a test file. In the test, I execute an external command ('/bin/echo test') using twisted.internet.utils.getProcessOutput().

If you execute the file with the standard reactor, everything works fine. However, if you comment out the first two lines (they enable the glib2 reactor) and test it again, CPU usage goes to 100% and stays at that level.

Some observations:

  • When I use a deferred without external process involved (I tested this with callLater), everything works fine.
  • The server does not go to 100% cpu usage on startup, only when the external processes ended.

Attachments (1)

test.py (510 bytes) - added by tdelaet 5 years ago.
Test file that reproduces this problem

Download all attachments as: .zip

Change History (10)

Changed 5 years ago by tdelaet

Test file that reproduces this problem

comment:1 in reply to: ↑ description Changed 5 years ago by tdelaet

  • Author thomas@delaet.org deleted

I should also mention that I am using Fedora 11, using Python 2.6 and Twisted 8.2.0.

Replying to tdelaet:

In attach you find a test file. In the test, I execute an external command ('/bin/echo test') using twisted.internet.utils.getProcessOutput().

If you execute the file with the standard reactor, everything works fine. However, if you comment out the first two lines (they enable the glib2 reactor) and test it again, CPU usage goes to 100% and stays at that level.

Some observations:

  • When I use a deferred without external process involved (I tested this with callLater), everything works fine.
  • The server does not go to 100% cpu usage on startup, only when the external processes ended.

comment:2 follow-up: Changed 5 years ago by therve

  • Resolution set to invalid
  • Status changed from new to closed

This is a bug in glib. I believe it's fixed in Ubuntu with a package patch, I guess it's not in Fedora. What's your version of glib?

comment:3 in reply to: ↑ 2 Changed 5 years ago by tdelaet

Replying to therve:

This is a bug in glib. I believe it's fixed in Ubuntu with a package patch, I guess it's not in Fedora. What's your version of glib?

2.20.4. I try to test the code on Ubuntu. Tnx!

comment:4 Changed 5 years ago by andrewbird

  • Resolution invalid deleted
  • Status changed from closed to reopened

This issue still persists in Fedora 11,12 OpenSuSE 11.1 etc. I raised a bug in Fedora https://bugzilla.redhat.com/show_bug.cgi?id=562825 but the guys there want the twisted people to progress with glib2 project. I know very little of this, since I'm an application programmer using twisted in Betavine Mobile Connect project, but the problem is hitting us hard on platforms other than Ubuntu. Can anyone here explain what the problem is and help to get the upstream fixed?

Thanks,

Andrew

comment:5 Changed 5 years ago by exarkun

This looks a lot like #3096. A comment there suggests that this is the upstream bug report: <http://bugzilla.gnome.org/show_bug.cgi?id=481569>. <https://bugzilla.gnome.org/show_bug.cgi?id=481569#c82> seems to indicate the revision in which it was fixed.

comment:6 Changed 4 years ago by Rotund

  • Resolution set to invalid
  • Status changed from reopened to closed

Bug was properly reported upstream and has since been fixed. The problem now exists with the packagers for the various OS versions.

If you can provide a patch that properly works under versions of PyGObject with and without the upstream fix, we would certainly consider it.

Make sure to update the redhat bug tracker with a link to https://bugzilla.gnome.org/show_bug.cgi?id=481569 as this is really a PyGObject bug. You may want to add a bug for SUSE as well.

My personal opinion is to either package PyGObject for the affected platforms or bug the distros repeatedly as it cannot be easily worked around by twisted.

comment:7 Changed 4 years ago by glyph

(A minor point of order: I'd say that "invalid" should be used for bugs where the description was really in error; in this case, it's a valid bug, but it's not our bug, so we won't fix it.)

comment:8 Changed 4 years ago by glyph

(Oops. Hence "wontfix" would be the appropriate resolution.)

comment:9 Changed 4 years ago by <automation>

  • Owner glyph deleted
Note: See TracTickets for help on using tickets.