GNU bug report logs - #39137
26.3; ispell-really-hunspell sometimes fails in init

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Bob Rogers <rogers <at> modulargenetics.com>
Cc: 39137 <at> debbugs.gnu.org
Subject: bug#39137: 26.3; ispell-really-hunspell sometimes fails in init
Date: Sat, 18 Jan 2020 12:14:55 +0200

> From: Bob Rogers <rogers <at> modulargenetics.com>
> Date: Tue, 14 Jan 2020 16:25:07 -0500
> 
>    Spell checking can die with "(wrong-type-argument stringp nil)" when
> ispell-really-hunspell is true.  To reproduce (if it reproduces at all
> on your system), just do "emacs -Q" with Hunspell installed and M-$ on
> any of the words in the startup screen.

Granted, this doesn't reproduce on my system.  And I have difficulty
understanding how could it reproduce on _any_ system, especially in
"emacs -Q".

>    On some of the systems I use, it fails reliably when initializing; on
> others, it works reliably.  All systems are running the openSUSE Leap
> 15.1 release of GNU/Linux, fully updated, with the identical locally-
> built RPM version of Emacs 26.3 (with no local patches) and the distro
> Hunspell 1.6.2.  The key seems to be whether ispell-dictionary-alist is
> initialized before ispell-start-process is called

Can you step through the ispell.el's initialization code, and explain
how come ispell-dictionary-alist ends up being uninitialized by the
time ispell-start-process is called for spell-checking?  This
shouldn't happen.

>   ;; Parse hunspell affix file if using hunspell and entry is uninitialized.
>   (if ispell-really-hunspell
>       (or (cadr (assoc ispell-current-dictionary ispell-dictionary-alist))
> 	  (ispell-hunspell-fill-dictionary-entry ispell-current-dictionary)))
> 
> It appears that "nil" is valid for ispell-current-dictionary and means
> "default", but ispell-hunspell-fill-dictionary-entry expects only a
> string.  On that basis, I would claim that there is a bug that has
> perhaps been hidden by being on a rare execution path.  But if
> ispell-dictionary-alist is already initialized with a "nil" entry, then
> ispell-hunspell-fill-dictionary-entry never gets called, leading to the
> "reproducible irreproducibility" of this bug.  And if
> ispell-dictionary-alist should *always* be initialized and contain the
> current entry, then this is dead code.

It isn't dead code, it just assumes that either
ispell-current-dictionary is nil and there's a nil entry in
ispell-dictionary-alist, or it is a string that specifies a new
dictionary, which is then used to update ispell-dictionary-alist.

We need to establish how come the first assumption is false on those
affected systems.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.