Looks like you have nailed it. If I now think about it, this has happened
only after an error (but not always after an error).

Last time this happened was after I was trying to intentionally generate an
error by evaluating

(string-match-p "." nil)

That was part of testing out some elisp, but that's a different story. I
basically needed to try some snippet that would generate error and I came
up with above.

I later find that the above causes emacs to freeze when using my config,
but not in emacs -Q (master branch).

I can get out of the emacs freeze by hitting C-g. But then I get:

Entering debugger...
Error during redisplay: (jit-lock-function 1619) signaled
(args-out-of-range 0 1622)
Error during redisplay: (jit-lock-function 2119) signaled
(args-out-of-range 0 2131)
Error during redisplay: (jit-lock-function 2619) signaled
(args-out-of-range 0 2684)
Error during redisplay: (jit-lock-function 3119) signaled
(args-out-of-range 0 3364)
help-function-arglist: End of file during parsing
Error in post-command-hook (global-font-lock-mode-check-buffers): (quit)
Error during redisplay: (jit-lock-function 1619) signaled (quit)
Error during redisplay: (jit-lock-function 1620) signaled (quit)
Quit [8 times]

So then I repeated generating the above error to figure out what in my
config is causing it (still haven't figured it out).

The strange thing is that

(string-match-p "." nil)

generates proper backtrace as expected when using my config:
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  string-match("." nil)
  eval((string-match "." nil) nil)
  eval-expression((string-match "." nil) nil)
  funcall-interactively(eval-expression (string-match "." nil) nil)
  call-interactively(eval-expression nil nil)
  command-execute(eval-expression)

Note that I simply replaced string-match-p with string-match. So error
backtrace generation has been working fine for me, except that "(string-match-p
"." nil)" triggers some bug in my config that causes emacs to freeze, and
that's most likely what's wiping the bindings, except that I cannot
recreate the binding loss scenario.

In one of such intentionally generated error trials, I lost all the
bindings. (I have no idea was help-function-arglist has to do in this. I
grepped my config, packages, but couldn't figure out what that has to do
with error caused by using nil instead of a string.)


On Mon, Jul 11, 2016 at 10:43 AM Eli Zaretskii <eliz@gnu.org> wrote:

> One of those (or something similar) done by some code that fails to
> unwind-protect itself, and so leaves these values behind when you type
> C-g or some other error is signaled.
>
-- 

-- 
Kaushal Modi