OpenOffice-2.4.1 crash after quit in KDE-3.5.9. In Windowmaker work fine. The output on console: KCrash: Application 'soffice.bin' crashing... XIO: fatal IO error 9 (Bad file descriptor) on X server ":0.0" after 119 requests (119 known processed) with 0 events remaining. Reproducible: Always Steps to Reproduce: 1.Start OpenOffice-2.4.1 2.Quit or close OpenOffice-2.4.1 Actual Results: OpenOffice crash... Expected Results: Correctly quit. Portage 2.1.4.4 (default-linux/amd64/2007.0, gcc-4.3.1, glibc-2.8_p20080602-r0, 2.6.24-gentoo-r2 x86_64) ================================================================= System uname: 2.6.24-gentoo-r2 x86_64 Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz Timestamp of tree: Tue, 10 Jun 2008 14:06:01 +0000 ccache version 2.4 [disabled] app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.1.4 dev-lang/python: 2.4.4-r11, 2.5.2-r2 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=core2 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-march=core2 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks loadpolicy metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="cs_CZ.UTF-8" LINGUAS="cs" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac aalib acl acpi alsa amd64 apache2 arts audacious bash-completion berkdb blender-game bluetooth bzip2 c++ cairo cdr cli clisp cracklib crypt ctype cups cvs dbus double-precision dri dvd dvdr dvdread editor emovix encode examples exif extensions extras ffmpeg firefox flac foomaticdb fortran ftp gcj gdbm gif gimp glut gphoto2 gpm graphviz gstreamer gtk gtkhtml hal hddtemp iconv icq ieee1394 ifp imagemagick imap imlib ipv6 isdnlog jabber java javamail jikes joystick jpeg jpeg2k kde kipi ladspa lame lapack latex lcms libcaca libsamplerate lm_sensors lua midi mikmod mjpeg mmx mng motif mozdevelop mozilla mp3 mp4 mpeg mudflap musepack musicbrainz mysql ncurses nls nptl nptlonly nsplugin ogg openal opengl openmp pam pango pascal pcmcia pcre pdf perl php plotutils png posix povray ppds pppd python qt3 qt4 quicktime quile readline recode reflection ruby scanner sdl seamonkey sensord session slang smp sndfile sox spell spl sqlite sqlite3 sse sse2 ssl svg symlink synaptics tcpd tetex theora threads tidy tiff timidity tk truetype unicode usb v4l v4l2 vcd vdr visualization vorbis wavpack wifi wma wmf x264 xerces-c xine xinerama xorg xosd xprint xscreensaver xv xvid yv12 zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev keyboard mouse synaptics joystick wacom" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="cs" USERLAND="GNU" VIDEO_CARDS="nv nvidia v4l" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Same thing here.
Anybody have any clues? Is there a possibility of me losing work because of this?
(In reply to comment #2) > Anybody have any clues? Is there a possibility of me losing work because of > this? > If it's compiled with USE="-kde", then OpenOffice work fine also in KDE. The use flag kde is reason, why OpenOffice crash.
It is _not_ the useflag, but rather the desktop integration. Exporting OOO_FORCE_DESKTOP="none" (or gnome) "solves" this problem, however, with none openoffice is ugly as hell, and many people simply don't want the gnome useflag when using KDE. Strace of the crash: close(17) = 0 munmap(0x7fd637058000, 4096) = 0 access("/home/fuchs/.qt/qtrc", F_OK) = 0 open("/home/fuchs/.qt/qtrc", O_RDONLY) = 18 fstat(18, {st_mode=S_IFREG|0644, st_size=1504, ...}) = 0 fstat(18, {st_mode=S_IFREG|0644, st_size=1504, ...}) = 0 fstat(18, {st_mode=S_IFREG|0644, st_size=1504, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd637058000 read(18, "[3.3]\nlibraryPath=/home/fuchs/.k"..., 4096) = 1504 fstat(18, {st_mode=S_IFREG|0644, st_size=1504, ...}) = 0 [more of those] fstat(18, {st_mode=S_IFREG|0644, st_size=1504, ...}) = 0 close(18) = 0 munmap(0x7fd637058000, 4096) = 0 fcntl(17, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}) = 0 close(17) = 0 rt_sigaction(SIGCHLD, {SIG_DFL}, NULL, 8) = 0 close(15) = 0 close(16) = 0 select(7, [6], [6], NULL, NULL) = 1 (out [6]) writev(6, [{"6\3\2\0\225\0@\3<\3\2\0f\0@\0036\3\2\0e\0@\3\n\3\2\0)\0@\3"..., 696}], 1) = 696 select(7, [6], [], NULL, NULL) = 1 (in [6]) read(6, "\22\0\352\7)\0@\3)\0@\3\0\0\0\0\320 L\2\0\0\0\0\274\260C\0\0\0\0\0"..., 4096) = 2912 read(6, 0x6b0fb4, 4096) = -1 EAGAIN (Resource temporarily unavailable) [more of those] read(6, 0x6b0fb4, 4096) = -1 EAGAIN (Resource temporarily unavailable) select(7, [6], [6], NULL, NULL) = 1 (out [6]) writev(6, [{"+\6\1\0", 4}], 1) = 4 select(7, [6], [], NULL, NULL) = 1 (in [6]) read(6, "\1\0014\10\0\0\0\0\16\0 \3\0\0\0\0\204\20}\0\0\0\0\0\260\241\23f\377\177\0\0", 4096) = 32 read(6, 0x6b0fb4, 4096) = -1 EAGAIN (Resource temporarily unavailable) select(7, [6], [6], NULL, NULL) = 1 (out [6]) writev(6, [{"\233\23\2\0r\0@\3\233\7\2\0o\0@\3\233\7\2\0p\0@\0036\7\2\0n\0@\3"..., 36}], 1) = 36 select(7, [6], [], NULL, NULL) = 1 (in [6]) read(6, "\1\0019\10\0\0\0\0\16\0 \3\0\0\0\0\204\20}\0\0\0\0\0\260\241\23f\377\177\0\0", 4096) = 32 read(6, 0x6b0fb4, 4096) = -1 EAGAIN (Resource temporarily unavailable) close(6) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- rt_sigaction(SIGALRM, {SIG_DFL}, {SIG_DFL}, 8) = 0 alarm(3) = 0 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0 close(3) = 0 close(4) = 0 close(5) = 0 close(6) = -1 EBADF (Bad file descriptor) close(7) = 0 close(8) = 0 close(9) = 0 close(10) = 0 close(11) = 0 close(12) = 0 close(13) = 0 close(14) = 0 [many many many more of those, counts up to 1023] close(1022) = -1 EBADF (Bad file descriptor) close(1023) = -1 EBADF (Bad file descriptor) write(2, "KCrash: Application \'soffice.bin"..., 46KCrash: Application 'soffice.bin' crashing... ) = 46 uname({sys="Linux", node="thinkfox", ...}) = 0 socket(PF_FILE, SOCK_STREAM, 0) = 3 connect(3, {sa_family=AF_FILE, path="/home/fuchs/.kde/socket-thinkfox/kdeinit__0"}, 110) = 0 write(3, "\f\0\0\0\0\0\0\0\\\0\0\0\0\0\0\0", 16) = 16 write(3, "\t\0\0\0\0\0\0\0drkonqi\0-display\0:0.0\0--"..., 92) = 92 read(3, "\4\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0", 16) = 16 read(3, "\0211\0\0\0\0\0\0", 8) = 8 alarm(0) = 3 kill(12561, SIG_0) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [SEGV], 8) = 0 rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [SEGV], NULL, 8) = 0 nanosleep({1, 0}, XIO: fatal IO error 9 (Ungültiger Dateideskriptor) on X server ":0.0" after 82 requests (82 known processed) with 0 events remaining. 0x7fff3f088f40) = ? ERESTART_RESTARTBLOCK (To be restarted) emerge --info output can be added when needed, system is amd64 with a core2duo, sane C*-Flags, kde useflag enabled.
Even if KDE related, OOo isn't maintained by the KDE team.
A fix was done by the Debian team as this mornings openoffice 2.4.1-3 on Debian amd64 fixed that problem on my other machine. Hope someone here can add that to our Gentoo ebuild.
(In reply to comment #6) > A fix was done by the Debian team as this mornings openoffice 2.4.1-3 on Debian > amd64 fixed that problem on my other machine. Hope someone here can add that to > our Gentoo ebuild. > For reference, the Debian bug is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=485833 Also, they didn't really fix the bug...they just disabled randr support to work around it.
Same here.
Very similar problem I experience, at least oo seems to work with OOO_FORCE_DESKTOP="none". Strangest thing is that when I have file which when I open in oo-2.4.1 crashs every time I change layout, while it does not crash with other files...
No problem here with KDE 3.5.9 and OOo 2.4.1 on ppc (PowerPC 32-bit) arch. USE="binfilter cups dbus firefox gstreamer java kde ldap opengl pam -debug -eds -gnome -gtk (-mono) -odk -seamonkey -xulrunner (-webdav%)" Seems to be affecting only x86 and amd64.
Here's mine: $ emerge -vp openoffice These are the packages that would be merged, in order: [ebuild R ] app-office/openoffice-2.4.1 USE="cups dbus gtk java kde opengl pam -binfilter -debug -eds -firefox -gnome -gstreamer -ldap -mono -odk -seamonkey -xulrunner" LINGUAS="-af -ar -as_IN -be_BY -bg -bn -br -bs -ca -cs -cy -da -de -dz -el -en -en_GB -en_US -en_ZA -eo -es -et -fa -fi -fr -ga -gl -gu_IN -he -hi_IN -hr -hu -it -ja -km -ko -ku -lt -lv -mk -ml_IN -mr_IN -nb -ne -nl -nn -nr -ns -or_IN -pa_IN -pl -pt -pt_BR -ru -rw -sh -sk -sl -sr -ss -st -sv -sw_TZ -ta_IN -te_IN -tg -th -ti_ER -tn -tr -ts -uk -ur_IN -ve -vi -xh -zh_CN -zh_TW -zu" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB
I've just (silently) bumped the patchset to ooo-build-2.4.1.6, which should solve this crasher. Please re-sync, rebuild and try again
Thank you Andreas. Seems that it should at least that's what upstream told me: http://www.openoffice.org/issues/show_bug.cgi?id=90864 I'll test it today, but I suppose that this specific issue requires revision bump, so all users could avoid this crasher. What do you think?
(In reply to comment #13) > Thank you Andreas. Seems that it should at least that's what upstream told me: > http://www.openoffice.org/issues/show_bug.cgi?id=90864 > I'll test it today, but I suppose that this specific issue requires revision > bump, so all users could avoid this crasher. What do you think? > I'm not too sure about a revision bump, because of the sheer size of OOo I normaly tend to avoid those ;) On the plus side everyone would get the fix, on the minus side a lot of users would have to recompile though they don't experience this problem at all. Also we would have to re-keyword a new revision for the 2.4.1 security bug... Tough choice...
(In reply to comment #12) > I've just (silently) bumped the patchset to ooo-build-2.4.1.6, which should > solve this crasher. Please re-sync, rebuild and try again > Patch really solve that bug.
Now I can confirm too that this bug is solved. > (In reply to comment #13) > I'm not too sure about a revision bump, because of the sheer size of OOo I > normaly tend to avoid those ;) On the plus side everyone would get the fix, on > the minus side a lot of users would have to recompile though they don't > experience this problem at all. Also we would have to re-keyword a new revision > for the 2.4.1 security bug... Tough choice... Crashers like this, which are reproducible very well without any specific actions should have their revision bump in any case. I've noticed users having such issue everywhere: this was asked on -dev IRC channel, this was discussed in forums, people asked me privately in jabber. BTW, more generally my opinion is that any such patchset upgrade requires revision bumps for the following reasons: 1. Fixes which upstream considered important will be at users systems 2. This will reduce number of bug reports for already fixed issues at upsteam OO 3. Currently it is unknown if user have fixed or known to be broken version of OO And last point: I think that taking into account compilation times is not good idea as thouse who bother should use binary package.
Crash long fixed, OOo 3.0 in the tree, closing
