Created attachment 397360 [details]
File: backtrace

Thanks for the bug report.

The backtrace looks pretty strange. There is an ImportError, but there is no 'import gi'...

Reassigning to python, because this import should be somewhere in locale.py or gettext.py, (if ever, as already said, I didn't find it...).


Does this happen everytime?
Which version of python do you have?

Thanks for filing this bug report.

How reproducible is this problem?

What is the output of running these commands?
  ls -al /usr/lib64/python2.6/site-packages/*gi*
  rpm -qf /usr/lib64/python2.6/site-packages/*gi*

Thanks!

(the report is rather unusual; I'm not sure what "gi" is doing there.  I wonder if it's something to do with http://live.gnome.org/PyGI )

I don't know how producable this bug is, but info you wanted is as following:
[xxx@alanine pear]$ ls -al /usr/lib64/python2.6/site-packages/*gi*
total 772
drwxr-xr-x  2 root root  4096 Jan 30 16:03 .
drwxr-xr-x 53 root root 12288 Mar  3 21:15 ..
-rw-r--r--  1 root root 30165 Jan 28 23:15 annotationparser.py
-rw-r--r--  1 root root 28082 Jan 28 23:15 annotationparser.pyc
-rw-r--r--  1 root root 27911 Jan 28 23:15 annotationparser.pyo
-rw-r--r--  1 root root 15216 Jan 28 23:15 ast.py
-rw-r--r--  2 root root 20333 Jan 28 23:15 ast.pyc
-rw-r--r--  2 root root 20333 Jan 28 23:15 ast.pyo
-rw-r--r--  1 root root  4300 Jan 28 23:15 cachestore.py
-rw-r--r--  2 root root  3371 Jan 28 23:15 cachestore.pyc
-rw-r--r--  2 root root  3371 Jan 28 23:15 cachestore.pyo
-rw-r--r--  1 root root   978 Jan 28 23:15 config.py
-rw-r--r--  2 root root   294 Jan 28 23:15 config.pyc
-rw-r--r--  2 root root   294 Jan 28 23:15 config.pyo
-rw-r--r--  1 root root  7934 Jan 28 23:15 dumper.py
-rw-r--r--  2 root root  6208 Jan 28 23:15 dumper.pyc
-rw-r--r--  2 root root  6208 Jan 28 23:15 dumper.pyo
-rw-r--r--  1 root root 14478 Jan 28 23:15 girparser.py
-rw-r--r--  1 root root 13361 Jan 28 23:15 girparser.pyc
-rw-r--r--  1 root root 13288 Jan 28 23:15 girparser.pyo
-rw-r--r--  1 root root 20233 Jan 28 23:15 girwriter.py
-rw-r--r--  1 root root 19000 Jan 28 23:15 girwriter.pyc
-rw-r--r--  1 root root 18915 Jan 28 23:15 girwriter.pyo
-rwxr-xr-x  1 root root 77304 Jan 28 23:15 _giscanner.so
-rw-r--r--  1 root root  5697 Jan 28 23:15 glibast.py
-rw-r--r--  2 root root  7022 Jan 28 23:15 glibast.pyc
-rw-r--r--  2 root root  7022 Jan 28 23:15 glibast.pyo
-rw-r--r--  1 root root 39466 Jan 28 23:15 glibtransformer.py
-rw-r--r--  1 root root 31967 Jan 28 23:15 glibtransformer.pyc
-rw-r--r--  1 root root 31927 Jan 28 23:15 glibtransformer.pyo
-rw-r--r--  1 root root   860 Jan 28 23:15 __init__.py
-rw-r--r--  2 root root   123 Jan 28 23:15 __init__.pyc
-rw-r--r--  2 root root   123 Jan 28 23:15 __init__.pyo
-rw-r--r--  1 root root  2106 Jan 28 23:15 libtoolimporter.py
-rw-r--r--  2 root root  1887 Jan 28 23:15 libtoolimporter.pyc
-rw-r--r--  2 root root  1887 Jan 28 23:15 libtoolimporter.pyo
-rw-r--r--  1 root root  2988 Jan 28 23:15 minixpath.py
-rw-r--r--  2 root root  1932 Jan 28 23:15 minixpath.pyc
-rw-r--r--  2 root root  1932 Jan 28 23:15 minixpath.pyo
-rw-r--r--  1 root root  1380 Jan 28 23:15 odict.py
-rw-r--r--  2 root root  1303 Jan 28 23:15 odict.pyc
-rw-r--r--  2 root root  1303 Jan 28 23:15 odict.pyo
-rw-r--r--  1 root root 13483 Jan 28 23:15 scannermain.py
-rw-r--r--  2 root root 10428 Jan 28 23:15 scannermain.pyc
-rw-r--r--  2 root root 10428 Jan 28 23:15 scannermain.pyo
-rw-r--r--  1 root root  3940 Jan 28 23:15 shlibs.py
-rw-r--r--  2 root root  2246 Jan 28 23:15 shlibs.pyc
-rw-r--r--  2 root root  2246 Jan 28 23:15 shlibs.pyo
-rw-r--r--  1 root root  7790 Jan 28 23:15 sourcescanner.py
-rw-r--r--  1 root root  9509 Jan 28 23:15 sourcescanner.pyc
-rw-r--r--  1 root root  9453 Jan 28 23:15 sourcescanner.pyo
-rw-r--r--  1 root root 26273 Jan 28 23:15 transformer.py
-rw-r--r--  1 root root 22565 Jan 28 23:15 transformer.pyc
-rw-r--r--  1 root root 22501 Jan 28 23:15 transformer.pyo
-rw-r--r--  1 root root  3587 Jan 28 23:15 utils.py
-rw-r--r--  2 root root  2656 Jan 28 23:15 utils.pyc
-rw-r--r--  2 root root  2656 Jan 28 23:15 utils.pyo
-rw-r--r--  1 root root  5165 Jan 28 23:15 xmlwriter.py
-rw-r--r--  1 root root  4980 Jan 28 23:15 xmlwriter.pyc
-rw-r--r--  1 root root  4903 Jan 28 23:15 xmlwriter.pyo


[x@alanine ~]$ rpm -qf /usr/lib64/python2.6/site-packages/*gi*
gobject-introspection-devel-0.6.8-0.1.20100128git.x86_64

Baris: thanks for the information!  I believe what you posted is the contents of
the directory "/usr/lib64/python2.6/site-packages/giscanner" (sorry, my instructions weren't as clear as they could be)

I also have that installed on my F16 i686 box, and I'm able to successfully run the gnome-timer-applet.

So I'm afraid I'm somewhat mystified as to where that error message came from.

Does the applet work for you reliably?

(In reply to comment #5)

> I also have that installed on my F16 i686 box, and I'm able to successfully run
> the gnome-timer-applet.
"F12", this should have read

Actually applet works reliably (well at least stays on panel). But I just reported this bug since something is somehow broken. If you need more info to triage I can help. Here's the list of the directory:

[x@alanine ~]$ ls -l /usr/lib64/python2.6/site-packages/giscanner
total 756
-rw-r--r-- 1 root root 30165 Jan 28 23:15 annotationparser.py
-rw-r--r-- 1 root root 28082 Jan 28 23:15 annotationparser.pyc
-rw-r--r-- 1 root root 27911 Jan 28 23:15 annotationparser.pyo
-rw-r--r-- 1 root root 15216 Jan 28 23:15 ast.py
-rw-r--r-- 2 root root 20333 Jan 28 23:15 ast.pyc
-rw-r--r-- 2 root root 20333 Jan 28 23:15 ast.pyo
-rw-r--r-- 1 root root  4300 Jan 28 23:15 cachestore.py
-rw-r--r-- 2 root root  3371 Jan 28 23:15 cachestore.pyc
-rw-r--r-- 2 root root  3371 Jan 28 23:15 cachestore.pyo
-rw-r--r-- 1 root root   978 Jan 28 23:15 config.py
-rw-r--r-- 2 root root   294 Jan 28 23:15 config.pyc
-rw-r--r-- 2 root root   294 Jan 28 23:15 config.pyo
-rw-r--r-- 1 root root  7934 Jan 28 23:15 dumper.py
-rw-r--r-- 2 root root  6208 Jan 28 23:15 dumper.pyc
-rw-r--r-- 2 root root  6208 Jan 28 23:15 dumper.pyo
-rw-r--r-- 1 root root 14478 Jan 28 23:15 girparser.py
-rw-r--r-- 1 root root 13361 Jan 28 23:15 girparser.pyc
-rw-r--r-- 1 root root 13288 Jan 28 23:15 girparser.pyo
-rw-r--r-- 1 root root 20233 Jan 28 23:15 girwriter.py
-rw-r--r-- 1 root root 19000 Jan 28 23:15 girwriter.pyc
-rw-r--r-- 1 root root 18915 Jan 28 23:15 girwriter.pyo
-rwxr-xr-x 1 root root 77304 Jan 28 23:15 _giscanner.so
-rw-r--r-- 1 root root  5697 Jan 28 23:15 glibast.py
-rw-r--r-- 2 root root  7022 Jan 28 23:15 glibast.pyc
-rw-r--r-- 2 root root  7022 Jan 28 23:15 glibast.pyo
-rw-r--r-- 1 root root 39466 Jan 28 23:15 glibtransformer.py
-rw-r--r-- 1 root root 31967 Jan 28 23:15 glibtransformer.pyc
-rw-r--r-- 1 root root 31927 Jan 28 23:15 glibtransformer.pyo
-rw-r--r-- 1 root root   860 Jan 28 23:15 __init__.py
-rw-r--r-- 2 root root   123 Jan 28 23:15 __init__.pyc
-rw-r--r-- 2 root root   123 Jan 28 23:15 __init__.pyo
-rw-r--r-- 1 root root  2106 Jan 28 23:15 libtoolimporter.py
-rw-r--r-- 2 root root  1887 Jan 28 23:15 libtoolimporter.pyc
-rw-r--r-- 2 root root  1887 Jan 28 23:15 libtoolimporter.pyo
-rw-r--r-- 1 root root  2988 Jan 28 23:15 minixpath.py
-rw-r--r-- 2 root root  1932 Jan 28 23:15 minixpath.pyc
-rw-r--r-- 2 root root  1932 Jan 28 23:15 minixpath.pyo
-rw-r--r-- 1 root root  1380 Jan 28 23:15 odict.py
-rw-r--r-- 2 root root  1303 Jan 28 23:15 odict.pyc
-rw-r--r-- 2 root root  1303 Jan 28 23:15 odict.pyo
-rw-r--r-- 1 root root 13483 Jan 28 23:15 scannermain.py
-rw-r--r-- 2 root root 10428 Jan 28 23:15 scannermain.pyc
-rw-r--r-- 2 root root 10428 Jan 28 23:15 scannermain.pyo
-rw-r--r-- 1 root root  3940 Jan 28 23:15 shlibs.py
-rw-r--r-- 2 root root  2246 Jan 28 23:15 shlibs.pyc
-rw-r--r-- 2 root root  2246 Jan 28 23:15 shlibs.pyo
-rw-r--r-- 1 root root  7790 Jan 28 23:15 sourcescanner.py
-rw-r--r-- 1 root root  9509 Jan 28 23:15 sourcescanner.pyc
-rw-r--r-- 1 root root  9453 Jan 28 23:15 sourcescanner.pyo
-rw-r--r-- 1 root root 26273 Jan 28 23:15 transformer.py
-rw-r--r-- 1 root root 22565 Jan 28 23:15 transformer.pyc
-rw-r--r-- 1 root root 22501 Jan 28 23:15 transformer.pyo
-rw-r--r-- 1 root root  3587 Jan 28 23:15 utils.py
-rw-r--r-- 2 root root  2656 Jan 28 23:15 utils.pyc
-rw-r--r-- 2 root root  2656 Jan 28 23:15 utils.pyo
-rw-r--r-- 1 root root  5165 Jan 28 23:15 xmlwriter.py
-rw-r--r-- 1 root root  4980 Jan 28 23:15 xmlwriter.pyc
-rw-r--r-- 1 root root  4903 Jan 28 23:15 xmlwriter.pyo

Thanks for the information.

I'm afraid I'm somewhat mystified by this report; I can't see where the reference to "gi" came from, and I'm not sure where to investigate further.

Given that it's working for you now, I'm going to close this bug report (marking it with "INSUFFICIENT_DATA", for want of a better state).  I'm sorry that I'm not able to give you a more substantial response at this time.

Please reopen this bug if the problem happens again.

I'm seeing this with pitivi git HEAD on F14 (Rawhide), with a slightly different backtrace.  Any suggestions?  Thanks.

pullcord:cjb~/git/pitivi % bin/pitivi ~/lilypad.xptv
Traceback (most recent call last):
  File "pitivi/ui/exportsettingswidget.py", line 375, in _vcodecSettingsButtonClickedCb
    settings = self.runSettingsDialog(factory, self.vcodecsettings)
  File "pitivi/ui/exportsettingswidget.py", line 335, in runSettingsDialog
    dialog = GstElementSettingsDialog(factory, settings)
  File "pitivi/ui/gstwidget.py", line 191, in __init__
    self._fillWindow()
  File "pitivi/ui/gstwidget.py", line 200, in _fillWindow
    self.widgets["elementsettings"].setElement(self.element, self.properties)
  File "pitivi/ui/gstwidget.py", line 135, in setElement
    self._addWidgets(properties)
  File "pitivi/ui/gstwidget.py", line 151, in _addWidgets
    widget = make_property_widget(self.element, prop, properties.get(prop.name))
  File "pitivi/ui/gstwidget.py", line 103, in make_property_widget
    log.log("gstwidget", "adding %s / %s", val.value_name, val)
  File "pitivi/log/log.py", line 628, in log
    logObject(None, cat, format, *args)
  File "pitivi/log/log.py", line 393, in logObject
    doLog(LOG, object, cat, format, args)
  File "pitivi/log/log.py", line 330, in doLog
    if level > getCategoryLevel(category):
  File "pitivi/log/log.py", line 152, in getCategoryLevel
    registerCategory(category)
  File "pitivi/log/log.py", line 131, in registerCategory
    if category in fnmatch.filter((category, ), spec):
  File "/usr/lib64/python2.6/fnmatch.py", line 42, in filter
    import os,posixpath
ImportError: No module named gi

I think this has nothing to do with this bug, please file one against pitivi.

I disagree.  The parallels are:

* the backtrace appears in a file in /usr/lib64/python2.6, and not in the application code.
* the backtrace is garbled, and trying to import a module that doesn't exist.  This surely shouldn't happen.  The non-existent module ("gi") is the same for both applications, despite it not being referenced by either application.
* the bug is not seen on F12, with *the same application code*.

I conclude that this is most likely to be a python-wide problem in Rawhide.

(In reply to comment #11)
> I conclude that this is most likely to be a python-wide problem in Rawhide.    

I once saw this on F-13. Rerunning the program in the same way and this backtrace was not reproducable anymore...

Chris, can you reproduce this more than just once?

Hi Thomas,

Yes, it's 100% reproducible.  Let me know if you have any debugging ideas.

Thanks.

(In reply to comment #13)
> Hi Thomas,
> 
> Yes, it's 100% reproducible.  Let me know if you have any debugging ideas.

Chris: do you have a recipe for reproducing this that I can try?

(In reply to comment #11)
> I conclude that this is most likely to be a python-wide problem in Rawhide.    
I'm inclined to agree.  Reopening.

CCing walters: Colin: it looks like this relates to gnome introspection - have you seen this before?  any ideas?

*** Bug 576587 has been marked as a duplicate of this bug. ***

For me the recipe is:

  git clone git://git.pitivi.org/pitivi
  cd pitivi
  ./autogen.sh && make
  bin/pitivi

  Choose "import clips", find a video file, then drag it to the timeline
  Choose "render project"
  Choose an output filename
  Click on settings->modify
  Click on export to->video codec->Settings

Then, when the video settings dialog appears, you'll see the traceback.  I've just reproduced this on a different Rawhide machine, so I'm pretty confident you'll hit it too.  This one's 32-bit rather than 64-bit.

Building http://koji.fedoraproject.org/koji/taskinfo?taskID=2076272 now, am interested to know if it resolves it.

No, doesn't seem to change the behavior at all, sorry.

(Perhaps there could be cleanup of the previously-installed files that I need to do independently of upgrading to your RPM?)

I also *uninstalled* gobject-introspection, and that doesn't prevent the traceback either.

Ok, this appears likely to be because our pygobject2 is compiled with --enable-pygi.  I'm going to punt on that for F-13.

Would appreciate testing of 

http://koji.fedoraproject.org/koji/taskinfo?taskID=2077170

*** Bug 577276 has been marked as a duplicate of this bug. ***

(In reply to comment #22)
> Would appreciate testing of 
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=2077170    

Looks good. With the pygobject2-2.21.1-3.fc13.x86_64 there was about 40 % chance that the timer applet would cause the strange ImportError right after logging into Gnome.
With this new build (-4) I have not seen the error appear.

Perhaps I spoke too soon. Though I can't reproduce the error with the timer applet anymore, I received a similar error when using Gajim today:

Traceback (most recent call last):
  File "/usr/share/gajim/src/message_window.py", line 754, in _on_notebook_switch_page
    new_ctrl = self._widget_to_control(notebook.get_nth_page(page_num))
  File "/usr/share/gajim/src/message_window.py", line 624, in _widget_to_control
    if ctrl.widget == widget:
ImportError: No module named gi

Didn't fix it for me either, I'm afraid.  In fact, I now get a traceback earlier than before:

t60p:cjb~/git/pitivi % bin/pitivi                                              
/usr/lib/python2.6/site-packages/gtk-2.0/gtk/__init__.py:40: RuntimeWarning: tp_compare didn't return -1 or -2 for exception
  from gtk import _gtk
ImportError: No module named gi
Traceback (most recent call last):
  File "pitivi/utils.py", line 469, in _registryFeatureAddedCb
    log.warning("utils", "New feature added, invalidating cached factories")
  File "pitivi/log/log.py", line 616, in warning
    warningObject(None, cat, format, *args)
  File "pitivi/log/log.py", line 372, in warningObject
    doLog(WARN, object, cat, format, args)
  File "pitivi/log/log.py", line 330, in doLog
    if level > getCategoryLevel(category):
  File "pitivi/log/log.py", line 152, in getCategoryLevel
    registerCategory(category)
  File "pitivi/log/log.py", line 131, in registerCategory
    if category in fnmatch.filter((category, ), spec):
  File "/usr/lib/python2.6/fnmatch.py", line 42, in filter
    import os,posixpath
ImportError: No module named gi

*** Bug 582047 has been marked as a duplicate of this bug. ***

*** Bug 588465 has been marked as a duplicate of this bug. ***

Created attachment 411699 [details]
clear error

Sorry that this one dropped off my radar.  We should definitely consider nominating this for a F-13 blocker.  Testing of the patch here appreciated, I'll do a quick scratch build.

(In reply to comment #29)
> Created an attachment (id=411699) [details]
> clear error    

I looked through pygobject, looking at the various places where
pygi_type_import_by_g_type is called, and in each case, if a NULL PyObject* is
returned, the code carries on with a fallback, leaving the error unhandled.  So
it does indeed look like we need to clear the error, as your patch does.

I'd like to propose this as a F-13 blocker, because pygobject2 is widely used, and the error here is likely to cause subtle failures in unrelated codepaths.

Risk of regressions from patch: I'd evaluate as "low" - we audited the callers and are confident.

Alternative approaches: We could --disable-pygi

Proposed build is:

http://koji.fedoraproject.org/koji/taskinfo?taskID=2165331

Hmm, I'm unsure how to test this...

This happend randomly and just 4-5 times in total.

Would be installing the koji build and not seeing a crash enought?

I saw the last crash yesterday, the one before, I don't remember anymore, might be 2-3 weeks...

pygobject2-2.21.1-5.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/pygobject2-2.21.1-5.fc13

Proposed Bodhi update:

https://admin.fedoraproject.org/updates/pygobject2-2.21.1-5.fc13

Let me try to characterize this bug a little bit better.

Originally in pygobject2-2.21.1-2 (before Thomas added --enable-pygi from bug 558003), we'd be calling PyErr_SetString when we tried to look for PyGI, but returning success.  The reason this blew up with the _locale import isn't entirely clear to me (but not very important for resolving this blocker right now).  In *some* code paths the code at this point called PyErr_Clear(), but not *all* of them.

Next in pygobject2-2.21.1-3 where --enable-pygi is passed to configure (what's in Fedora 13 now, since I never made an update for -4), we now set an ImportError, and note that that's exactly the exception that the _locale code was catching.  So that's why it appeared to fix the bug.

But we still had the fundamental problem that we were setting a Python exception, but leaving it around for some totally unrelated code to wander into later.  Upstream developer Simon tried to bring some sanity to this in the patch I added in -4 (upstream bug http://bugzilla.gnome.org/607674 ) by removing the exception if pygi support was *disabled*, but he still left the ImportError lying around in the case where it's *enabled* by configure but where pygi is not installed (as is default in Fedora).

Finally, my patch in -5 on top of Simon's, as audited by both me and dmalcolm, ensures that we don't leave any exception set in either the enabled or disabled case.

In summary, my take here is that other operating system creators aren't passing --enable-pygi, and are likely using Simon's patch.  Actually I just checked on patches.ubuntu.com, and that is indeed the case for them.

So in terms of reproducing this, we only have the pitivi case at this point.

What we don't have is a good characterization of all the things that break.  There are 4 duplicates against this bug for 4 different projects.  My guess is there are likely more.

Thinking about this a bit more, my action suggestion here is to pass --disable-pygi and use Simon's patch, and at that point we'll be in sync with what Ubuntu is doing. 

My patch should still go upstream, and for Fedora 14 we should enable pygi, but that's a later discussion.

The -6 build removes my patch and disables pygi.

https://admin.fedoraproject.org/updates/pygobject2-2.21.1-6.fc13

pygobject2-2.21.1-6.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.