Created attachment 62404 [details] Crash log from the unsuccesful start Problem description: We're using a Lion server (previously a Snow Leopard server — the version doesn't matter) with OD and AFP service. LibreOffice is installed on client computers and users do log in as network users using OD/AFP. (That means, their profile data is stored within their network home folder.) Starting a long time ago (at least from 3.3.0) I'm unable to update libreoffice without losing user profile data. Steps to reproduce: 1. A working LibreOffice installation on a variety of client computers (iMacs) being normally used by various network users without trouble 2. Remove the LibreOffice from the client. 3. Install a new version of LibreOffice (application + slovak localization pack) Current behavior: LibreOffice crashes on launch. Expected behavior: LibreOffice should start up normally. Workaround: Delete the org.libreoffice.script.savedState directory from Saved Application State folder within the users Library folder. Delete the user profile from the users Library folder. — LibreOffice will work normally, but the users loses all his settings/database connections and other stuff… Platform (if different from the browser): Apple OS X Lion (10.7.4) / OS X Lion Server (10.7.4) Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/534.57.2 (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2
Thank you very much for your bug report! I'm not sure how to reproduce the problem (I don't have a MacOS server here, only independed MacOS machines), but maybe someone else can help. I just can say that I don't have seen anything similar when I update a single-machine installation + German langpack. According to the description "Starting a long time ago (at least from 3.3.0) [...]", the Version field should be 3.3.0 release (the Version field should contain the number of the FIRST version which contains the problem, not the last one). Furthermore, I propose 'Installation' as Component, because the problem seems related to installation/update.
Thanks Roman for clarification. I cannot remember when the problem started to appear exactly, so the version number may be misleading. We were only testing LO at that time, but now we've got more users, so it's a real headache. I have tried to reproduce it with local users — and everything works as it should. This looks like a server-only issue.
Created attachment 62952 [details] Crash log of the second crash (while LO is creating a new user profile)
There's also something else: after the user profile is deleted, LO will crash once more (presumably while it's trying to create a new one). Nevertheless the user profile is created and LO works normally on the second launch. This is fully replicable. With every single user on our network I had to come through the same routine: LO doesn't start > delete user profile > start LO > wait a few seconds for a crash > start LO again > works fine.
Created attachment 62953 [details] Crash log of the second crash (while LO is creating a new user profile) Uploaded the correct crash log — sorry for the mistake.
(In reply to comment #2) > Thanks Roman for clarification. I cannot remember when the problem started to > appear exactly, so the version number may be misleading. OK, so, to be sure, I set the version number again to "LibO 3.5.4 release", the version in which you definitely found the issue.
Hi Stephan - new deploymentexception(?) case causing upgrade pain on Mac ? wondered if you're interested; it also seems Rainer has a beautiful tracker in bug#43489 for profile upgrading that may have a number of duplicates.
From attachment 62953 [details], this looks like ExtensionManager::getAllExtensions (desktop/source/deployment/manager/dp_extensionmanager.cxx) catching and rethrowing an exception (and that is not handled up the call stack; any of DeploymentException, CommandFailedException, CommandAbortedException, IllegalArgumentException, RuntimeException). Maybe a problem with one of the extensions that are installed---do you have any extensions installed as "shared" ones in your scenario?
I have not installed anything besides LO + l10n pack. Where should I look? I'm just trying to replicate this with the base install only (without the localization) and a new (temporary) network user.
(In reply to comment #9) > I have not installed anything besides LO + l10n pack. Good to know. > Where should I look? "Tools - Extension Manager..." would give the full list of extensions (when all three "Type of Extension" are checked, "Installation", "Shared", and "User"). I'm just thinking about an easy way to retrieve better information about your problem. I'll come back to you later.
OK, there are no shared extensions, only installation. Further testing: - Wiped out all traces of LO from the client, created a brand new network user, installed LO 3.5.3 (en-US) > Works like charm. - Deleted LO 3.5.3 from the client, installed LO 3.5.4 (en-US) > Still works! - Wiped out everything again… - Installed LO 3.5.3 (en-US). - Installed langpack_sk. - Works normally. - Deleted LO 3.5.3. - Installed LO 3.5.4 (en-US). - Installed langpack_sk (for 3.5.4 of course). - Works… … ????? — Wait, I still have it in English. > Opening Preferences, setting Slovakian in Languages tab > OK. BOOM! I'm posting that as a third crash report. This means, that there is probably some problem with the slovak language pack (which installs an entire bunch of extensions).
Created attachment 62966 [details] Crash log from the language change English > Slovakian
The crash is always from within the automatic update check thread, so when it will happen is somewhat non-deterministic. (For example, that it happened just while you switched the language to Slovakian is mere coincidence.) In a scenario that is known to be bad, can you manually do "Tools - Extension Manager... - Check for Updates..." to see whether it outputs anything that could give us more of a clue?
Yes I can, it just displays an update window with "No new updates available" message.
Investigated into this via offline communication with Michal, found out "OK, I think I understand the problem now. (It indeed requires both (a) installing an additional LO language pack -- so that LO restarts itself upon first start for a fresh user, as it considers the per-user extension data 'not in sync' due to the additional dictionary extension that comes with the language pack, and (b) having the user's home directory on something like AFP, causing failure to open the same file twice for writing from the same PID.)" The (first) such problematic file happens to be uno_packages/cache/log.txt in the per-user configuration directory, which causes an unhandled exception to be thrown when opened for writing a second time via UCB.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=942d0591be15d3886efd3c68bb2a5eefb2ed82ef&g=libreoffice-3-6 fdo#50603: Close fds across a restart of soffice on Mac OS X It will be available in LibreOffice 3.6.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d5e9c2e3e85a2bcdd6a0b2088253fc133e52e831 fdo#50603: Close fds across a restart of soffice on Mac OS X
Clarified offline with Michal that <http://cgit.freedesktop.org/libreoffice/core/commit/?id=d5e9c2e3e85a2bcdd6a0b2088253fc133e52e831> "fdo#50603: Close fds across a restart of soffice on Mac OS X" (backported to LO 3.5) would fix both of his issues, the crash after upgrading (as in attachment 62404 [details] from the original description) as well as the crash when creating a new user profile (as in attachment 62953 [details] from comment 5, which in turn is the same crash as in attachment 62966 [details] from comment 12).
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=dbc4070cacc85e4021c9f24947e84eeaa7f104f4&g=libreoffice-3-5 fdo#50603: Close fds across a restart of soffice on Mac OS X It will be available in LibreOffice 3.5.6.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-3-5-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a76695e1f3e0ad3a6a610ed7ffe6cd0507bde4aa&g=libreoffice-3-5-5 fdo#50603: Close fds across a restart of soffice on Mac OS X It will be available already in LibreOffice 3.5.5.
Unfortunately, even if I was not able to duplicate the issue with previous test builds, now I have downloaded the new version (LO 3.5.5/Mac) and I'm unable to get it working with my profile again. The problem was partially fixed: there's no crash after profile reset. But it still doesn't start with old profile data. To be more precise: Same configuration as in first post, same situation, but this time updating 3.5.4 -> 3.5.5 Result: Crash Console says: 20.7.2012 16:19:45,745 com.apple.launchd.peruser.1025: ([0x0-0x21021].org.libreoffice.script[242]) Job appears to have crashed: Bus error: 10 Crash log in the attachment.
Created attachment 64451 [details] Crash log from 3.5.4 -> 3.5.5 update
Michal, can you make available a zip of the problematic old profile data?
Created attachment 64530 [details] Profile data from ~/Library/… This is the profile data used while trying to update LO.
(In reply to comment #24) > This is the profile data used while trying to update LO. I unfortunately cannot reproduce any problems with that profile data. Will try to produce an unstripped Mac OS X LO 3.5.5 installation set that maybe gives a more useful crash log.
(In reply to comment #21) > Unfortunately, even if I was not able to duplicate the issue with previous test > builds, now I have downloaded the new version (LO 3.5.5/Mac) and I'm unable to > get it working with my profile again. The problem was partially fixed: there's > no crash after profile reset. But it still doesn't start with old profile data. > > To be more precise: Same configuration as in first post, same situation, but > this time updating 3.5.4 -> 3.5.5 > Result: Crash We tried to figure this out offline, but with little success: "Sorry, looks like I'm running out of ideas then. From the symptoms you describe, I would have come to the conclusion that it must be a corrupted common.rdb. However, that wouldn't explain why the problem could be observed for multiple user settings. Also, the common.rdb you sent works fine here. Unfortunately I cannot set up a scenario where I could reproduce your problem. "If removing the per-user ~/Library/Application Support/LibreOffice/3/user/extensions/bundled tree does help you, I have no better idea for now than to remove that once per user. (It is only a cache and is automatically recreated upon the next start of LO.) Incidentally, the fix for another bug (<https://bugs.freedesktop.org/show_bug.cgi?id=53006> 'Autocorrection TWo INitial CApitals does not work because of bundled extensions problem') will automatically remove that cache after a LO upgrade; it will be available in LO 3.7 and hopefully also in LO 3.6.1." So I'm setting this issue back to RESOLVED FIXED for now, as the original problem /is/ fixed.