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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 39137 in the body.
You can then email your comments to 39137 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bob Rogers <rogers <at> modulargenetics.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.3; ispell-really-hunspell sometimes fails in init
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.

   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; just a warning to
anyone who fails to reproduce this.  But since it fails in "emacs -Q" on
systems with apparently identical software, I am at a complete loss to
figure this out.

When it fails, the backtrace looks like this:

	Debugger entered--Lisp error: (wrong-type-argument stringp nil)
	  string-match("," nil 0)
	  split-string(nil "," t)
	  ispell-parse-hunspell-affix-file(nil)
	  ispell-hunspell-fill-dictionary-entry(nil)
	  ispell-start-process()
	  ispell-init-process()
	  ispell-buffer-local-words()
	  ispell-accept-buffer-local-defs()
	  ispell-word(nil nil nil t)
	  funcall-interactively(ispell-word nil nil nil t)
	  call-interactively(ispell-word nil nil)
	  command-execute(ispell-word)

The problem seems to be related to this code in the start of
ispell-start-process:

  ;; 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.

   I don't know where or how ispell-current-dictionary is getting set up
on some systems but not on others, nor how it ought to be set up, so I
am unable to take this any further.


					-- Bob Rogers
					   Modular Genetics Inc.
					   http://www.modulargenetics.com/

------------------------------------------------------------------------
In GNU Emacs 26.3 (build 1, x86_64-suse-linux-gnu, GTK+ Version 3.22.30)
 of 2019-11-21 built on yuggoth
Windowing system distributor 'The X.Org Foundation', version 11.0.12003000
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Entering debugger...

Configured using:
 'configure --with-pop --without-dbus --without-gsettings
 --without-gconf --prefix=/usr --infodir=/usr/share/info
 --mandir=/usr/share/man --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --with-x --with-xpm=no --with-jpeg --with-tiff --with-gif=no --with-png
 --with-x-toolkit=gtk3 --x-includes=/usr/X11R6/include
 --x-libraries=/usr/X11R6/lib64 --build x86_64-suse-linux 'CFLAGS=-g -O2
 -fno-optimize-sibling-calls' LDFLAGS=-s'

Configured features:
JPEG TIFF PNG RSVG SOUND GLIB NOTIFY GNUTLS LIBXML2 FREETYPE XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM THREADS

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Debugger

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq dired
dired-loaddefs format-spec rfc822 mml mml-sec password-cache epa derived
epg epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils help-mode
easymenu cl-print byte-opt gv bytecomp byte-compile cl-loaddefs cl-lib
cconv debug ispell elec-pair time-date mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads inotify dynamic-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 100243 8442)
 (symbols 48 20704 1)
 (miscs 40 88 143)
 (strings 32 30091 1374)
 (string-bytes 1 795489)
 (vectors 16 15184)
 (vector-slots 8 514416 10616)
 (floats 8 55 85)
 (intervals 56 284 0)
 (buffers 992 12))

Message #8 received at 39137 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Bob Rogers <rogers <at> modulargenetics.com>
Cc: 39137 <at> debbugs.gnu.org
Subject: Re: 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.

Message #11 received at 39137 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39137 <at> debbugs.gnu.org, Bob Rogers <rogers <at> modulargenetics.com>
Subject: Re: bug#39137: 26.3; ispell-really-hunspell sometimes fails in init
Date: Fri, 29 Jan 2021 08:27:00 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> 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.

More information was requested, but no response was given within a
year, so I'm closing this bug report.  If the problem still exists,
please respond to this email and we'll reopen the bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #20 received at 39137 <at> debbugs.gnu.org (full text, mbox):

From: Bob Rogers <rogers <at> modulargenetics.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 39137 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#39137: 26.3; ispell-really-hunspell sometimes fails in init
Date: Tue, 23 Mar 2021 18:13:29 -0400

   From: Lars Ingebrigtsen <larsi <at> gnus.org>
   Date: Fri, 29 Jan 2021 08:27:00 +0100

   Eli Zaretskii <eliz <at> gnu.org> writes:

   > 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.

   More information was requested, but no response was given within a
   year, so I'm closing this bug report.  If the problem still exists,
   please respond to this email and we'll reopen the bug report.

My apologies for being so lazy, but I finally got around to checking
this out.  I went to reproduce the problem and found that the current
Emacs 27.2-rc2 on the affected system now produces the following error
message:

	ispell-find-hunspell-dictionaries: Can t find Hunspell dictionary with a .aff affix file

So it was a Hunspell configuration issue (further investigation found
the missing RPM), and not an Emacs problem.  And I'm glad to see that
the Hunspell initialization now reports this intelligibly.

					-- Bob

Message #23 received at 39137 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Bob Rogers <rogers <at> modulargenetics.com>
Cc: 39137 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#39137: 26.3; ispell-really-hunspell sometimes fails in init
Date: Wed, 24 Mar 2021 09:11:58 +0100

Bob Rogers <rogers <at> modulargenetics.com> writes:

> 	ispell-find-hunspell-dictionaries: Can t find Hunspell dictionary with a .aff affix file
>
> So it was a Hunspell configuration issue (further investigation found
> the missing RPM), and not an Emacs problem.  And I'm glad to see that
> the Hunspell initialization now reports this intelligibly.

Thanks for checking.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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