[Libreoffice-bugs] [Bug 51252] LO cannot start (reports runtime error with Visual C++ Runtime Library)

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=51252

Stephan Bergmann <sbergman at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Severity|critical                    |blocker
           Priority|highest                     |high
         AssignedTo|libreoffice-bugs at lists.free |sbergman at redhat.com
                   |desktop.org                 |

--- Comment #35 from Stephan Bergmann <sbergman at redhat.com> 2012-07-26 11:18:15 PDT ---
I now understand what is going on, know how to reproduce the problem, and have
found a solution.  There are various factors that are involved:

1  The LO 3.6.0 installation set needs to contain a share/prereg/bundled
directory (containing pre-registered information about bundled extensions, that
is later copied into per-user configuration data, when a user starts LO).  This
is automatically created (via "unopkg sync") for standard installation sets
when those installation sets are created in instsetoo_native.  However, it is
not created for the "make dev-install" installation set (at least not on
Linux), in which case one needs to create it manually to reproduce this
problem, calling "install/program/unopkg sync --verbose" (and watch out for
errors, see next).

2  The LO 3.6.0 build must not be configured --enable-ext-barcode (to include
the Barcode extension as a bundled extension in LO installation sets). 
Registering that extension as a bundled extension is broken.  (Quoting from a
recent mail to Kami:  "The problem (building with --enable-ext-barcode leads to
a broken bundled Barcode extension) is still there with Barcode version 1.3.5,
but I now found out why that is so:  If you start with a fresh user
installation (i.e., after 'rm -rf ~/.config/libreoffice' on Linux), LO tries to
register bundled extensions' components in an environment where bundled
extensions' configuration data is not available.  But Barcode's
barcode-loader.py requires Barcode's Barcode.{xcs,xcu} to be registered (def
getpath: 'config = getconfig( ctx,
'org.openoffice.%sSettings/ConfigNode'%classname )'), which raises an exception
that is unhelpfully swallowed by the try: ... except: debugexception() in
barcode-loader.py.  Using passive component registration for Barcode should
work around that problem.")  That in turn causes "unopkg sync" (whether called
automatically in insetsetoo_native or manually, see above) to silently fail
mid-way, leading to a half-populated share/prereg/bundled that might or might
not allow to reproduce the problem.

3  At least on Linux (other than on Windows) the problem cannot currently be
reproduced because
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=dfbece50ebaeaf45ea3f016d911b5de7c878afc5>
"Make --help and --version work even without $DISPLAY" added UNX-only code that
already creates the service manager very early (at the start of soffice_main),
before Desktop::Init decides whether or not to copy share/prereg/bundled into
the per-user configuration data.  That inadvertently hides this problem.  (But
it leads to issues of its own, like bundled extensions not working properly on
first start.  Those issues are fixed with the fix for this issue, too, namely
to not copy share/prereg/bundled into per-user configuration data, see below) 
To work around that reproduction hindrance, one can temporarily disable that
code in LO 3.6.0, by replacing the "#ifdef UNX" in soffice_main
(desktop/source/app/sofficemain.cxx) with "#if 0".

4  One needs a LO 3.5.x installation (or maybe even older) including some
bundled extension X (that contains UNO components), and that same extension
also as an oxt.  Also, the LO 3.6.0 installation set needs to bundle that
extension (in a higher version), too.  For example, I used the LO 3.5.4 that
comes bundled with Fedora 17 as /usr/lib64/libreoffice/program/soffice.  It
bundles Presenter Console 1.1.0, and the LO 3.6.0 installation set bundles
Presenter Console 1.1.1.  (To produce an oxt of Presenter Console 1.1.0, one
can do "(cd /usr/lib64/libreoffice/share/extensions/presenter-screen && zip -r
~/old-presenter-screen.oxt *)".)

5  Produce a clean starting point by removing any old per-user configuration
data, "rm -rf ~/.config/libreoffice".

6  Start the LO 3.5.x (/usr/lib64/libreoffice/program/soffice), "Tools -
Extension Manager...", "Add...", select the old-presenter-screen.oxt, install
it for the current user only.  (It will replace the bundled version for this
user, the Extension Manager will display it without a lock now.)

7  Make sure the LO 3.6.0 share/prereq/bundled/lastsynchronized is newer than
the corresponding
~/.config/libreoffice/3/user/extensions/bundled/lastsynchronized: "touch
install/share/prereq/bundled/lastsynchronized" (or wherever that installation
is).

8  Now start the LO 3.6.0 soffice.  It will fail to start, reporting some "UNO
Exception: InvalidRegistryException:
file:///.../opt/program/../share/extensions/presenter-screen/components.rdb:
duplicate <implementation
name='com.sun.star.comp.Draw.framework.PresenterScreenJob'>."

9  The problem is that LO is careful to only ever have a single instance of an
extension actually installed for a given user (even if instances of that
extension are installed both bundled and per-user), but the logic to copy
share/prereg/bundled into the per-user configuration data bluntly shortcuts
that and breaks that carefully maintained invariant.  The irony is that
share/prereg/bundled is only an optimization, to save a little time at first
start of LO (when started for the very first time for a user, or after an
upgrade).  For functionality it is not needed---rather, it is demonstrated here
to be harmful, at least in its current implementation (see both this problem
and the issues mentioned under (3)).  Therefore, I propose to fix this by
disabling the share/prereg/bundled feature.  The simplest way to do so for LO
3.6.0 is by adding "if (false)" before the call to copy_bundled_recursive in
Desktop::Init (desktop/source/app/app.cxx).  (That way, compiling does not
cause spurious warnings about unused code.)

10  However, once a user ran into this problem (which in turn can only happen
if she ever ran a LO snapshot up to LO 3.6.0 rc3), her per-user configuration
data is broken, and fixing LO 3.6.0 as per (9) will not help.  In such a case,
it is necessary to manually remove the "extensions" directory from the per-user
configuration data once: "rm -rf ~/.config/libreoffice/3/user/extensions". 
That per-user information about bundled (and shared) extensions is strictly a
cache; it is recreated upon the next start of LO without any loss of
functionality.

11  I explained the above in the context of Linux, but I verified that it all
works exactly the same on Windows.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.