After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 689208 - signal handling issues with 3.7 issues
signal handling issues with 3.7 issues
Status: RESOLVED NOTABUG
Product: pygobject
Classification: Bindings
Component: general
unspecified
Other Linux
: High major
: ---
Assigned To: Martin Pitt
Python bindings maintainers
Depends on:
Blocks: 699925
 
 
Reported: 2012-11-28 10:27 UTC by Michael Vogt
Modified: 2013-05-08 10:48 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Michael Vogt 2012-11-28 10:27:16 UTC
There appears to be a regression with signal handling with python-gi 3.7.

I don't have a minimal test-case (yet) but you can reproduce on a ubuntu system with:

$ aptd --dummy --session-bus
and then run
$ killall -TERM aptd

This works fine with pygobject 3.4 and the daemon catches the signal and
quits. But the signal does not make it anymore in 3.7.
Comment 1 Martin Pitt 2012-11-28 10:30:23 UTC
This is a regression, presumably from http://git.gnome.org/browse/pygobject/commit/?id=191cf45a . Bumping priority.
Comment 2 Martin Pitt 2012-11-28 11:45:48 UTC
We were investigating this on IRC. Indeed using the signal module (as aptdaemon does) together with GLib main loops seems to be somewhat undefined, as GLib does its own signal handling. It is generally recommended to use GLib.unix_signal_add(), as done in https://code.launchpad.net/~mvo/aptdaemon/use-glib-unix-signal-handling/+merge/136626 .

For example, if I run this test script


---------------- 8< ------------
from gi.repository import GLib
import signal, sys

def _on_signal(signum, frame):
    sys.stderr.write('XXXX _on_signal\n')
    global handler_called
    handler_called = True
    loop.quit()

signal.signal(signal.SIGTERM, _on_signal)

loop = GLib.MainLoop()
loop.run()
assert handler_called
---------------- 8< ------------

... with 3.4 and SIGTERM it, it aborts, but with a KeyboardInterrupt exception instead of calling the handler. With 3.7 nothing happens at all at first; only when pressing Ctrl+C after the SIGTERM, I finally see the "XXXX _on_signal".

This is related to dropping pygobject's signal watching from the static bindings, which has always interfered with what user applications do (see bug 622084).

So I am wondering if we should try and replicate the old behaviour with the overrides (which apparently is impossible with overrides, we'd need to do it in the static binding part), or just call it an ABI break and do what the real GLib behaviour is doing (and ask applications to use GLib.unix_signal_add()).

Opinions?
Comment 3 Martin Pitt 2013-02-27 16:37:49 UTC
This was fixed in aptd long ago by using GLib.unix_signal_add(), and we don't really want to divert from what glib is doing for bindings.