GNU bug report logs -
#23424
better error reporting when package archives have issues
Previous Next
Full log
Message #33 received at 23424 <at> debbugs.gnu.org (full text, mbox):
> From: Kaushal Modi <kaushal.modi <at> gmail.com>
> Date: Mon, 02 May 2016 16:41:32 +0000
> Cc: 23424 <at> 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.
This bug report was last modified 9 years and 100 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.