I have tried all three of these, and *NONE* of them work as anything *BUT* the root user. Running strace reveals nothing on six threads that start up when executing any of the OpenOffice scripts for the first time under a user account. The setup program always fails with a segmentation fault if you are not root, it doesn't matter *which* of these builds you use. Reproducible: Always Steps to Reproduce: 1. emerge openoffice (or emerge openoffice-bin or emerge openoffice-ximian) 2. attempt to run the package as a non-root user, it dies. 3. attempt to run the package as root, it works. Actual Results: SIGSEGV. Expected Results: Started! Running programs are irrelevant to this issue. strace -f output is over 1 MB, *WAY* too big to post. Attached as a .tgz file. 'emerge info' output: Portage 2.0.51-r3 (default-linux/x86/2004.3, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.6.9-gentoo-r6 i686) ================================================================= System uname: 2.6.9-gentoo-r6 i686 Intel(R) Pentium(R) 4 CPU 1.50GHz Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.90.0.1.1-r3 Headers: sys-kernel/linux-headers-2.4.21-r1 Libtools: sys-devel/libtool-1.5.2-r7 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O3 -mcpu=pentium4 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -mcpu=pentium4 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="http://gentoo.osuosl.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X aim alsa apm arts avi berkdb bitmap-fonts crypt cups encode esd f77 fam foomaticdb fortran gdbm gif gnome gpm gstreamer gtk gtk2 imagemagick imlib java jpeg libg++ libwww mad mikmod motif mozilla mpeg msn ncurses nls oggvorbis opengl oss pam pdflib perl png python quicktime readline samba sdl spell ssl svga tcpd tiff truetype x86 xml2 xmms xv yahoo zlib"
Created attachment 45462 [details] All output from strace -f Hopefully, this helps or makes sense to someone. I've been very frustrated with this problem and I can't figure it out as a configuration problem. This stuff makes zero sense to me, so *shrugs*. This excerpt is from openoffice-ximian - I wasn't about to rebuild openoffice or anything crazy like that 'cuz it takes 3/4 of a day or so to build it on this system.
I've been having this problem for the longest time as well, but it never occurred to me to try running OO.o from a console. Doing so quickly presented me with a solution: $ xooffice I'm confused because I can't find OpenOffice's user files. Your ~/.xversionrc file tells they should be under /home/luciano/.xopenoffice/1.1.2, but they are not. Please fix the situation manually. You may want to edit ~/.xversionrc to indicate where is OO installed, or remove it if you did remove your installation directory manually (you bad one). Deleting .xversionrc from my home folder remedied the problem and now everything is back to normal. I hope this helps.
I've already attempted that. Those files do not exist, it doesn't even get to creating them for the user. However, it does for 'root'. This leaves me still looking for a solution, and this isn't good because this is my machine at the office. I'm using AbiWord for the moment, but I'm going to eventually need to use the spreadsheet. Later.
And another thing - I created *SEVERAL* user accounts to try this with - it fails to run on *ALL* of them where the uid is not zero.
same here exactly the same bug! it runs well with root user but with no other! i-m trying to get to work ximian-openoffice. I think that basically is a privs problem that
same here exactly the same bug! it runs well with root user but with no other! i-m trying to get to work ximian-openoffice. I think that basically is a privs problem that´s my fault after a long discussion on the forum. Hope this could help!
Yeah, well, I suppose that might be it - but I don't know *where* to look for the problem if it is permissions - and if it is permissions, why is it segfaulting? Why isn't it failing with an error message or something, giving me an idea of what to fix? This is getting to be uber-frustrating, and I don't have the time to go on wild-goose chases to try to determine what the problem might be. I spent a few hours in #gentoo on FreeNode the other day, to no avail, either. I've exhaused virtually everything I can think of that I'm capable of doing, trying to figure out what the problem is, why it won't start, or whatever, and nothing is working. So. *shrugs*. And if it's a permission problem, it affects all three of the packages that I emerged, and that's frustrating. Do you know how long it takes to emerge OO.o from source? I figured the binary distribution was broken or something so I tried the source package - and same result - so I think perhaps it's something that hasn't been fixed in OpenOffice. I was hesitant to report the bug here, but I am *REALLY* hesitant to report it as a bug on OO.o's website because I'm not sure that it's specific to anything but an installation in the way that Gentoo does it.
An interesting note: If I'm on another machine, connect to this one via SSH, and the display variable is set to the second machine's display (running SSH), OpenOffice functions. It will *not* function on the X display when I'm sitting at the computer running it, however. Does this make sense to anyone? Why would this happen? This *seriously* does not make sense to me. I am at a complete loss for any more ideas to solve this problem. I'm growing more and more to think, however, that this may not be a bug at all, at least, if it is, not necessarily with OpenOffice, but the default configuration or something - and I don't even *know* where to begin looking on *that*.
*AHA*. I have a workaround, but there is *definately* a bug in OpenOffice. It has to do with how it handles DRI cards. Wow, this was not easy to figure out. The default permissions on the card are: crw-rw---- 1 root root 226, 0 Dec 7 19:03 /dev/dri/card0 I was unable to find this out before because the info was buried, but I tried running strace again after running OpenOffice on my office machine from home, when before I came into work, and it setup the files and such, so I checked strace again, and it was complaining about /dev/dri/card0 not having permissions, and then subsequently, trying to unmap memory, which results in a SIGSEGV. See the new strace -f output, being attached shortly. OpenOffice *should* fall back to functioning as other X apps do, I would imagine, if the DRI device isn't accessible... or at the very least, display an error, not segfault. A workaround is to configure the DRI permissions so that they aren't broken on an end-users system, and another workaround is to not enable DRI. Perhaps another bug should be filed to fix the default DRI permissions, wherever that bug would go? However, OO.o needs to be set to not segfault when it encounters this situation, it should instead fail gracefully. I am changing some of the bug information to reflect the true nature of this bug.
Created attachment 45602 [details] strace -f of xoowriter showing failure upon DRI This is the output showing a failure after attempting to use /dev/dri/card0. This problem (and resulting segfault) does not occur when the permissions are changed on /dev/dri/card0 to allow the user to access it.
allright i don
allright i don´t know how to run openoffice without using the card0 device so just changed the permission there. everything is working now. thanks!
*** This bug has been marked as a duplicate of 70397 ***
