Red Hat Bugzilla – Bug 124374
Terminal memory usage when right-clicking on a misspelled word
Last modified: 2007-11-30 17:10:43 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Description of problem:
If you misspell a word in OpenOffice.org and right click on it, the
following will happen:
* Memory usage increased dramatically (in my case, it went from an RSS
of 55.0MB to 249MB)
* The following is printed to the console:
Hash Manager Error : 1
Error - could not open affix description file
Failure loading aff file /usr/lib/ooo-1.1/share/dict/ooo/fr_BE.aff
This does not occur when using the standard spell checker (Tools >
Spell Check > Check [F7]). Continuing to right-click on misspelled
words does not seem to result in the memory leak getting larger.
The used resources are not released until OpenOffice.org is closed
completely. Simply closing all documents does not resolve this issue.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start OpenOffice.org in Fedora Core 2
2. Misspell a word
3. Right-click on that word to give a list of suggested spellings.
Actual Results: Severe memory leak.
Expected Results: Memory usage should change little, if any.
I've got a quick fix. Using your info I looked through the dictionary
directory and opened dictionary.lst.
To quote the file, "List of All Dictionaries to be Loaded by OpenOffice"
I backed up the file and then deleted every entry except
DICT en US en_US
HYPH en US hyph_en_US
THES en US th_en_US
Now right-click spell-checking works without problems.
After this, I tested what would happen if I just remove the fr_BE
lines (seeing as there are no fr_BE files in the directory) but it
didn't solve the bug. (Maybe there are other non-existant dictionary
files? I ctrl+C'd OO.o before seeing any text in the console; it
slows my 128MB system to a crawl.)
(I remember having this kind of bug in Redhat 9 but not in FC 1.)
I have done some more analysis. The problem seems to have something to
do with the number of dictionaries installed by default. If you remove
a few, memory usage will drop quite a bit. See
http://www.openoffice.org/issues/show_bug.cgi?id=14980 for more
Reducing the number of dictionaries installed by default may be a good
solution. The new version of OpenOffice includes "DicOOo," which is a
dictionary installer macro. If someone needs another language, they
can install it by clicking 'File > AutoPilot > Install New Dictionaries.'
Now, I am unable to completely explain why this does not happen when
you use the standard spell checker. However, it seems to be related to
the spelling suggestions when you right click on a word. I think it is
loading all installed dictionaries to search for spelling suggestions.
Run "strace oowriter" and misspell a word, take a look at all of the
files it reads. Then, close OpenOffice.org and run "strace oowriter"
again. Now, misspell a word and click on the standard Check Spelling
button. Notice the difference in the stack trace?
Now, we only need to find out if this is a bug in OpenOffice.org
itself, or the Red Hat customized version.
This seems to still plague 1.1.2 in Rawhide latest, with packages in
the 1.1.2-3 build
Is there anything we can do, since DicOOo is already present and its
loading up all dictionaries? The lag isn't so notiecable when the
machine has more than 512MB of RAM, but it takes time even with
machines with 256MB of RAM or so
Here's the problem. People get mad if we _don't_ include lots of
dictionaries, but of course dictionaries take a lot of memory to use
and load. I patched out the "Check in all languages" option for OOo
and set it off always, but unfortunately OOo works against me and
enables all dictionaries right after the upgrade. The best solution
would be to figure out which dictionary the user actually _needs_ and
enable only that one. I guess a solution would be to patch OOo to
check LANG to grab the current language after an upgrade and only
enable that dictionary by default, and allow the user to enable more
Dan, what about separating the dictionaries into individual packages,
like Debian does? Then based on LANG selected, only such a dictionary
is installed by default?
So we'll still include lots of dictionaries, but they'll only get
installed by request. Then maybe an upstream patch to DicOOo to also
handle local installs of dictionaries as well?
I have discussed separate i18n packages with Jeremy (anaconda) at
great length and and he's said that its not such a problem
post-install, but a great problem at install time. KDE has separate
i18n packages, and the hackery in Anaconda required to deal with them
is quite complicated for some reason. I still think this requires a
cleaner solution inside OOo.
Why not simply just install dictionaries for the languages selected to
be installed in anaconda? Or better: only load the dictionary which is
selected as the current language... I really don't care if a
misspelled word happens to be correct in polish or welsh...
I had the kernel kill off OO on a 320 MB + enough swap once... After
five minutes of waiting. And yes, i lot my data.
Kyrre: because stuff isn't broken out by language yet. You can't do
this unless there are additional packages for each language you wish
to support. That's going to happen for FC4.
The whole reason this started was because people whined about "I wan't
my dictionary installed and working by default", which is fine, but
not possible with a monolithic language package, which was being done
for other reasons.
This is targetted to be fixed for FC4 by splitting up -i18n into
language packs. I'm working on finding a fix for FC3 that I hope to
push as an update.
*** Bug 138993 has been marked as a duplicate of this bug. ***
*** Bug 136133 has been marked as a duplicate of this bug. ***
*** Bug 140026 has been marked as a duplicate of this bug. ***
*** Bug 138025 has been marked as a duplicate of this bug. ***
Clarify title (doesn't crash, just uses so much memory that the
Out-Of-Memory killer kills OOo).
As an update, new RPMS will take the dictionary.lst file and do a:
cat dictionary.lst | sort | uniq
This should help the problem. I will most likely also trim the
dictionary list to remove less common dictionaries (bg, la, ca_ES,
de_AT, de_CH, el_GR, others). Note that these can be _easily_
installed using DicOOO (File->Autopilot->Install New Dictionaries...).
Dictionary list has been trimmed in 1.1.2-16 and later. This is only
temporary and will be reverted when we split the language packs out
into separate RPMs.
*** Bug 142808 has been marked as a duplicate of this bug. ***
*** Bug 143698 has been marked as a duplicate of this bug. ***
(In reply to comment #13)
> Clarify title (doesn't crash, just uses so much memory that the
> Out-Of-Memory killer kills OOo).
On my machine even after four hours OpenOffice.org is not killed by OOM.
The only method I have found to sucessfully gain control of the computer is to
do a hard reset on the computer.
I still have the problem with FC3. The memory usage is so bad that
linux starts furiously swapping (though I have 384 MB RAM!) and I lose
all keyboard & mouse responsiveness -- after 5 minutes I can't even
switch to a console, let alone check memory usage. The only solution
is hard power off.
This bug is very critical for me, since it means I need to boot into
windows 2000 for much of my work just for a stable, non-crashing OS.
(Though I'll try the workarounds listed above.) Thanks.
Brendan, see Comment #14 for a workaround that should help your
problem for now.
This happened in RH 9.0 too: Bug 88268
How do I unsubscribe from this list and could someone add that
information to the help section. That would be keen.
*** Bug 144962 has been marked as a duplicate of this bug. ***
Default dictionary list is indeed trimmed with openoffice.org-1.1.2-18.6.EL4 so
that should make things better for now, but still need to do the work to split
out the languages.
In 1.9.85-1 and above I've split the dictionaries up into the langpacks and
modified the myspell startup to examine to see which dictionaries are actually
available at start time. So the split up of dictionaries is implemented for fc4.