OpenLP fails to start if python-uno throws an exception

[Zachary Steele]

As of OpenLP 2.0.2, the startup code is unable to handle external errors which cause python-uno to throw exceptions. In this particular instance,

Current behavior:
After running OpenLP with the option "-l debug", the following stack trace is logged:
 File "/usr/bin/openlp", line 44, in <module>
    main()
  File "/usr/share/openlp/openlp/core/__init__.py", line 342, in main
    sys.exit(app.run(qt_args))
  File "/usr/share/openlp/openlp/core/__init__.py", line 150, in run
    self.mainWindow = MainWindow(self)
  File "/usr/share/openlp/openlp/core/ui/mainwindow.py", line 685, in __init__
    self.pluginManager.find_plugins(plugin_path, self.pluginHelpers)
  File "/usr/share/openlp/openlp/core/lib/pluginmanager.py", line 121, in find_plugins
    plugin = p(plugin_helpers)
  File "/usr/share/openlp/openlp/plugins/custom/customplugin.py", line 54, in __init__
    self.manager = Manager(u'custom', init_schema)
  File "/usr/share/openlp/openlp/core/lib/db.py", line 229, in __init__
    self.session = init_schema(self.db_url)
  File "/usr/share/openlp/openlp/plugins/custom/lib/db.py", line 61, in init_schema
    session, metadata = init_db(url)
  File "/usr/share/openlp/openlp/core/lib/db.py", line 64, in init_db
    engine = create_engine(url, poolclass=NullPool)
  File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/__init__.py", line 321, in create_engine
    return strategy.create(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/strategies.py", line 64, in create
    dbapi = dialect_cls.dbapi(**dbapi_args)
  File "/usr/lib/python2.7/dist-packages/sqlalchemy/dialects/sqlite/pysqlite.py", line 276, in dbapi
    from pysqlite2 import dbapi2 as sqlite
  File "/usr/lib/python2.7/dist-packages/uno.py", line 334, in _uno_import
    "%s (or '%s.%s' is unknown)" % (py_import_exc, name, x)
AttributeError: 'exceptions.ImportError' object has no attribute 'with_traceback'

Expected behavior:
OpenLP should provide the user with an error dialog before crashing with a message such as "OpenLP is unable to connect to the LibreOffice database".
If it is reasonable, add workaround code to allow OpenLP to continue without using the plugin which triggered the external exception.

Environment notes:
OpenLP 2.0.2
Ubuntu 12.04
Libre Office 4.1.1

[Raoul Snyman (raoul-snyman)]

Did OpenLP's interface show up at all when this exception occurred?

[Jon Arnold (jonarnoldsemail)]

Raoul-

I had the same problem. It seems to be related to the python-uno package in the LibreOffice PPA (I was trying to upgrade LibreOffice). It did not show the interface, but it did show the splash logo and when I opened another instance, a pop-up came up saying OpenLP was already running.

I was able to get it running again by installing python3-uno instead of python-uno (https://bugs.launchpad.net/df-libreoffice/+bug/1222823/comments/4). Perhaps it is related to that bug (https://bugs.launchpad.net/df-libreoffice/+bug/1222823).

I've attached my log from before I installed the new package.

[Zachary Steele (zcsteele)]

Jon described the GUI behavior exactly as is occurs on my system. I'll try installing python3-uno and see if that is a viable workaround.

Regardless of whether or not the workaround is functional, the startup code should have at least one exception handler so OpenLP can perform a clean shutdown (and maybe give the user a helpful popup message).

[Tim Bentley (trb143)]

Please check your setups. OpenLP 2.0.2 is python 2 and LibreOffice 4 is Python 3. To use LibreOffice 4.x you need to be running OpenLP 2.x which is unstable at present

They should not be able to see each other as the packages are on different class paths.

From the error message you are invoking the new Python 3 uno module so how are you calling it from python 2.

This module has only been tested and supported on Python 3.

[Zachary Steele (zcsteele)]

The python3-uno package is not installed on my system; it would seem that the package for LibreOffice 4 is referencing the wrong dependency. I'll try completely downgrading LibreOffice to version 3 to see if that fixes OpenLP.

[Oliver Wieland (oliwee)]

Could you please try this branch

https://code.launchpad.net/~oliwee/openlp/bug-1223644

to see if openlp starts without exception?

[Oliver Wieland (oliwee)]

Please note that the branch above is only a dirty hack to ignore the plugin. I don't have LibreOffice 4.1 to test it, so it would be glad if someone with LO 4.1 would try the hack.
Thank you

[Raoul Snyman (raoul-snyman)]

Guys, please note that this is actually a packaging issue with the LibreOffice PPA. See http://openlp.org/en/blog/2013/09/13/openlp-libreoffice-41-and-ubuntu-ppa

[Phill (phill-ridout)]

If Libre Impress is stopping OpenLP from starting, should we not try to work around this? I know its not our issue, but at the end of the day the average user isn't going to see it that way!

[Zachary Steele (zcsteele)]

There are three underlying issues causing this bug to occur:

1) LibreOffice 4 depends on the wrong version of python-uno
2) OpenLP 2.0.2 depends on LibreOffice 3.5 but the dependency is not listed in the package
3) OpenLP crashes if external code throws an exception during init_db in file core/lib/db.py

While root cause #1 is out of our hands, root causes #2 and #3 are entirely within the domain of OpenLP's code and package.

[Zachary Steele (zcsteele)]

Oliver - the patch you created does allow OpenLP to continue launching, but the exception in init_db has the effect of making the song library inaccessible. It's understandable given the error but would still be kinda mysterious to an end-user.

[Raoul Snyman (raoul-snyman)]

The actual problem is that UNO hacks __import__ and causes endless issues for us as developers, which we just smooth over for end users. UNO should not hack __import__.

Also, the original report said that OpenLP should show some error dialog. At the stage that the exception is occurring, /there is no GUI/ and I am doubtful as to OpenLP's ability to show a dialog at such an early phase in the application startup.

Lastly, I am not going to go and program around everyone else's bad bugs. This would mean that OpenLP development would be even slower, and I don't care for cleaning up other people's messes.

[Zachary Steele (zcsteele)]

Proof-of-concept patch for db.py which adds exception handling for external DB dependencies. Since there is no reasonable action to take when the DB is not functional, the patch simply displays an error message and continues to crash as normal.

[Zachary Steele (zcsteele)]

Raoul -

First off, thanks for the work you've done to make the UNO interface function at all, given the state of that package. I can empathize with the rather unenviable position of needing to write writing code dependent on a poorly designed resource.

However, I see a couple of flaws in your argument for not attempting to add code to OpenLP for handling external-related errors.

First off, you make the statement "there is no GUI". OpenLP's GUI is based on Qt; the startup code imports the necessary Python dependencies during the startup process. If the Python interpreter was unable to load those resources it wouldn't even execute the call to create_engine() in the first place. The db.py file I have attached demonstrates this by displaying the Qt popup (without any secondary errors!) during the failure condition.

Secondly, you refuse to to make any attempt to cope with "everyone else's bad bugs". I'm not suggesting that you go around coding patches for every project that has any possible affect on OpenLP; what I am endorsing is "defensive programming" - much akin to the "defensive driving" taught in driving classes. As you can see with my attachment, the additional code is not at all complicated but allows OpenLP to report a meaningful error when LibreOffice (or any potential future replacement) fails.

You said "OpenLP development would be even slower". There is an element of truth to this, but how much time do you really lose by dropping my code in to the project? Also, as an open-source project there is not a hard cap on the number of active participants. I for one have no problem contributing to the codebase but if you really *want* OpenLP to be brittle I won't bother you with such issues in the future.

One point of consideration you may have missed is that of the end-user perspective. While any developer can trace the root cause of something like this back to its (external) source, all a user can see is "I clicked on the program, and then it crashed". The end-user is going to blame OpenLP because that was the program they were trying to run, not LibreOffice (which seems fine from an end-user perspective). I doubt most of the users are even /aware/ that the song database is tied to LibreOffice.

[Joe Mulloy (jdmulloy)]

This bug is also affecting openSUSE 13.1 which comes with LibreOffice 4.1. Uninstalling libreoffice-pyuno fixes the issue but breaks Impress integration and any other software that uses UNO.

Full log attached.

Traceback:

  File "/usr/bin/openlp", line 44, in <module>
    main()
  File "/usr/lib/python2.7/site-packages/openlp/core/__init__.py", line 342, in main
    sys.exit(app.run(qt_args))
  File "/usr/lib/python2.7/site-packages/openlp/core/__init__.py", line 150, in run
    self.mainWindow = MainWindow(self)
  File "/usr/lib/python2.7/site-packages/openlp/core/ui/mainwindow.py", line 685, in __init__
    self.pluginManager.find_plugins(plugin_path, self.pluginHelpers)
  File "/usr/lib/python2.7/site-packages/openlp/core/lib/pluginmanager.py", line 113, in find_plugins
    __import__(modulename, globals(), locals(), [])
  File "/usr/lib/python2.7/site-packages/uno.py", line 269, in _uno_import
    return _g_delegatee( name, *optargs, **kwargs )
  File "/usr/lib/python2.7/site-packages/openlp/plugins/bibles/bibleplugin.py", line 38, in <module>
    from openlp.plugins.bibles.lib import BibleManager, BiblesTab, BibleMediaItem
  File "/usr/lib/python2.7/site-packages/uno.py", line 269, in _uno_import
    return _g_delegatee( name, *optargs, **kwargs )
  File "/usr/lib/python2.7/site-packages/openlp/plugins/bibles/lib/__init__.py", line 456, in <module>
    from manager import BibleManager
  File "/usr/lib/python2.7/site-packages/uno.py", line 269, in _uno_import
    return _g_delegatee( name, *optargs, **kwargs )
  File "/usr/lib/python2.7/site-packages/openlp/plugins/bibles/lib/manager.py", line 47, in <module>
    from openlp1 import OpenLP1Bible
  File "/usr/lib/python2.7/site-packages/uno.py", line 335, in _uno_import
    "%s (or '%s.%s' is unknown)" % (py_import_exc, name, x)
AttributeError: 'exceptions.ImportError' object has no attribute 'with_traceback'
None

[Tim Bentley (trb143)]

Suggest you get LibreOffice to upgrade. This was fixed 2 months back and back ported to effected versions.

[Joe Mulloy (jdmulloy)]

Did LibreOffice fix this? I was planning on patching the version of LibreOffice in openSUSE 13.1 to fix this. Is there a LibreOffice bug related to this? Is there a certian LO version that fixes this? Based on https://bugs.freedesktop.org/show_bug.cgi?id=69070 it seems they've decided that only Python 3 matters and if you're still using Python 2 they don't care about you.

[Joe Mulloy (jdmulloy)]

I downloaded the source for LO 4.1.3.2 and I see that there is a fix for this. I'll backport the fix to the LO version in openSUSE 13.1.

[Samuel Mehrbrodt (sam92)]

I guess this issue can then be closed if it's fixed on the LibreOffice side?