bug#22976: 24.5; setting unread-command-events to non cons puts emacs in 100% CPU use

bug#22976: 24.5; setting unread-command-events to non cons puts emacs in 100% CPU use

[Eyal Lotem]

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

As can be reproduced easily:

(setq unread-command-events 1) -- emacs now at 100% CPU
(setq unread-command-events nil) -- emacs OK again


In GNU Emacs 24.5.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8)
 of 2015-12-11 on eyal-XPS13-9333
Windowing system distributor `The X.Org Foundation', version 11.0.11501000
System Description: Linux Mint 17.3 Rosa

Configured using:
 `configure --prefix=/usr/local'

Important settings:
  value of $LC_MONETARY: en_US.UTF-8
  value of $LC_NUMERIC: en_US.UTF-8
  value of $LC_TIME: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Emacs-Lisp

Minor modes in effect:
  column-enforce-mode: t
  global-auto-revert-mode: t
  delete-selection-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  better-registers: t
  show-paren-mode: t
  ido-everywhere: t
  global-git-gutter+-mode: t
  git-gutter+-mode: t
  diff-auto-refine-mode: t
  global-git-commit-mode: t
  shell-dirtrack-mode: t
  helm-autoresize-mode: t
  global-eclim-mode: t
  recentf-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Grep finished (matches found) [2 times]
scroll-up-command: End of buffer [9 times]
Mark set
Mark saved where search started [8 times]
Quit [2 times]
user-error: No further undo information
Mark set
scroll-down-one: Beginning of buffer [16 times]
Mark set [2 times]
scroll-up-command: End of buffer

Load-path shadows:
/usr/local/share/emacs/24.5/lisp/emacs-lisp/cl-lib hides
~/.emacs.d/lisp/cl-lib

Features:
(shadow sort mail-extr emacsbug sendmail helm-command helm-elisp
helm-eval edebug eldoc helm-mode hideshow cc-langs misearch
multi-isearch winner image-file key-bindings git-timemachine init
haskell-simple-indent haskell haskell-completions haskell-load
haskell-commands highlight-uses-mode haskell-modules haskell-sandbox
haskell-repl haskell-debug haskell-interactive-mode
haskell-presentation-mode haskell-collapse haskell-navigate-imports
haskell-compile haskell-process haskell-session haskell-cabal
haskell-utils haskell-mode-autoloads smooth-scrolling
column-enforce-mode autorevert filenotify delsel etags-table
auto-install anything woman man grep-a-lot haskell-font-lock
haskell-mode haskell-string haskell-sort-imports haskell-lexeme
haskell-align-imports haskell-compat haskell-complete-module noutline
outline flymake dabbrev haskell-customize haskell-indentation hl-line
keymaps tags-ext undo-tree diff better-registers c-functions os
mode-hooks settings paren grep-all dired-ext indent-region my-custom ido
whitespace cus-start cus-load git-gutter+ magit-blame magit-stash
magit-bisect magit-remote magit-commit magit-sequence magit magit-apply
magit-wip magit-log magit-diff smerge-mode diff-mode magit-core
magit-process magit-popup magit-mode magit-git crm magit-section
magit-utils git-commit log-edit message rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums
mailabbrev mail-utils gmm-utils mailheader pcvs-util add-log with-editor
tramp-sh server ctx-switch-face cc-mode cc-fonts cc-guess cc-menus
cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs flycheck-via-make
flycheck help-mode subr-x dash hindent helm-proc proced helm-git-grep
helm-ls-git helm-files image-dired tramp tramp-compat tramp-loaddefs
trampver shell pcomplete format-spec dired-x dired-aux ffap helm-buffers
helm-elscreen helm-tags helm-bookmark helm-adaptive helm-info bookmark
pp helm-locate helm-grep helm-regexp helm-plugin helm-external helm-net
browse-url xml url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf url-util url-parse auth-source
gnus-util mm-util mail-prsvr password-cache url-vars mailcap helm-utils
helm-help helm-types helm helm-source eieio byte-opt bytecomp
byte-compile cl-extra cconv eieio-core helm-multi-match helm-lib dired
vc-git derived grep vc-dir ewoc vc vc-dispatcher helm-config
helm-autoloads helm-easymenu async-bytecomp find-func async eclimd eclim
eclim-problems eclim-maven compile comint ansi-color eclim-ant
eclim-completion eclim-c advice help-fns json eclim-project easy-mmode
edmacro kmacro s ucs-normalize etags ring multiple-cursors-autoloads
package epg-config recentf tree-widget wid-edit cl-macs cl gv
cl-loaddefs cl-lib goto-last-change momentary-display gitattributes-mode
thingatpt easymenu gitignore-mode gitconfig-mode conf-mode rx time-date
tooltip electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
x-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list
newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer nadvice loaddefs button faces cus-face macroexp
files text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 16 610905 39178)
 (symbols 48 43800 3)
 (miscs 40 456 1223)
 (strings 32 106130 7082)
 (string-bytes 1 2986246)
 (vectors 16 58622)
 (vector-slots 8 953242 40103)
 (floats 8 216 552)
 (intervals 56 8293 188)
 (buffers 960 25)
 (heap 1024 55943 3098))


-- 
Eyal

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

bug#22976: 24.5; setting unread-command-events to non cons puts emacs in 100% CPU use

[Andreas Schwab]

Eyal Lotem <eyal.lotem@gmail.com> writes:

> As can be reproduced easily:
>
> (setq unread-command-events 1) -- emacs now at 100% CPU
> (setq unread-command-events nil) -- emacs OK again

Don't do that then.

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."

bug#22976: 24.5; setting unread-command-events to non cons puts emacs in 100% CPU use

[Eyal Lotem]

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

I don't, but some buggy packages I use do!

Instead of wasting me hours chasing these bugs, why not output an explicit
error and set the var to nil?

This behavior caused the bug in the first place (subtle enough wrong
behavior instead of explicit error made it go unnoticed).

I'm not the first one to waste hours on this...

On Thu, Mar 10, 2016, 11:42 Andreas Schwab <schwab@suse.de> wrote:

> Eyal Lotem <eyal.lotem@gmail.com> writes:
>
> > As can be reproduced easily:
> >
> > (setq unread-command-events 1) -- emacs now at 100% CPU
> > (setq unread-command-events nil) -- emacs OK again
>
> Don't do that then.
>
> 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."
>

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

bug#22976: 24.5; setting unread-command-events to non cons puts emacs in 100% CPU use

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Date: Thu, 10 Mar 2016 10:42:53 +0100
> Cc: 22976@debbugs.gnu.org
> 
> Eyal Lotem <eyal.lotem@gmail.com> writes:
> 
> > As can be reproduced easily:
> >
> > (setq unread-command-events 1) -- emacs now at 100% CPU
> > (setq unread-command-events nil) -- emacs OK again
> 
> Don't do that then.

Can unread-command-events be anything but nil or a cons cell?  If not,
we could change the few tests of the value to explicitly ignore
non-nil, non-cons values.  Do you see any immediate problems with such
a change?

Thanks.

bug#22976: 24.5; setting unread-command-events to non cons puts emacs in 100% CPU use

[Eyal Lotem]

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

It can be set to any value at all, unfortunately.

The problem now is that non-cons/non-nil values are ignored.
The loop to repeatedly thinks there's input so it consumes 100% cpu, each
iteration seeing that it isn't a cons cell, so there's "nothing to do".

On Thu, Mar 10, 2016 at 12:25 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Andreas Schwab <schwab@suse.de>
> > Date: Thu, 10 Mar 2016 10:42:53 +0100
> > Cc: 22976@debbugs.gnu.org
> >
> > Eyal Lotem <eyal.lotem@gmail.com> writes:
> >
> > > As can be reproduced easily:
> > >
> > > (setq unread-command-events 1) -- emacs now at 100% CPU
> > > (setq unread-command-events nil) -- emacs OK again
> >
> > Don't do that then.
>
> Can unread-command-events be anything but nil or a cons cell?  If not,
> we could change the few tests of the value to explicitly ignore
> non-nil, non-cons values.  Do you see any immediate problems with such
> a change?
>
> Thanks.
>



-- 
Eyal

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

bug#22976: 24.5; setting unread-command-events to non cons puts emacs in 100% CPU use

[Eli Zaretskii]

> Date: Thu, 10 Mar 2016 12:34:08 +0200
> From: Eyal Lotem <eyal.lotem@gmail.com>
> Cc: Andreas Schwab <schwab@suse.de>, 22976@debbugs.gnu.org
> 
> It can be set to any value at all, unfortunately.

That's not what I asked.  I asked whether non-nil, non-cons values
have any meaning in unread-command-events.

> The problem now is that non-cons/non-nil values are ignored.
> 
> The loop to repeatedly thinks there's input so it consumes 100% cpu, each iteration seeing that it isn't a cons
> cell, so there's "nothing to do".

Exactly.  So these values aren't ignored, they create an illusion that
some input is available.  I was thinking about ignoring them entirely,
i.e. treating such values as nil (and maybe even silently replacing
them with nil).

The question is: would that kind of change break something?

bug#22976: 24.5; setting unread-command-events to non cons puts emacs in 100% CPU use

[Eyal Lotem]

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

On Thu, Mar 10, 2016 at 12:39 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Thu, 10 Mar 2016 12:34:08 +0200
> > From: Eyal Lotem <eyal.lotem@gmail.com>
> > Cc: Andreas Schwab <schwab@suse.de>, 22976@debbugs.gnu.org
> >
> > It can be set to any value at all, unfortunately.
>
> That's not what I asked.  I asked whether non-nil, non-cons values
> have any meaning in unread-command-events.
>

Don't think they do. They are an error.

>
> > The problem now is that non-cons/non-nil values are ignored.
> >
> > The loop to repeatedly thinks there's input so it consumes 100% cpu,
> each iteration seeing that it isn't a cons
> > cell, so there's "nothing to do".
>
> Exactly.  So these values aren't ignored, they create an illusion that
> some input is available.  I was thinking about ignoring them entirely,
> i.e. treating such values as nil (and maybe even silently replacing
> them with nil).
>

Ah, sorry I misunderstood originally!

That sounds good to me (though it would be slightly better to warn about it
somewhere, IMO)



>
> The question is: would that kind of change break something?
>

I think most scenarios it would break would be ones that currently consume
100% cpu. So besides scenarios like https://xkcd.com/1172/ it is unlikely :)


-- 
Eyal

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

bug#22976: 24.5; setting unread-command-events to non cons puts emacs in 100% CPU use

[Eli Zaretskii]

> Date: Thu, 10 Mar 2016 14:40:24 +0200
> From: Eyal Lotem <eyal.lotem@gmail.com>
> Cc: Andreas Schwab <schwab@suse.de>, 22976@debbugs.gnu.org
> 
>  > The problem now is that non-cons/non-nil values are ignored.
>  >
>  > The loop to repeatedly thinks there's input so it consumes 100% cpu, each iteration seeing that it isn't
>  a cons
>  > cell, so there's "nothing to do".
> 
>  Exactly. So these values aren't ignored, they create an illusion that
>  some input is available. I was thinking about ignoring them entirely,
>  i.e. treating such values as nil (and maybe even silently replacing
>  them with nil).
> 
> Ah, sorry I misunderstood originally!
> 
> That sounds good to me (though it would be slightly better to warn about it somewhere, IMO)

No further comments, so I installed a fix along the above-mentioned
lines on the emacs-25 branch, and I'm marking this bug done.