Bug 124374 - Terminal memory usage when right-clicking on a misspelled word
Summary: Terminal memory usage when right-clicking on a misspelled word
Alias: None
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
(Show other bugs)
Version: 2
Hardware: i686 Linux
Target Milestone: ---
Assignee: Caolan McNamara
QA Contact:
: 136133 138025 138993 140026 142808 143698 144962 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2004-05-26 02:24 UTC by Jim
Modified: 2007-11-30 22:10 UTC (History)
18 users (show)

Fixed In Version: 1.9.85-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-21 09:06:45 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Jim 2004-05-26 02:24:56 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Gecko/20040207 Firefox/0.8

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):

How reproducible:

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.

Comment 1 Jonathan Marc Bearak 2004-05-27 18:00:48 UTC
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.)

Comment 2 Jim 2004-05-27 20:50:59 UTC
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.

Comment 3 Colin Charles 2004-08-14 01:47:47 UTC
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

Comment 4 Dan Williams 2004-08-15 16:28:07 UTC
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
if necessary.

Comment 5 Colin Charles 2004-08-15 16:46:21 UTC
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?

Comment 6 Dan Williams 2004-08-16 13:29:02 UTC
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.

Comment 7 Kyrre Ness Sjøbæk 2004-11-07 13:28:33 UTC
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.

Comment 8 Dan Williams 2004-11-07 15:06:00 UTC
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.


Comment 9 Dan Williams 2004-11-30 02:42:40 UTC
*** Bug 138993 has been marked as a duplicate of this bug. ***

Comment 10 Dan Williams 2004-11-30 02:43:14 UTC
*** Bug 136133 has been marked as a duplicate of this bug. ***

Comment 11 Dan Williams 2004-11-30 02:43:34 UTC
*** Bug 140026 has been marked as a duplicate of this bug. ***

Comment 12 Dan Williams 2004-11-30 02:47:14 UTC
*** Bug 138025 has been marked as a duplicate of this bug. ***

Comment 13 Dan Williams 2004-11-30 02:50:38 UTC
Clarify title (doesn't crash, just uses so much memory that the
Out-Of-Memory killer kills OOo).

Comment 14 Dan Williams 2004-12-03 16:59:16 UTC
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...).

Comment 15 Dan Williams 2004-12-08 03:54:55 UTC
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.

Comment 16 Caolan McNamara 2004-12-15 16:03:10 UTC
*** Bug 142808 has been marked as a duplicate of this bug. ***

Comment 17 Max Kanat-Alexander 2004-12-28 05:16:11 UTC
*** Bug 143698 has been marked as a duplicate of this bug. ***

Comment 18 Xander D Harkness 2004-12-29 13:42:42 UTC
(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.

Comment 19 Brendan O'Connor 2005-01-10 19:19:39 UTC
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.

Comment 20 Warren Togami 2005-01-11 00:18:13 UTC
Brendan, see Comment #14 for a workaround that should help your
problem for now.

Comment 21 Josiah Royse 2005-01-25 15:36:39 UTC
This happened in RH 9.0 too: Bug 88268

Comment 22 Strix Nebulosa 2005-01-26 03:12:13 UTC
How do I unsubscribe from this list and could someone add that
information to the help section. That would be keen.

Comment 23 Caolan McNamara 2005-01-26 08:47:45 UTC
*** Bug 144962 has been marked as a duplicate of this bug. ***

Comment 24 Jay Turner 2005-02-10 12:42:41 UTC
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.

Comment 26 Caolan McNamara 2005-03-21 09:06:45 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.