Bug 902401

Summary: importing Gtk crashes the app on headless system
Product: [Fedora] Fedora Reporter: Martin Sivák <msivak>
Component: gtk3Assignee: Matthias Clasen <mclasen>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 19CC: ccecchi, mclasen, walters
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-04-08 20:50:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
optionally disable the implicit Gtk.init using env variable none

Description Martin Sivák 2013-01-21 15:24:12 UTC 
Description of problem:

calling the following line from Python

> from gi.repository import Gtk

immediately tries to initialize Gtk. If the system has no display output or no X, it fails with

RuntimeError: Gtk couldn't be initialized

This behaviour is unacceptable for a library as it makes it impossible to import
a file with this line from anywhere outside of X environment (unittest or rpmbuild for example).

Version-Release number of selected component (if applicable):

rawhide+koji repo on the 21st of January 2013

gtk3-devel-3.7.6-1
pygobject3-3.7.4-1
gobject-introspection-devel-1.35.4-1

How reproducible:

Always

Steps to Reproduce:

[msivak@euryale initial-setup]$ DISPLAY= python
Python 2.7.3 (default, Jul 24 2012, 10:05:38) 
[GCC 4.7.0 20120507 (Red Hat 4.7.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from gi.repository import Gtk

Actual results:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.7/site-packages/gi/importer.py", line 76, in load_module
    dynamic_module._load()
  File "/usr/lib64/python2.7/site-packages/gi/module.py", line 224, in _load
    overrides_modules = __import__('gi.overrides', fromlist=[self._namespace])
  File "/usr/lib64/python2.7/site-packages/gi/overrides/Gtk.py", line 1533, in <module>
    raise RuntimeError("Gtk couldn't be initialized")
RuntimeError: Gtk couldn't be initialized


Expected results:

No output and Gtk initialized with the first Gtk call (or using Gtk.init() which is currently unavailable)
Comment 1 Matthias Clasen 2013-01-22 00:21:02 UTC 
This has been the traditional behaviour of the gtk python bindings since forever, afaik
Comment 2 Martin Sivák 2013-01-22 11:36:57 UTC 
Well, that may be, but it still is wrong.

All the other languages I checked have separate init call. There is even Gtk.init available in Python, it just gets called too early.

/usr/lib64/python2.7/site-packages/gi/overrides/Gtk.py contains this:

initialized, argv = Gtk.init_check(sys.argv)
sys.argv = list(argv)
if not initialized:
    raise RuntimeError("Gtk couldn't be initialized")

I understand the reasons for the exception (fallback to different UI mode), but any Python library that has side-effects in it's initialization is really wrong. The reason is we have no equivalent of .h files, but still want to access constants and control when the initialization happens (and if it should happen at all).

Moreover, tools like python-nose (unittest launcher) have to import files to take a look at the definitions there, but are not executing anything. Gtk's current behaviour breaks it.

Is it possible to modify Gtk so it does not throw an exception when it is imported and (if such compatibility is really needed) tries the init silently again when a library call really needs it?

If anybody needs the detection, he should call Gtk.init explicitly and catch the error where it fits his project codebase.

The exception used in overrides is way too generic and it is not really nice to have such a generic try/except block around all imports (because it can be somebody else's library that accesses Gtk). And import Gtk can be in lots of files, on the other hand.. Gtk.init is usually a single line in the project.
Comment 3 Matthias Clasen 2013-01-22 12:27:35 UTC 
(In reply to comment #2)

> 
> Is it possible to modify Gtk so it does not throw an exception when it is
> imported and (if such compatibility is really needed) tries the init
> silently again when a library call really needs it?
>

I don't know, I don't do python. But I am very much convinced that compatibility is needed.
Comment 4 Martin Sivák 2013-01-22 13:34:18 UTC 
Created attachment 685139 [details]
optionally disable the implicit Gtk.init using env variable

This is probably the least intrusive change that will add the behaviour we want without compromising the backward compatibility.

I still think this should be changed properly in the future, but this is the best we can do at this moment.
Comment 5 Colin Walters 2013-01-22 15:07:46 UTC 
This should really be filed upstream with pygobject.  I tried searching the bugzilla there but couldn't find anything.  Making one now.
Comment 6 Colin Walters 2013-01-22 15:11:39 UTC 
https://bugzilla.gnome.org/show_bug.cgi?id=692300
Comment 7 Fedora End Of Life 2013-04-03 16:12:14 UTC 
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
Comment 8 Matthias Clasen 2013-04-08 20:50:39 UTC 
fixed upstream and in 3.8.0