I'm using OOo 2.01, compiled from source. Even after closing OOo, processes are left over eating almost 100% of CPU time. Get the impression that these zombies especially linger around after cases where OOo crashed ... "kill -9" frees the system from this load - afterwards it is in a normal condition again. cf. http://forums.gentoo.org/viewtopic-p-3060962.html#3060962 # emerge --info : Portage 2.0.54 (default-linux/x86/2005.1, gcc-3.3.6, glibc-2.3.5-r2, 2.6.15-gentoo-r1 i686) ================================================================= System uname: 2.6.15-gentoo-r1 i686 Pentium III (Coppermine) ______ [ ASUS dual board with 2 processors, 1.1 GHz each ] Gentoo Base System version 1.6.14 ccache version 2.3 [disabled] dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium3 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/fax /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/bind /var/qmail/alias /var/qmail/control /var/spool/fax/etc" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks fixpackages noauto sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror " LC_ALL="de_DE@euro" LINGUAS="de" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://linux.rz.ruhr-uni-bochum.de/gentoo-portage" USE="x86 X aalib acl alsa apm arts audiofile avi bash-completion berkdb binfilter bitmap-fonts bonobo bzip2 cdr crypt cups curl directfb doc eds emboss encode esd exif expat fam ffmpeg flac foomaticdb fortran gd gdbm gif gimpprint glut gmp gnome gpm gstreamer gtk gtk2 gtkhtml guile hbci idn imagemagick imap imlib ipv6 java jpeg junit kbanking kde lcms ldap libg++ libwww mad maildir matrox mga mhash mikmod mng motif mozilla mp3 mpeg mysql ncurses nls nsplugin ogg oggvorbis opengl oss pam pcre pdflib perl png postgres ppds python qt quicktime readline ruby samba scanner sdl slang spell sqlite ssl svga tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts udev unicode vorbis wmf xine xml xml2 xmms xv xvid zlib video_cards_matrox linguas_de userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LDFLAGS
I'm just re-compiling the newest available ebuild, this time without any optimizations at all: CFLAGS="-O0 -march=pentium3 -pipe" emerge -av app-office/openoffice: Portage exploits the ebuild app-office/openoffice-2.0.1 with my following USE-flags: +binfilter +curl +eds +gnome +gtk +java +kde +ldap +mozilla +xml2 +zlib Portage exploits the distfile ooo-build-2.0.1.2.tar.gz. I will report my further experiences later.
Can't reproduce here, OOo closes fine. Do you use some sort of quickstarter? "Even after closing OOo, processes are left over eating almost 100% of CPU time." Do you get that always or just sometimes? "Get the impression that these zombies especially linger around after cases where OOo crashed" So that is no big surprise, is it? Crashing certainly isn't the prefered way to close OOo ;) If there is a crasher, you should file a bug report upstream about the crash, if zombie processes remain after "regular" closing that is another problem...
(In reply to comment #2) > Do you use some sort of quickstarter? Nope. > Do you get that always or just sometimes? Sometimes. > Crashing certainly isn't the prefered way ... ... to anything at all ;) right. Well, I'm running my old beloved dual-proc dual-screen workstation with 2 x 16 virtual screens, usually with an up-time of months until the next kernel build enforces a reboot - the running time of many applications (1GB of main memory was a good investment even six years ago) corresponds. So I'm not always aware when exactly one of the OOo-tasks (texts, spread-sheets, ...) crashes. I get back to that virtual screen, and just observe KDE's tracing note. Since StarOffice became OpenOffice, the developer community has done a really great, even magnificent job to clean the structure of the beast; it still crashes too often - but not that often that I was able to identify a reproducable situation yet. So, after being alerted now, I'm just trying to exactly observe where the left-over-processes result from. And I already promised that I will provide any hints as soon as I have a clue. Yes, unfortunaltely I got the _impression_ that after an "exit" of OOo when some OOo application windows were (saved, but) still open, not all of them are being closed properly; but I have to verify that. Unfortunately, tonight's ooo-build-2.0.1.2 which was intended to investigate if "-O0" makes a differenceto "-O2" crashed because a separate quick 4 GB SCSI disk for /var/tmp/portage (completely emptied) had not been sufficient ?! - you got a separate mail on that. Kind regards, Manfred
We need some more "hard facts" here, as this is not reproducable here. So if you have donee some more testing and can add when this happens, please reopen the bug
