You are not logged in.
I have put OOO_FORCE_DESKTOP=gnome; otherwise, openoffice hang at the splash screen using 100% CPU. I use a plain windows manager, no desktop (icewm).
If I do in openoffice writer File -> Save As; then I find a popup window asking ma the name, etc... under which I want to save the file (this is expected). But then openoffice uses 100% CPU until I choose a name and click save. The same behavior happens when clicking File -> Export
Is it a known bug? is it reproducible elsewhere?
(By the way the same kind of problems happens with xfig, but I do not know if it is related since these two packages uses different toolkits).
Olive
Offline
Open office is a pretty heavy application in general as such it's much more likely that your system is not state of the art rather than a bug in OO.
If you are concerned about CPU spikes you could always install Abiword, Gnumeric - much lighter alternatives to OO.
What sort of machine do you have?
--
My machine reacts as follows.
Open Open Office (3.0)
62% CPU Usage.
Open / Save file
98% CPU Usage.
Doesn't seem to be a bug to me.
Thurin1 @ irc.freenode.net #archlinux
Offline
@orasis The problem only appears when there is the file dialog "save as" (or export) waiting for input (thus doing nothing else than waiting). If there is already a name for the document and you click save there is no problem; it only appears when OO display the windows asking for th efile name. I have 0% of cpu when openoffice is waiting for input when typing a document. It seems clearly that there is an endless loop somewhere. I remember emacs has a similar problem when clicking tool -> Compare(Ediff) -> introduce the two files to compare and you see 100% cpu usage. For emacs the problem disappears when recompiling without gtk (so it might be a gtk problem).
My machine is an intel celeron 1.6 Ghz with 1280 Mb ram (but I am pretty sure it is not the problem)
Olive
Offline
I think olive is right.. this was easily reproducible for me.
1. Open OOo Writer
2. Type 'ekgheoif'
3. Hit Ctrl-S
At this point it maxes out 1 core and eats up 55% of the 2nd core indefinitely as long as the 'Save' dialog is open.. I'm guessing it's an upstream bug.
Last edited by AD28 (2008-10-12 05:35:09)
Offline
I can confirm to. Can someone file a bug report for this. We need to keep track of it until it is confirmed as an upstream bug, and especially if it isn't...
Offline
@Allan Bug reported ( http://bugs.archlinux.org/task/11710 ).
Olive
Offline
I have just tested the official build of openoffice at www.openoffice.org. It works properly without forcing the gnome desktop. Also the KDE version seems to works properly as well as the save as dialog with the gnome version. It seems that adding OOO_FORCE_DESKTOP=gnome is an ugly hack to mask a broken package.
If openoffice is that difficult to compile, I wonder if just repackaging the official build would not be a better and easier solution
Offline
The official build isn't broken because it's compiled static against an ancient version of Glib that does not hang itself when it's used without initialization. Start your official openoffice build from a terminal with KDE and you'll see tonnes of CRITICAL glib warnings.
Offline
@JGC I do not have kde installed but the official build start without any warning after putting export OOO_FORCE_DESKTOP=kde (in that case it does indeed put KDE-like icons). If these warnings appears under some circumstance, do they prevent openoffice from working properly? Why do not statically link with the old version of glib as in the official build? I understand it might be a bad idea theoretically but I wonder if the remedy isn't worse that the problem.
Offline