bug#23424: 25.0.93; error in process sentinel with Melpa added to package-archives

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Mon, 02 May 2016 16:41:32 +0000
> Cc: 23424@debbugs.gnu.org
> 
> Breakpoint 3, Fsignal (error_symbol=41328, data=16757379) at eval.c:1471
> 1471 = (NILP (error_symbol) ? Fcar (data) : error_symbol);
> (gdb) c
> Continuing.
> 
> Breakpoint 3, Fsignal (error_symbol=41328, data=14850531) at eval.c:1471
> 1471 = (NILP (error_symbol) ? Fcar (data) : error_symbol);
> (gdb) c
> Continuing.
> 
> Breakpoint 3, Fsignal (error_symbol=41328, data=25212659) at eval.c:1471
> 1471 = (NILP (error_symbol) ? Fcar (data) : error_symbol);
> (gdb) c
> Continuing.
> 
> Breakpoint 3, Fsignal (error_symbol=41328, data=25415251) at eval.c:1471
> 1471 = (NILP (error_symbol) ? Fcar (data) : error_symbol);

This is your "Debugging Emacs 101", lesson 1:

A breakpoint in Fsignal is frequently hit because some error is thrown
which Emacs will catch and ignore, but the debugger gets to see it
first.  To see whether this is the signal you are after (if you don't
already know), do this:

  (gdb) p error_symbol
  (gdb) xsymbol

The last command should display the Lisp name of the signal.  Crystal
ball here says you will see "void-variable", which is not the signal
you want.  So now make the breakpoint conditional:

  (gdb) condition 3 error_symbol != 41328
  (gdb) c

and see what other signal is thrown.  I had a couple of other
unrelated signals (which happened once each, so I didn't feel like
making the condition more complex), and finally you will get your
expected "end-of-file" error.  Then look around; the Lisp backtrace
should be the first thing to look at.