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 /usr/lib/ooo-1.1/share/dict/ooo/fr_BE.aff 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): openoffice.org-1.1.1-4 How reproducible: Always 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 information. 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 if necessary.
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. Dan
*** 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.