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:
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...
Where are those files supposed to be? Perhaps a permission/SELinux problem?
~/.libreoffice/3/user/extensions/{shared,bundled}/registry/*/backenddb.xml
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.
After some updates to other stuff and various reboots it now works without a hitch.
*** Bug 667638 has been marked as a duplicate of this bug. ***
As a workaround: it is perfectly safe to remove ~/.libreoffice/3/user/extensions -- it will be recreated on the next start.
(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...
removing ~/.libreoffice/3/user/extensions fixed it for me
(In reply to comment #9) > removing ~/.libreoffice/3/user/extensions fixed it for me It fixed the problem here too.
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.
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.
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
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 .
It does work now.