From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3)
Gecko/20050104 Red Hat/1.4.3-3.0.7
Description of problem:
aspell check index.html
does not to terminate. The memory footprint grows and grows. Running
strace shows that it's in some loop trying to allocate memory.
aspell --mode=none check index.html
will operate correctly.
Trying LANG=C aspell check index.html
to remove possible locale problems has the same effect.
(I don't see an easy way of reverting to a previous aspell version,
too many dependencies).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. aspell check anyfile.html
Actual Results: Nothing. It sits and waits.
Expected Results: A spell check screen should appear.
I'm also able to recreate this problem using aspell-0.33.7.1-25. I use the
/usr/bin/aspell -a -d american -H
This is actually a pretty serious problem. If anyone uses Horde/IMP webmail on
my server, and asks Horde/IMP to do Spell Check, it uses these options and this
causes my server to crash! This seems like a simple way to crash a server remotely.
Also confirmed in RHEL 3 i386 AS U5 with aspell-0.33.7.1-25.3 installed.
In the strace logfile we found the suspicious line
open("/usr/share/aspell/SGML&iso8859-1.map", O_RDONLY) = -1 ENOENT (No such file
I assume it meant to open /usr/share/aspell/SGML.map ?
Still strange that it does not handle this gracefully.
this is a serious bug disabling quite a bit of software (moodle is one example)
from working properly because it operates with HTML documents and "-H" (or
--mode=sgml) is essential...
It's quite surprising that it haven't been adressed for longer time
Thank you for your comments.
The test version (aspell-0.33.7.1-25.3.test), which should fix this bug is on
http://people.redhat.com/varekova/work.html there are i386 sources too). Could
you please test this version?
The test aspell works for me. Funny thing is that I had tried the same fix, but
my version failed misserably.
Thank you for testing Matthias. Your suggestion in comment 3 is very close to
the patch in attached test version.
Another confirmation that the test package solves the problem on RHEL3 AS U6
i386. I thought I saw this issue on RHEL4 AS U3 i386 but I couldn't replicate it
so I didn't test the new package there.
Thanks for getting this fixed!
This fixes it for me too.. sorry I didn't respond more quickly..
Thank you for your tests.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.