Red Hat Bugzilla – Bug 142809
Openoffice.org, when started as a normal user is able to cause the system to swap uncontrollably, requiring a reboot to resolve.
Last modified: 2016-06-07 18:45:06 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.3; Linux) (KHTML, like Gecko)
Description of problem:
When the automatic spelling checker is started in Openoffice.org it results in the system swapping uncontrollably. So much so that it is not possible to terminate any of the the graphical applications, Ctrl+Alt+Backspace does not work to kill X and I am unable to log in via ssh or a virtual console to reduce the load.
The only solution is to reset the hardware and boot the system again.
The hardware is an X31 Laptop with 256Mb of RAM and 524Mb swap.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start Openoffice.org and right click on a mis-spelled word, this should launch a list of similarly spelled words that are correctly spelled.
2. The system starts swapping and becomes unresponsive, the mouse is stuttery but does not affect any application
3. A hardware reset is required to recover the system.
Actual Results: The operating system becomes unresponsive, it was left once for ten minutes and a few hours on another kernel and it would continue thrashing the disk.
Expected Results: The misbehaving application should either be killed or the system remain responsive enough for user interaction to kill processes.
This is the bug against Openoffice.org relating to the spelling checker.
I have also heard from other people that they have been able to cause similar problems with evolution or with lots of "cutting and pasting"
This is a tricky problem. I suspect the system feels unresponsive because of the
sheer amounting of swaping that is going on (and laptop hard disks often have
low throughput so this would take an age). However until most of the swap is
exhausted the OOM killer won't normally come out. To stay responsive you would
have had to have had a very twitchy OOM killer or to have not allowed OOo to use
so much swap. You could try changing /proc/sys/vm/overcommit_ratio to a lower
number like 25 to see whether that halts OOo's growth quicker...
This sounds more like an openoffice bug than a kernel bug.
You keep asking for memory, the kernel keeps giving it to you
(until you run out of swap, or resource limits kick in).
However, it's possible that you're seeing some inefficieny of the vm layer.
Is the current 2.6.10 update kernel any better ?
See also this thread
I don't know that it's a kernel bug but I think it's an OS bug that a user app
can effectively shut down the OS for hours (or really, indefinitely; you could
*nearly* exhaust VM then just keep allocating and freeing random blocks).
By "OS bug" I mean we should at least be setting some userspace tunables or
providing some sort of watchdog to avoid this problem, if we can possibly think
of a way.
Imagine a multiuser timeshare system, you wouldn't want any user to be able to
do this. And for an individual workstation, you never want an app bug to cause
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem. Please update to this new kernel, and
report whether or not it fixes your problem.
If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.
This bug has been automatically closed as part of a mass update.
It had been in NEEDINFO state since July 2005.
If this bug still exists in current errata kernels, please reopen this bug.
There are a large number of inactive bugs in the database, and this is the only
way to purge them.