Understanding the cause of a bug causing *all* bindings to be wiped out

Understanding the cause of a bug causing *all* bindings to be wiped out

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 1580 bytes --]

Hi all,

Lately, I have seen this issue on the master branch. It's difficult to tell
if something in my config is causing this, something in the master branch.

The bug is that something suddenly causes *all* bindings to get wiped out.
So I cannot do even C-h l to see what I typed that caused that to happen.
Also M-x gets unbound, along with *all* other bindings. So no C-n/C-p, C-x
C-c, etc.

The only way I can get out of that is by killing emacs from the terminal.
When I start emacs again, everything is fine again.

I have seen the sudden bindings blackout happen to me for, I believe, 3
times by now, all while on the master branch build, probably in last 2-3
weeks.

But I do not know if the bug is localized in the master branch or my config.

Can anyone give me hints as to what kind of config mess-up can cause this?
Or has anyone else on master branch also seen this happen?

Below is my version info.

Emacs version: GNU Emacs 25.1.50.16 (x86_64-unknown-linux-gnu, GTK+ Version
2.24.23)
 of 2016-07-10, built using commit 466ee1b3ea76425d201b5d59950e88251870c836.

./configure options:
  --with-modules --prefix=/home/kmodi/usr_local/apps/6/emacs/master
'CPPFLAGS=-fgnu89-inline -I/home/kmodi/usr_local/6/include
-I/usr/include/freetype2 -I/usr/include' 'CFLAGS=-O2 -march=native'
'LDFLAGS=-L/home/kmodi/usr_local/6/lib -L/home/kmodi/usr_local/6/lib64'

Features:
  XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK2 X11 MODULES

Thanks.
-- 

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 2028 bytes --]

Re: Understanding the cause of a bug causing *all* bindings to be wiped out

[Andreas Schwab]

Kaushal Modi <kaushal.modi@gmail.com> writes:

> I have seen the sudden bindings blackout happen to me for, I believe, 3
> times by now, all while on the master branch build, probably in last 2-3
> weeks.
>
> But I do not know if the bug is localized in the master branch or my config.
>
> Can anyone give me hints as to what kind of config mess-up can cause this?

Maybe global-map is being clobbered.  Try attaching with a debugger and
inspecting global_map and current_global_map.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Understanding the cause of a bug causing *all* bindings to be wiped out

[Stefan Monnier]

> Maybe global-map is being clobbered.

Or maybe it's a high-priority map that's hiding all the bindings.


        Stefan

Re: Understanding the cause of a bug causing *all* bindings to be wiped out

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 1210 bytes --]

On Mon, Jul 11, 2016 at 8:33 AM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> Or maybe it's a high-priority map that's hiding all the bindings.
>

I do use high-priority map. But basic bindings like C-x C-c, C-n/C-p, etc
are in the global map. Also this bug causes all those keys to be totally
unbound. So it's not as if a high-priority map is masking a global map key.
If it is unbound, it is unbound in both high-priority and global maps,
right?

Next time this happens, I'll see if my high-priority map bindings are
intact. To prepare for that, I will bind C-h l to the high priority map too
so that they work even if global map is wiped out (there's probably no
point binding M-x, M-:, etc in high-priority map because the self insert
bindings are wiped out too).

On Mon, Jul 11, 2016 at 3:29 AM Andreas Schwab <schwab@suse.de> wrote:

> Maybe global-map is being clobbered.  Try attaching with a debugger and
> inspecting global_map and current_global_map.
>

Thanks. I'll give that a try next time this happens. Unfortunately, I just
need to wait until it happens again as I have no idea what causes this.
Will also note if that happens in a particular major mode next time.
-- 

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 2079 bytes --]

Re: Understanding the cause of a bug causing *all* bindings to be wiped out

[Stefan Monnier]

> If it is unbound, it is unbound in both high-priority and global maps,
> right?

The overriding-local-map if non-nil disables all other maps.
And in Emacs<24.4, the same holds for overriding-terminal-local-map.

Could it be you're using a package written for Emacs>=24.4 which sets
a sparse keymap in overriding-terminal-local-map to just override a few
key bindings, but you use it with Emacs<24.4 where that ends up
disabling all other bindings?


        Stefan

Re: Understanding the cause of a bug causing *all* bindings to be wiped out

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 1350 bytes --]

I am using the emacs master build version (25.1.50.x).

Here is how I set my minor mode map:

=====
(defvar modi-mode-special-map (make-sparse-keymap)
  "Special keymap for `modi-mode' whose bindings begin with
`modi-special-keymap-prefix'.")
(fset 'modi-mode-special-map modi-mode-special-map)

(defvar modi-mode-map (let ((map (make-sparse-keymap)))
                        (define-key map modi-special-keymap-prefix
'modi-mode-special-map)
                        map)
  "Keymap for `modi-mode'.")

;; The keymaps in `emulation-mode-map-alists' take precedence over
;; `minor-mode-map-alist'
(add-to-list 'emulation-mode-map-alists `((modi-mode . ,modi-mode-map)))
=====

Also there was a typo in my previous email:

I meant:

=====
The strange thing is that

(string-match "." nil) ; *not* (string-match-p ..)

generates proper backtrace as expected ..
=====

On Mon, Jul 11, 2016 at 11:28 AM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> The overriding-local-map if non-nil disables all other maps.
> And in Emacs<24.4, the same holds for overriding-terminal-local-map.
>
> Could it be you're using a package written for Emacs>=24.4 which sets
> a sparse keymap in overriding-terminal-local-map to just override a few
> key bindings, but you use it with Emacs<24.4 where that ends up
> disabling all other bindings?

-- 

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 3026 bytes --]

Re: Understanding the cause of a bug causing *all* bindings to be wiped out

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 3941 bytes --]

I am getting some hard to debug/fix conclusions for this issue.

Looks like 2 issues are overlapping in my config; not necessarily config
but due to the packages I am installing: (1) the help-function-arglist
error and (2) emacs freezing error.

(1) Narrowed down one of the issues: "help-function-arglist: End of file
during parsing"

This is caused by just enabling global-projectile-mode (projectile package)
followed by evaluating (string-match-p "." nil)

This part at least is easily reproducible by evaluating the below in an
emacs -Q session (tested on master build).

=====
(progn
  (require 'package)
  (add-to-list 'package-archives '("melpa" . "http://melpa.org/packages/")
t)
  (package-initialize)
  (package-refresh-contents)
  (package-install 'projectile)

  (require 'projectile)
  (projectile-global-mode)
  (string-match-p "." nil))
=====

Here's the odd part .. If I replace string-match-p with string-match in the
above progn block, I do *not* get this error:

Entering debugger...
help-function-arglist: End of file during parsing

Also if I disable projectile-global-mode, I do not get this error.

Another odd element to this issue is that even after M-x
toggle-debug-on-error, above error does not result in a backtrace.

If it's of any help, projectile only advises delete-file and
compilation-find-file.

So I cannot figure out what connects the string-match-p error,
help-function-arglist error and global-projectile-mode; and why isn't this
help-function-arglist error popping up when using string-match instead of
string-match-p?

(2a) The another issue was emacs freezing up when I evaluated (string-match-p
"." nil). For now, I can prevent that if I do not load the fci package (
http://www.emacswiki.org/FillColumnIndicator ). I yet have to derive a
minimum working code to recreate that freeze on emacs -Q.

(2b) Another cause of emacs freeze was calling of define-key forms when
enabling a minor mode (drag-stuff-minor-mode from the drag-stuff package).
I need to create a minimum working version to prove this "fix" too.

For some reason, the drag-stuff package calls a function that sets the
drag-stuff-mode-map key definitions when that minor mode is enabled.

Here's the code from the package:

=====
(defun drag-stuff-define-keys ()
  "Defines keys for `drag-stuff-mode'."
  (define-key drag-stuff-mode-map (drag-stuff--kbd 'up) 'drag-stuff-up)
  (define-key drag-stuff-mode-map (drag-stuff--kbd 'down) 'drag-stuff-down)
  (define-key drag-stuff-mode-map (drag-stuff--kbd 'right)
'drag-stuff-right)
  (define-key drag-stuff-mode-map (drag-stuff--kbd 'left) 'drag-stuff-left))

;;;###autoload
(define-minor-mode drag-stuff-mode
  "Drag stuff around."
  :init-value nil
  :lighter " drag"
  :keymap drag-stuff-mode-map
  (when drag-stuff-mode
    (drag-stuff-define-keys)))
=====

The "fix" was simply to do the key binding outside the minor mode.

=====
    ;; Mon Jul 11 14:09:57 EDT 2016 - kmodi
    ;; Earlier I had the below `bind-keys' form inside
`drag-stuff-define-keys'
    ;; function. Strangely, with that, evaluation of "(string-match-p "."
nil)"
    ;; made emacs freeze. But moving it out does not! I got the same emacs
freeze
    ;; issue if I replaced `bind-keys' with `define-key' forms *inside* that
    ;; `drag-stuff-define-keys' function.
    ;; https://lists.gnu.org/archive/html/emacs-devel/2016-07/msg00519.html
    (bind-keys
     :map drag-stuff-mode-map
      ("C-M-p" . drag-stuff-up)
      ("C-M-n" . drag-stuff-down)
      ("C-M-;" . drag-stuff-left)
      ("C-M-'" . drag-stuff-right))

    (defun drag-stuff-define-keys () nil)
=====

By doing above *and* not loading fci package, I was able to prevent emacs
from freezing on evaluating (string-match-p "." nil)... No idea why.

(4) Finally I hope one or all of the above had anything to do the bindings
wipeout issue (which I still haven't been able to recreate ever since I
started this thread).
-- 

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 6351 bytes --]

Re: Understanding the cause of a bug causing *all* bindings to be wiped out

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 11 Jul 2016 08:33:32 -0400
> 
> > Maybe global-map is being clobbered.
> 
> Or maybe it's a high-priority map that's hiding all the bindings.

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.

Re: Understanding the cause of a bug causing *all* bindings to be wiped out

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 2655 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3638 bytes --]