Bug 834800
a) If you've seen the bug reported elsewhere, has the bug been reported to any other bugzilla anywhere ?, i.e not a random web forum, but any existing bugs.freedesktop.org, bugzilla.redhat.com (was there any reports of this around F-13, I've no memory of any?) or somesuch location ? b) can I get the output of... unopkg list && unopkg list --shared && unopkg list --bundled c) Can you try tar cjf .libreoffice .openoffice.org /tmp/config.tar.bz2 and attach /tmp/config.tar.bz2 to this bug issue. Though that seems a longshot given that you already seem to have tried deleting those ? d) The output of strace -f /usr/lib/libreoffice/program/soffice.bin > /tmp/strace.log 2>&1 and attaching /tmp/strace.log to this bug might help as well. Re: a) First, thanks for a very rapid response to my bug post! At the very top of the list is a bug report I posted to the OpenOffice bugzilla. It is currently marked as closed, I suppose, because it never got solved and there has no further activity on it: https://issues.apache.org/ooo/show_bug.cgi?id=118239 Some additional reports that look informative: http://lists.freedesktop.org/archives/libreoffice-bugs/2012-April/049778.html http://lists.debian.org/debian-openoffice/2012/04/msg00154.html http://us.generation-nt.com/bug-633929-also-seeing-bug-help-207050472.html http://ubuntuforums.org/showthread.php?t=1861643 https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/792947 http://user.services.openoffice.org/en/forum/viewtopic.php?f=6&t=33374 I will send in formation regarding your question s b, c and d in separate comments Re: b)
>unopkg list && unopkg list --shared && unopkg list --bundled
ERROR: Cannot determine language!
unopkg failed.
terminate called after throwing an instance of 'com::sun::star::uno::RuntimeException'
/usr/lib64/libreoffice/program/unopkg: line 141: 31585 Aborted (core dumped) "$sd_prog/unopkg.bin" "$@" "$JVMFWKPARAMS" "-env:INIFILENAME=vnd.sun.star.pathname:$sd_prog/redirectrc"
ERROR: Cannot determine language!
unopkg failed.
terminate called after throwing an instance of 'com::sun::star::uno::RuntimeException'
/usr/lib64/libreoffice/program/unopkg: line 141: 31662 Aborted (core dumped) "$sd_prog/unopkg.bin" "$@" "$JVMFWKPARAMS" "-env:INIFILENAME=vnd.sun.star.pathname:$sd_prog/redirectrc"
ERROR: Cannot determine language!
unopkg failed.
terminate called after throwing an instance of 'com::sun::star::uno::RuntimeException'
/usr/lib64/libreoffice/program/unopkg: line 141: 31730 Aborted (core dumped) "$sd_prog/unopkg.bin" "$@" "$JVMFWKPARAMS" "-env:INIFILENAME=vnd.sun.star.pathname:$sd_prog/redirectrc"
Created attachment 594011 [details]
contains .libreoffice directory, newly created when trying to start LO
Created attachment 594012 [details]
strace from trying to start libreoffice
strace -f /usr/lib64/libreoffice/program/soffice.bin > /tmp/strace.log 2>&1
hmm, that .config is *way* too small, so we must have died very early before we even get a chance to write any configuration on first-start. The "ERROR: Cannot determine language" is then a symptom of that. Just to be sure of where we stand, can I get the output of... a) rpm -qa|grep libreoffice and the output of b) rpm -V `rpm -qa|grep libreoffice|xargs` and does a prior ~/.openoffice.org dir exist ? I think what might be helpful is to try and get a strace of a recreation of the original first-start situation which must have failed, e.g. rm -rf ~/.libreoffice && strace -f /usr/lib64/libreoffice/program/soffice.bin > /tmp/strace.log 2>&1 Created attachment 594086 [details]
output from rpm -qa|grep libreoffice > rpm.out
Created attachment 594087 [details]
output from rpm -V `rpm -qa|grep libreoffice|xargs` > rpmV.out
Created attachment 594088 [details]
screen messages from rpm -V `rpm -qa|grep libreoffice|xargs` > rpmV.out
Created attachment 594095 [details] strace using original .openoffice.org I deleted .libreoffice and restored the .openoffice.org directory from a 2 week old backup. Then tried running strace -f /usr/lib64/libreoffice/program/soffice.bin > /tmp/strace.log 2>&1 Notably, this time, the splash screen did NOT appear. Only the popup error message as shown in attachment 593922 [details]. And, again libreoffice did not launch. As previously, a very minimal .libreoffice directory was created. I wonder why it appears to be reopening the .xcd files again and again. Once should be enough. can't figure out a reason for this, and am unable to reproduce. So... if there is *no* .openoffice.org and there is *no* .libreoffice dir, i.e. rm -rf .openoffice.org .libreoffice and you launch libreoffice it fails in exactly the same way, right ? i.e. I don't think we're looking at a config migration failure. Is there anything special about how your home dir is mounted ?, and/or is there sufficient free diskspace on /home ? (In reply to comment #13) > can't figure out a reason for this, and am unable to reproduce. So... > > if there is *no* .openoffice.org and there is *no* .libreoffice dir, i.e. rm > -rf .openoffice.org .libreoffice and you launch libreoffice it fails in > exactly the same way, right ? i.e. I don't think we're looking at a config > migration failure. > > Is there anything special about how your home dir is mounted ?, and/or is > there sufficient free diskspace on /home ? Back in September, I posted the following to the OpenOffice.org bugzilla https://issues.apache.org/ooo/show_bug.cgi?id=118239 3. This bug happens on an account by account basis. That is, it happens to each user on the system, independently, after one or more uses of OO or LO. An important point here is that once either program is broken, both are broken. If I create a NEW user account, the first time I try to use OO or LO, the program works. After one or more launches, suddenly both no longer work at all. There is oodles of disk space in /home, so that's not a problem. Hey, I wonder if it could be something in /tmp? One of the things that has always nagged me is that an awful lot of the applications in gnome/Fedora/RedHat etc. leave a lot of old files and directories in /tmp. There are all sorts of things going back many months, from various applications. Examples: 4fc817b951376 -> /etc/cups/ppd/Lexmark-C543.ppd hsperfdata_user keyring-uP9L8o lusu2hzd.tmp pulse-cQdeHA5R9M6F orbit-user mozilla-media-cache svcnp.tmp virtual-user.R7Kt5A (I've changed usernames and some characters.) In turn, many of these directories have lots and lots of things in them. The fact that users often can launch LO exactly once, and then have it stop working, would be consistent with something bad being left in /tmp, which LO reads. (That is complicated by the fact that other users don't even get to run LO even once, although all of them have previously run OpenOffice, when it was still on the system.) Still, if it was, say, a conflict of libraries, you would expect it to break for everybody right from the beginning. The /tmp hypothesis would also be consistent with the observation that many others have made, that they can uninstall LO and reinstall it, and it still doesn't work. I should point out that I'm running a RHEL6.2 system that was installed fresh, reformatting the hard drive, and dutifully running the updates thereafter. The ONLY non RHEL package that installed was VLC, using rpms from the VLC web site. (That, by the day, doesn't work because of library conflicts.) So if it was something persisting in /tmp, presumably one could delete everything in /tmp and reboot, and LO should work again. If I did delete the entire contents of /tmp, am I in for any nasty surprises? I am going to guess that the correct procedure would be to logout, shift to a text screen (eg. ctrl-alt-F3), login as root, and then cd /tmp rm -rf ./* ./.* {even contemplating this makes me nervous} {did I get this right so as to include dot files?} restart Or, maybe a less potentially destructive way would be to create a new user, try to launch LO, and then do some sort of find in /tmp to see which files were changed at the moment LO started up. while i really hope that a LO process doesn't read anything from /tmp that the same process has written, the easiest way to try that out is to put /tmp on a tmpfs, that way it will get cleared automatically on reboot. e.g. on my Fedora 17 system i have the following in /etc/fstab: tmpfs /tmp tmpfs nodev,nosuid 0 0 err i meant "i hope that a LO process doesn't read anything from /tmp that the same process has _not_ written" My current /etc/fstab has tmpfs /dev/shm tmpfs defaults 0 0 which I assume is RHEL's default. So to make sure I am getting this right, comment out that line and replace it with tmpfs /tmp tmpfs nodev,nosuid 0 0 then reboot. Then retry launching LO. Rereading my above comment, I realize that the line I showed probably has no relation to /tmp. Here's my complete fstab: # # /etc/fstab # Created by anaconda on Sun Sep 11 08:33:42 2011 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info # /dev/mapper/vg_orpheus-lv_root / ext4 defaults 1 1 UUID=xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx /boot ext4 defaults 1 2 /dev/mapper/vg_orpheus-lv_home /home ext4 defaults 1 2 /dev/mapper/vg_orpheus-lv_swap swap swap defaults 0 0 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 I masked UUID above, in case it's a potential security hole. hi Brian, /etc/fstab can contain many tmpfs mounts, and i guess you shouln't remove any existing ones because that will probably break something, just add a new line for /tmp at the end is enough. (In reply to comment #15) > while i really hope that a LO process doesn't read anything from > /tmp that the same process has written, the easiest way to try > that out is to put /tmp on a tmpfs, that way it will get cleared > automatically on reboot. > > e.g. on my Fedora 17 system i have the following in /etc/fstab: > tmpfs /tmp tmpfs nodev,nosuid 0 0 Okay, so I deleted .libreoffice, added the above line to /etc/fstab, and rebooted. I checked /tmp after reboot and indeed, the old files were gone, with just a small number of new files and directories. The result was the same as before: launch LO, and you get the splashscreen, and then the error popup. So, I guess we can rule out the hypothesis that nefarious file persists in /tmp. Brian, can you give the output of "set" from a (bash) shell from which starting soffice would fail? (In reply to comment #21) > Brian, can you give the output of "set" from a (bash) shell from which > starting soffice would fail? Stephan, I have found a reproducible way to go back and forth between fixing LibreOffice and breaking it. I will attach two files showing the output of set when LO works, and when it doesn't. (set_ooworks.txt and set_oobroken.txt). Briefly, what happened is that my .bashrc sources another file called profile.source that sets a large number of environment variables, and does a few other things such as turning off noclobber, 'ulimit -c 0', and setting a custom prompt. When I comment out the '.' line that runs profile.source, LibreOffice launches. If I uncomment the '.' line, LO no longer works. I have managed to turn LO on and off many times, so it seems like my profile.source file must be the culprit. Most of the enviroment variables set in profile.source have obscure names specific for a package of bioinformatics programs that I use, so I doubt there are any environment variable conflicts. Notably, I do NOT set LD_LIBRARY_PATH (I know the trouble that can cause). Given enough time I can probably track down the offending lines in profile.source. However, I was wondering if you had anything specific in mind when you asked about the output from 'set'? That might give me a clue as to what to look for. As an aside, there seem to have been several people reporting various fixes that eliminate the error message, and they are not necessarily related. I am thinking that there may be a number of ways of causing LO to generate the "general error" message, and to prevent LO from running. Created attachment 597192 [details]
output from set when LO fails to launch
Created attachment 597193 [details]
output from set when LO works
This is upstream <https://bugs.freedesktop.org/show_bug.cgi?id=42961> "Setting $DATA causes LibreOffice to crash" first fixed in upstream LibreOffice 3.5.2. As a workaround, you could make sure to not have environment variables DATA or SCHEMA set. (Re "I am thinking that there may be a number of ways of causing LO to generate the 'general error' message, and to prevent LO from running." Yes, this is one of a few messages that appear when something fatal happens internally during early start up. It can have various reasons and the error message does not always reflect the true problem. Another common---and often misleading---message is something about failure to determine a UI language.) Development Management has reviewed and declined this request. You may appeal this decision by reopening this request. |
Created attachment 593922 [details] screenshot of error message Description of problem: Today I upgraded my RHEL6.2 system using System --> Administration --> Software update. Apparently, the update deleted OpenOffice and replaced it with Libreoffice. I rebooted after the upgrade. All attempts to launch LibreOffice result in a failure to launch any LO component. Version-Release number of selected component (if applicable): LO3.4 How reproducible: Somewhat reproducible. This happened to me after I installed Libreoffice 3.3 on Fedora 13, which caused me to upgrade to RHEL6 when no fix seemed to be available. It has been reported extensively on the Internet, for both Windows and Linux, but there is still no certain fix to the problem. Apparently, it doesn't happen to everyone, but happens frequently enough that the same problem has been reported many times since 2011. Steps to Reproduce: 1. Applications --> Office --> Libreoffice Writer (or Calc or Impress or Draw) Actual results: Try to launch any LO component from either the command line or the Applications menu always fails to launch. The splash screen appears, and only a tiny bit of the progress bar in the splash screen fills in, from left to right. Almost immediately, a window pops up with the message: The application cannot be started. A general error occurred while accessing your central configuration. Alternatively, launching from the command line using 'oowriter' 'oocalc' etc. give the same result. No error messages appear in the terminal window. Only the popup error is seen. Expected results: Libreoffice components launch Additional info: Some of the reports on various newsgroups suggest deleting .openoffice and .libreoffice directories, and it appeared to work for some users, but not for others. I have tried renaming my openoffice.org directory, and deleting the newly-created .libreoffice directory, but that doesn't fix the problem.