I have tested this with various versions of openoffice1: (openoffice-ximian 1.3.7 and 1.3.9) and (openoffice-bin 1.1.4 and 1.9.91-r2) and whenevr I am drawing 3D objects nad manipulating them (roatating, applying attributes) the openoffice stops responding. In terminal I get Xlib: unexpected async reply (sequence 0x6ef2)! The sequence number is always different. Reproducible: Always Steps to Reproduce: 1.Run drawing program from openoffice 2.Draw and manipulate 3D objects 3. Actual Results: Openoffice locks up with error mentioned above Expected Results: Openoffice should not lock up. I am running fully updated stable system, my xorg version is 6.8.2-r1. I am using nvidia driver 1.0.6629-r4. Emerge info: Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.4.20041102-r1, 2.6.11-ck2 i686) ================================================================= System uname: 2.6.11-ck2 i686 AMD Athlon(TM) XP 2400+ Gentoo Base System version 1.5.3 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 9 2005, 23:57:41)] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.5.14 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="http://128.213.5.34/gentoo/ http://mirror.datapipe.net/gentoo ftp://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ ftp://ftp.ussg.iu.edu/pub/linux/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowex X aalib alsa apm artworkextra avi bash-completion berkdb bitmap-fonts cdparanoia cdr crypt cups curl divx4linux edl emboss encode fam fbcon fbdev fftw flac foomaticdb fortran fpx gd gdbm gif gnome gpm graphviz gstreamer gtk gtk2 gtkhtml guile hal imagemagick imlib ipv6 java javascript jpeg libcaca libg++ libwww live lzo lzw-tiff mad mikmod mmx mng motif mozilla mozsvg mp3 mpeg msn nas ncurses network nls nptl nvidia ogg oggvorbis opengl pam pdflib perl plotutils png python quicktime readline real rtc sdl slang spell sse ssl svg tcltk tcpd tetex theora tiff truetype truetype-fonts type1-fonts usb v4l v4l2 vorbis wmf xml xml2 xmms xv xvid zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
Can't reproduce that with both openoffice-ximian-1.3.9 and openoffice-bin-1.9.91-r2 (xorg-x11-6.8.2-r1 / nvidia driver 1.0.7174), everything works fine here. So this might actually be a problem with your X.org-setup. Adding the x-devs to the bug.
I have found that disabling nvidia driver (i.e. replacing "nvidia" in xorg.conf by "nv") fixes the problem. I see the same for 1.0.6629-r4 and 1.0.7174 versions of nvidia-kernel. No special options (such asRenderAccel) are enabled. I am using ck-sources-2.6.11-ck4 kernel. Openoffice is the only application that seems to have problems with nvidia driver, all other applications work fine including 3D games.
This error has to do with wonky multithread code. Does OO still use SDL for 3D work? I've had issues w/ SDL in the past.
OOo does not used (can't even remember a time it did)
Do you still get that problem?
Nothing has changed, I am still having this problem. Manupulating 3D objects always locks my ximian openoffice.
After all there's really nothing we can do here, the bug is not reproducible, so it is most likely a problem in your setup. And even if it would be a real problem, this should be reported upstream, as there is nothing we can do here.
