377915 - PyXPCOM race in XULRunner 1.8.0.4

Status: RESOLVED FIXED

(Other Applications Graveyard :: PyXPCOM, defect)

Description

[Nick Nassar]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: http://ftp.mozilla.org/pub/mozilla.org/xulrunner/releases/1.8.0.4/source/xulrunner-1.8.0.4-source.tar.bz2

It appears that there's a race condition in PyXPCOM in XULRunner 1.8.0.4 that causes it not to start if -console isn't passed to the application. Here's a description of the reproducible bug in Democracy/Miro, as well as links to the Democracy/Miro bug report and exact details on how XULRunner was built.

https://develop.participatoryculture.org/trac/democracy/ticket/6803
https://develop.participatoryculture.org/trac/democracy/wiki/BuildingXULRunner


Reproducible: Always

Steps to Reproduce:
1. Installed Democracy 20070417-0.9.6-nightly build (which uses XULRunner 1.8.0.4 built as described below.) as update from 20070413-0.9.6-nightly build (which uses the XULRunner 1.8.0.1 build kit).  Stopped at end of install dialog, added -console and -jsconsole to launch command. App started.

2. Installed as a clean install. Stopped at end of install dialog, added -console and -jsconsole to launch command. App started.

3. Installed as a clean install. Did not stop and add -console and -jsconsole. App *not* started.

4. Installed as a clean install. Stopped at end of install dialog, added -jsconsole to launch command. App *not* started.

5. Installed as a clean install. Stopped at end of install dialog, added -console to launch command. App started.
Actual Results:  
My XULRunner/PyXPCOM app doesn't always start

Expected Results:  
My app always starts :)

Comment 1

[Nick Nassar]

It looks like what's happening is that Module.registerSelf() in xpcom/server/module.py gets called before stdout is set up, resulting in this problem.

Commenting out the print statement (line 70) in registerSelf() fixes the problem.


Index: module.py
===================================================================
RCS file: /cvsroot/mozilla/extensions/python/xpcom/server/module.py,v
retrieving revision 1.6
diff -u -r1.6 module.py
--- module.py	25 Aug 2004 23:02:43 -0000	1.6
+++ module.py	24 May 2007 17:14:58 -0000
@@ -67,7 +67,7 @@
         fname = os.path.basename(location.path)
         for klass in self.components.values():
             reg_contractid = klass._reg_contractid_
-            print "Registering '%s' (%s)" % (reg_contractid, fname)
+            #print "Registering '%s' (%s)" % (reg_contractid, fname)
             reg_desc = getattr(klass, "_reg_desc_", reg_contractid)
             compMgr = compMgr.queryInterface(components.interfaces.nsIComponentRegistrar)
             compMgr.registerFactoryLocation(klass._reg_clsid_,

Comment 2

[Mark Hammond [:markh] [:mhammond]]

I'm not convinced this is a bug in pyxpcom, and not at all convinced a "race condition" is involved.  I think that the problem is that stdout and stderr are invalid file handles in this environment, and Python just uses these invalid handles.  Python makes no promises or attempts to ensure that stdout is valid - if you truly think that is a bug, the bug is in the environment *hosting* python - ie, the application, rather than in Python.  FWIW, python on Windows ships with a 'pythonw.exe', which is a GUI application and also makes no attempt to ensure the standard handles are valid, and therefore will also fail in this same way.  A fairly common strategy is to assign sys.stdout and sys.stderr to your own objects which implement the semantics you desire (eg, to a file, ignoring errors, etc) - but IMO this is not something pyxpcom can do for you - it doesn't know what the ideal semantics are for all applications.

Note that the trunk of pyxpcom catches and ignores all IOError exceptions caused by 'print' statements, and also have a much more reliable logging mechanism, so this problem will not be able to be reproduced there.  It might be worth investigating if we can port some of these changes back to the 1.8 branch.

Comment 3

[Shane Caraveo]

Just as a note, the Komodo startup code deals with getting correct handles.  Once OpenKomodo is available publicly, you can look into nsKomodoApp.cpp and koStart.c to see what we have done.

Comment 4

[Todd Whiteman]

Expired - this was fixed a long time ago by wrapping these Pyxpcom "print" statements in a try/except.