bug#84: Acknowledgement (23.0.60; Occasional hangs in flyspell-mode and ispell-word)

[Markus Triska]

I now think the previous patch only fixes a symptom of an underlying
problem, which is that the aspell process occasionally receives SIGPIPE
and terminates unexpectedly. Here's a simpler test case - it seems to
work only on OSX and with Emacs >= 23, but I have seen very similar
problems on other systems and with Emacs <= 22 too (for example, when
replying to a post in Gnus, sometimes aspell would die and not be
restarted). Let f.el consist of:

   (defun reactivate-flyspell ()
     (unless (memq 'flyspell-post-command-hook post-command-hook)
       (flyspell-mode 1)))

   (setq my-idle (run-with-idle-timer 0.1 t 'reactivate-flyspell))

If I then do:

1) $ emacs -Q f.el -f eval-buffer

2) enter and leave Gnus twice: M-x gnus RET q y M-x gnus RET q y

3) kill the aspell process:
   
   M-! killall -9 aspell RET

   (aspell is instantly restarted by the idle timer, and you can attach
    gdb to the new process to verify the signal in the next step.)
   
4) M-x gnus RET q y  (==> you're back in f.el - do anything, like C-n)

   Now aspell receives SIGPIPE and exits, and I get EBADF in
   wait_reading_process_output; the previous patch handles this, and
   thus you can at least interrupt the wait. Ideally though, the aspell
   process would not have been killed in the first place, and besides,
   after SIGPIPE, the process status should become 'signal eventually.

I would like to trace down where the SIGPIPE comes from, and how the
file descriptor can become invalid in Emacs; I've traced through the
Lisp code of Gnus and flyspell/ispell, and they seem not to touch the
aspell process here.  What would be a good place to put a breakpoint in
GDB, such that I can observe execution right after the final "C-n" in
f.el?  I tried to raise an error in before-change-functions in f.el, and
instead of "C-n" insert a character in the last step, so that I can put
a breakpoint in Fsignal, but the SIGPIPE occurs before this hook.