Bug 164334 - Spell checking can start silently failing to spot misspelled words
Spell checking can start silently failing to spot misspelled words
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: evolution (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Matthew Barnes
Depends On:
Blocks: 170416
  Show dependency treegraph
Reported: 2005-07-26 20:53 EDT by John Devereaux
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-07-21 12:25:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description John Devereaux 2005-07-26 20:53:35 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050719 Red Hat/1.0.6-1.4.1 StumbleUpon/1.9992 Firefox/1.0.6

Description of problem:
During writing a email to a remote user, I use the spell check feature and it never finds a spelling error on my emails. I deliberately write incorrect words and the spell check tool simply informs me that there is no spelling errors.

Version-Release number of selected component (if applicable):
gtkhtml3-3.3.2-3 evolution-2.0.2-16

How reproducible:

Steps to Reproduce:
1. Up2date -u to RHEL 4 U1 Desktop
2. Configure Evolution to a IMAP Server
3. Start Evolution, create a email message
4. Type incorrect words
5. Do a spell check
6. Spell Check engine informs me that there is no spelling errors

Actual Results:  Spell Check Tool does not identify incorrect words in email messages. 

Expected Results:  Should have identified the incorrect words. Always informs me that the spelling is ok. 

Additional info:

Comment 3 Christopher Blizzard 2005-10-19 20:54:22 EDT
Devel NAK for U3.
Comment 4 John Devereaux 2005-11-09 12:12:40 EST

Running evolution from the command line revealed:
** (evolution:5686): WARNING **: aspell error: The file
"/home/jdeverea/.aspell.en.pws" is not in the proper format.

This turns out to be a zero-byte file
Moving it out of the way and trying again:
** (evolution:5799): WARNING **: aspell error: The file
"/home/jdeverea/.aspell.en.prepl" is not in the proper format.
(another 0 byte file)

Moving this out of the way, and trying again, and spell checking is working again.

Seems to have fixed it for this user/computer; however, this is a pernicious
bug, as it fails silently.

Need to investigate how the zero-byte files got created, if they're intended to
be valid, and if we can give some kind of indication to the user that
spellchecking is not going to work, rather than merely logging it to the console.
Comment 6 Dave Malcolm 2005-11-09 12:19:50 EST
Renaming bug to better describe symptoms from an Evolution-user's point of view
Comment 7 Dave Malcolm 2005-11-09 12:36:47 EST
"aspell error:" can be generated in gnome-spell/dictionary.c in update_engine()
and in engine_check_word()

In both cases, they call raise_error() which creates a
GNOME_Spell_Dictionary_Error and sets it as the exception in the

update_engine() is called by update_engines() and looks like it will accumulate
the last CORBA error if one occurred. (error occurring as a result of call to
new_aspell_speller or delete_aspell_speller)

update_engines() is called by all of the impl functions of
GNOME_Spell_Dictionary, and it looks like none of the references there correctly
handle CORBA errors.

engine_check_word() is called by impl_gnome_spell_dictionary_check_word which
seems to correctly propagate the error back.

Finally, looking at gtkhtml-3.3.2/components/html-editor/spell.c, it looks like
the caller throws away any CORBA errors set in the environment.

To summarize:  
Analysis of why there's no GUI feedback: any failures in updates_engines() when
initializing aspell/pspell will be thrown away inside the implementation of
gnome-spell; failures in engine_check_word will be propagated up to gtkhtml, but
they get thrown away inside gtkhtml.

Haven't yet looked at why the failure occurred, and how to reproduce.
Comment 12 RHEL Product and Program Management 2006-07-21 12:25:21 EDT
Development Management has reviewed and declined this request.  You may appeal this decision by reopening this request.

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