This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 666440 - Libreoffice doesn't start: com.sun.star.deployment.DeploymentException: Start tag expected
Libreoffice doesn't start: com.sun.star.deployment.DeploymentException: Start...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: libreoffice (Show other bugs)
rawhide
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: David Tardon
Fedora Extras Quality Assurance
:
: 667638 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-12-30 14:17 EST by Horst H. von Brand
Modified: 2011-02-16 04:25 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-02-16 04:25:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Horst H. von Brand 2010-12-30 14:17:09 EST
Description of problem:
An error window shows up on logging into Gnome:

The application cannot be started. 
com.sun.star.deployment.DeploymentException: Start tag expected, '<' not found
Line: 1
Column: 1

Trying to run e.g. oocalc or oowriter by itself doesn't do anything (no splash screen, nothing at all). There were two processes running (soffice and soffice.bin). After killing those oowriter started (splash screen and the edit window)

Version-Release number of selected component (if applicable):
libreoffice-core-3.3.0.2-2.fc15.x86_64

How reproducible:
No idea. Happened just now (first boot after update)

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 David Tardon 2010-12-30 14:35:23 EST
Hmm. I see this happening when I remove content from one of the backenddb.xml files from package registration dir. I do not understand how that could have happened, because the file, if present, should contain at least XML declaration and a root element, but it cannot hurt to be prepared for the possibility...
Comment 2 Horst H. von Brand 2010-12-30 15:10:58 EST
Where are those files supposed to be? Perhaps a permission/SELinux problem?
Comment 3 David Tardon 2010-12-31 02:14:41 EST
~/.libreoffice/3/user/extensions/{shared,bundled}/registry/*/backenddb.xml
Comment 4 Horst H. von Brand 2010-12-31 14:38:04 EST
I've got a lot of files in there, all oldish (dating from Oct 14 to Dic 17), all -rw-rw-r--, all unconfined_u:object_r:user_home_t:s0.

BTW, after starting oowriter as noted above and then quitting, now the applet showed up (?!)

Re comment 1: Right. Stuff in the user's home can be screwed up arbitrarily.
Comment 5 Horst H. von Brand 2011-01-05 11:43:02 EST
After some updates to other stuff and various reboots it now works without a hitch.
Comment 6 David Tardon 2011-01-06 05:49:49 EST
*** Bug 667638 has been marked as a duplicate of this bug. ***
Comment 7 David Tardon 2011-01-06 05:52:55 EST
As a workaround: it is perfectly safe to remove ~/.libreoffice/3/user/extensions -- it will be recreated on the next start.
Comment 8 Horst H. von Brand 2011-01-16 19:43:11 EST
(In reply to comment #5)
> After some updates to other stuff and various reboots it now works without a
> hitch.

Sorry, wrong. Due to massive borkage in Gnome I switched to XFCE, and the LO applet crashes again (sometimes?). I did as comment 7 suggests, let's see what happens...
Comment 9 Hicham HAOUARI 2011-01-17 07:34:49 EST
removing ~/.libreoffice/3/user/extensions fixed it for me
Comment 10 Horst H. von Brand 2011-01-17 07:46:01 EST
(In reply to comment #9)
> removing ~/.libreoffice/3/user/extensions fixed it for me

It fixed the problem here too.
Comment 11 Caolan McNamara 2011-01-18 06:36:12 EST
caolanm->dtardon: do we have any idea as to why this is happening, a test downgrade and re-upgrade didn't trigger it for me locally anyway.
Comment 12 David Tardon 2011-01-18 08:11:01 EST
dtardon->caolanm: yup, happened there once. I suspect an exception during saving the file. I'm fixing the "load" side to be more tolerant right now and going to look at the "save" part later.
Comment 13 David Tardon 2011-01-20 03:07:54 EST
The backenddb.xml files are only used to get info about extensions changed _since_ the last run; that means that this bug will normally only be observable after an update. AFAICS, if I just recreate the file in case of problems (and add a few safeguards to avoid using empty Reference), the worst that can happen is that there might be some stuff left in some of the registry dirs. On the other side, I really really do not want to just replace one crash with another, so I will not push any fix without (quite) a bit of testing :-)

The alternative is to read all the backenddb.xml files on every start and throw away the whole registry and resync in case of problems.

A way to reproduce this is:
1. cat /dev/null > ~/.libreoffice/3/user/extensions/bundled/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/backenddb.xml
2. touch -d 2000-01-01 ~/.libreoffice/3/user/extensions/bundled/lastsynchronized
3. ooffice
Comment 14 David Tardon 2011-02-10 09:18:47 EST
I've thrown my towel into the ring and commited just Caolan's fix. It's good for most of possible cases anyway.

Should be okay in >=libreoffice-3.3.0.4-4.fc15 .
Comment 15 Horst H. von Brand 2011-02-15 19:41:19 EST
It does work now.

Note You need to log in before you can comment on or make changes to this bug.