* bug#22976: 24.5; setting unread-command-events to non cons puts emacs in 100% CPU use
@ 2016-03-10 8:37 Eyal Lotem
2016-03-10 9:42 ` Andreas Schwab
0 siblings, 1 reply; 8+ messages in thread
From: Eyal Lotem @ 2016-03-10 8:37 UTC (permalink / raw)
To: 22976
[-- 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 --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#22976: 24.5; setting unread-command-events to non cons puts emacs in 100% CPU use
2016-03-10 8:37 bug#22976: 24.5; setting unread-command-events to non cons puts emacs in 100% CPU use Eyal Lotem
@ 2016-03-10 9:42 ` Andreas Schwab
2016-03-10 9:47 ` Eyal Lotem
2016-03-10 10:25 ` Eli Zaretskii
0 siblings, 2 replies; 8+ messages in thread
From: Andreas Schwab @ 2016-03-10 9:42 UTC (permalink / raw)
To: Eyal Lotem; +Cc: 22976
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."
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#22976: 24.5; setting unread-command-events to non cons puts emacs in 100% CPU use
2016-03-10 9:42 ` Andreas Schwab
@ 2016-03-10 9:47 ` Eyal Lotem
2016-03-10 10:25 ` Eli Zaretskii
1 sibling, 0 replies; 8+ messages in thread
From: Eyal Lotem @ 2016-03-10 9:47 UTC (permalink / raw)
To: Andreas Schwab; +Cc: 22976
[-- 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 --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#22976: 24.5; setting unread-command-events to non cons puts emacs in 100% CPU use
2016-03-10 9:42 ` Andreas Schwab
2016-03-10 9:47 ` Eyal Lotem
@ 2016-03-10 10:25 ` Eli Zaretskii
2016-03-10 10:34 ` Eyal Lotem
1 sibling, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2016-03-10 10:25 UTC (permalink / raw)
To: Andreas Schwab; +Cc: 22976, eyal.lotem
> 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#22976: 24.5; setting unread-command-events to non cons puts emacs in 100% CPU use
2016-03-10 10:25 ` Eli Zaretskii
@ 2016-03-10 10:34 ` Eyal Lotem
2016-03-10 10:39 ` Eli Zaretskii
0 siblings, 1 reply; 8+ messages in thread
From: Eyal Lotem @ 2016-03-10 10:34 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Andreas Schwab, 22976
[-- 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 --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#22976: 24.5; setting unread-command-events to non cons puts emacs in 100% CPU use
2016-03-10 10:34 ` Eyal Lotem
@ 2016-03-10 10:39 ` Eli Zaretskii
2016-03-10 12:40 ` Eyal Lotem
0 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2016-03-10 10:39 UTC (permalink / raw)
To: Eyal Lotem; +Cc: schwab, 22976
> 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?
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#22976: 24.5; setting unread-command-events to non cons puts emacs in 100% CPU use
2016-03-10 10:39 ` Eli Zaretskii
@ 2016-03-10 12:40 ` Eyal Lotem
2016-03-26 8:54 ` Eli Zaretskii
0 siblings, 1 reply; 8+ messages in thread
From: Eyal Lotem @ 2016-03-10 12:40 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Andreas Schwab, 22976
[-- 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 --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#22976: 24.5; setting unread-command-events to non cons puts emacs in 100% CPU use
2016-03-10 12:40 ` Eyal Lotem
@ 2016-03-26 8:54 ` Eli Zaretskii
0 siblings, 0 replies; 8+ messages in thread
From: Eli Zaretskii @ 2016-03-26 8:54 UTC (permalink / raw)
To: Eyal Lotem; +Cc: schwab, 22976-done
> 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2016-03-26 8:54 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-03-10 8:37 bug#22976: 24.5; setting unread-command-events to non cons puts emacs in 100% CPU use Eyal Lotem
2016-03-10 9:42 ` Andreas Schwab
2016-03-10 9:47 ` Eyal Lotem
2016-03-10 10:25 ` Eli Zaretskii
2016-03-10 10:34 ` Eyal Lotem
2016-03-10 10:39 ` Eli Zaretskii
2016-03-10 12:40 ` Eyal Lotem
2016-03-26 8:54 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).