GNU bug report logs - #13103
24.3.50; Trunk --with-ns eats 100% CPU

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13103 in the body.
You can then email your comments to 13103 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Didier Verna <didier <at> didierverna.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; Trunk --with-ns eats 100% CPU 
Date: Thu, 06 Dec 2012 14:41:03 +0100

  Hello,

the Emacs trunk eats 100% CPU on one of my cores at startup, when
compiled --with-ns. In fact, I discovered that this is the case until I
do something network'ish, like start Gnus or the emacs server. Then, the
CPU usage goes back to "normal".

This reminds me of a gethostname problem we had in XEmacs ages
ago. FWIW, this doesn't happen if I compile --with-x --without-ns (the
rest being identical). on the same machine. This doesn't happen either
with a 24.2 tarball compiled with either configuration.


In GNU Emacs 24.3.50.1 (x86_64-apple-darwin10.8.0, NS apple-appkit-1038.36)
 of 2012-12-03 on scofield.lrde.epita.fr
Bzr revision: 111073 dmantipov <at> yandex.ru-20121203080602-hwv4fug7bvt2red7
Windowing system distributor `Apple', version 10.3.1038
Configured using:
 `configure '--with-ns' '--enable-link-time-optimization'
 '--x-includes=/opt/X11/include' '--x-libraries=/opt/X11/lib''

Important settings:
  locale-coding-system: nil
  default enable-multibyte-characters: t

Major mode: Group

Minor modes in effect:
  gnus-topic-mode: t
  gnus-undo-mode: t
  show-paren-mode: t
  global-whitespace-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
o u r SPC t e ' l e ' c h a r g e r SPC l e s SPC p 
a r o l e s , SPC e t SPC l a SPC b a n d e SPC i n 
s t r u m e n t a l e SPC <backspace> , SPC h i s t 
o i r e SPC d e SPC v o u s SPC e n t r a i ^ n e r 
SPC u n SPC p e u . . . <return> <return> s-v <return> 
s-v <return> <return> F a i t e s - m o i SPC s i g 
n e SPC s i SPC v o u s SPC a v e z SPC d e s SPC p 
r o b l e ` m e s SPC p o u r SPC o u v r i r SPC d 
<backspace> c e s SPC f i c h i e r s . <return> <up> 
<return> <down> C-d <help-echo> <return> <return> <up> 
T r o i s , SPC q u a t <backspace> a a a a t r e SPC 
! C-a <return> <down> <down> <down> <down> <down> C-k 
C-k C-k C-k C-k C-k C-k C-x i . g n u s <tab> s i <tab> 
d e f <tab> <return> <down> <down> C-SPC <down> <down> 
<down> <down> <down> C-w <wheel-up> <double-wheel-up> 
<triple-wheel-up> <triple-wheel-up> <wheel-down> <double-wheel-down> 
<triple-wheel-down> <wheel-up> <double-wheel-up> <triple-wheel-up> 
<triple-wheel-up> C-c C-c x q l s g n SPC SPC q l s 
g g n SPC q SPC n q SPC q SPC d d q l s M-x r e p o 
r t - e m a c s <tab> <return>

Recent messages:
name mismatch: "XEmacs Beta Testers" changed to "XEmacs Beta Discussion"
Exiting summary buffer and applying spam rules
nnimap read 0k from imap.gmail.com
Exiting summary buffer and applying spam rules [2 times]
Saving file /Users/didier/.newsrc...
Wrote /Users/didier/.newsrc
Saving /Users/didier/.newsrc.eld...
Saving file /Users/didier/.newsrc.eld...
Wrote /Users/didier/.newsrc.eld
Saving /Users/didier/.newsrc.eld...done

Load-path shadows:
None found.

Features:
(shadow warnings emacsbug crm thingatpt cus-edit dired jka-compr
find-func debug mailalias smtpmail sendmail ispell pp gnus-draft rfc1345
quail help-mode footnote misearch multi-isearch compface gnus-fun
bbdb-gui bbdb-hooks smiley ansi-color gnus-cite flow-fill gnus-dup
mule-util sort shr-color color shr browse-url gnus-async gnus-bcklg
vc-git qp gnus-ml gnus-topic mm-archive url-http url-gw url-cache
url-auth url-handlers nnrss xml mm-url url url-proxy url-privacy
url-expand url-methods url-history url-cookie url-domsuf url-util
url-parse url-vars nndoc nndraft nnmh utf-7 nnimap utf7 gnutls nnml
parse-time bbdb-gnus bbdb-snarf mail-extr epa-file epa derived epg netrc
network-stream auth-source eieio byte-opt bytecomp byte-compile cconv
starttls tls gnus-agent gnus-srvr gnus-score score-mode nnvirtual nntp
gnus-cache spam spam-stat bbdb-com advice help-fns message-utils gnus-uu
yenc gnus-msg gnus-diary gnus-art mm-uu mml2015 epg-config mm-view
mml-smime smime password-cache dig mailcap nndiary gnus-sum gnus-group
gnus-undo nnmail mail-source nnoo gnus-start gnus-spec gnus-int
gnus-range bbdb-autoloads bbdb timezone message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mailabbrev gmm-utils mailheader gnus-win server rcfiles
slime-autoloads rcfiles-autoloads auctex-autoloads tex-site info
easymenu nlinum-autoloads package saveplace disp-table milonga-theme
cl-macs gv paren gnus gnus-ems nnheader gnus-util mail-utils mm-util
mail-prsvr wid-edit whitespace cus-start cus-load cl nadvice cl-lib
time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel ns-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
lisp-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 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 ns multi-tty
emacs)

-- 
Resistance is futile. You will be jazzimilated.

Scientific site:   http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com

EPITA/LRDE, 14-16 rue Voltaire, 94276 Le Kremlin-Bicêtre, France
Tel. +33 (0)1 44 08 01 85       Fax. +33 (0)1 53 14 59 22

Message #8 received at 13103 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Didier Verna <didier <at> didierverna.net>
Cc: 13103 <at> debbugs.gnu.org
Subject: Re: bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU
Date: Thu, 06 Dec 2012 12:38:50 -0500

> ago. FWIW, this doesn't happen if I compile --with-x --without-ns (the
> rest being identical). on the same machine. This doesn't happen either
> with a 24.2 tarball compiled with either configuration.

Can you also try with the 24.3 pretest (i.e. 2.4.2.90 or from the
`emacs-24' branch)?


        Stefan

Message #11 received at 13103 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Didier Verna <didier <at> didierverna.net>
Cc: 13103 <at> debbugs.gnu.org
Subject: Re: bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU
Date: Thu, 06 Dec 2012 20:08:29 +0200

> From: Didier Verna <didier <at> didierverna.net>
> Date: Thu, 06 Dec 2012 14:41:03 +0100
> 
> the Emacs trunk eats 100% CPU on one of my cores at startup, when
> compiled --with-ns.

When this happens, please attach a debugger to Emacs and show us where
it loops.  There's some guidance in etc/DEBUG regarding this; search
for "Emacs fails to respond".

Thanks.

Message #14 received at 13103 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Didier Verna <didier <at> didierverna.net>
Cc: 13103 <at> debbugs.gnu.org
Subject: Re: bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU 
Date: Thu, 6 Dec 2012 19:29:02 +0100

Hello.

Did you start Emacs with -Q?
What gcc are you using?  AFAIK --enable-link-time-optimization does not do anything with Apple supplied GCC.

	Jan D.

6 dec 2012 kl. 14:41 skrev Didier Verna <didier <at> didierverna.net>:

> 
>  Hello,
> 
> the Emacs trunk eats 100% CPU on one of my cores at startup, when
> compiled --with-ns. In fact, I discovered that this is the case until I
> do something network'ish, like start Gnus or the emacs server. Then, the
> CPU usage goes back to "normal".
> 
> This reminds me of a gethostname problem we had in XEmacs ages
> ago. FWIW, this doesn't happen if I compile --with-x --without-ns (the
> rest being identical). on the same machine. This doesn't happen either
> with a 24.2 tarball compiled with either configuration.
> 
> 
> In GNU Emacs 24.3.50.1 (x86_64-apple-darwin10.8.0, NS apple-appkit-1038.36)
> of 2012-12-03 on scofield.lrde.epita.fr
> Bzr revision: 111073 dmantipov <at> yandex.ru-20121203080602-hwv4fug7bvt2red7
> Windowing system distributor `Apple', version 10.3.1038
> Configured using:
> `configure '--with-ns' '--enable-link-time-optimization'
> '--x-includes=/opt/X11/include' '--x-libraries=/opt/X11/lib''
> 
> Important settings:
>  locale-coding-system: nil
>  default enable-multibyte-characters: t
> 
> Major mode: Group
> 
> Minor modes in effect:
>  gnus-topic-mode: t
>  gnus-undo-mode: t
>  show-paren-mode: t
>  global-whitespace-mode: t
>  tooltip-mode: t
>  mouse-wheel-mode: t
>  menu-bar-mode: t
>  file-name-shadow-mode: t
>  global-font-lock-mode: t
>  blink-cursor-mode: t
>  auto-composition-mode: t
>  auto-encryption-mode: t
>  auto-compression-mode: t
>  buffer-read-only: t
>  size-indication-mode: t
>  column-number-mode: t
>  line-number-mode: t
>  transient-mark-mode: t
> 
> Recent input:
> o u r SPC t e ' l e ' c h a r g e r SPC l e s SPC p 
> a r o l e s , SPC e t SPC l a SPC b a n d e SPC i n 
> s t r u m e n t a l e SPC <backspace> , SPC h i s t 
> o i r e SPC d e SPC v o u s SPC e n t r a i ^ n e r 
> SPC u n SPC p e u . . . <return> <return> s-v <return> 
> s-v <return> <return> F a i t e s - m o i SPC s i g 
> n e SPC s i SPC v o u s SPC a v e z SPC d e s SPC p 
> r o b l e ` m e s SPC p o u r SPC o u v r i r SPC d 
> <backspace> c e s SPC f i c h i e r s . <return> <up> 
> <return> <down> C-d <help-echo> <return> <return> <up> 
> T r o i s , SPC q u a t <backspace> a a a a t r e SPC 
> ! C-a <return> <down> <down> <down> <down> <down> C-k 
> C-k C-k C-k C-k C-k C-k C-x i . g n u s <tab> s i <tab> 
> d e f <tab> <return> <down> <down> C-SPC <down> <down> 
> <down> <down> <down> C-w <wheel-up> <double-wheel-up> 
> <triple-wheel-up> <triple-wheel-up> <wheel-down> <double-wheel-down> 
> <triple-wheel-down> <wheel-up> <double-wheel-up> <triple-wheel-up> 
> <triple-wheel-up> C-c C-c x q l s g n SPC SPC q l s 
> g g n SPC q SPC n q SPC q SPC d d q l s M-x r e p o 
> r t - e m a c s <tab> <return>
> 
> Recent messages:
> name mismatch: "XEmacs Beta Testers" changed to "XEmacs Beta Discussion"
> Exiting summary buffer and applying spam rules
> nnimap read 0k from imap.gmail.com
> Exiting summary buffer and applying spam rules [2 times]
> Saving file /Users/didier/.newsrc...
> Wrote /Users/didier/.newsrc
> Saving /Users/didier/.newsrc.eld...
> Saving file /Users/didier/.newsrc.eld...
> Wrote /Users/didier/.newsrc.eld
> Saving /Users/didier/.newsrc.eld...done
> 
> Load-path shadows:
> None found.
> 
> Features:
> (shadow warnings emacsbug crm thingatpt cus-edit dired jka-compr
> find-func debug mailalias smtpmail sendmail ispell pp gnus-draft rfc1345
> quail help-mode footnote misearch multi-isearch compface gnus-fun
> bbdb-gui bbdb-hooks smiley ansi-color gnus-cite flow-fill gnus-dup
> mule-util sort shr-color color shr browse-url gnus-async gnus-bcklg
> vc-git qp gnus-ml gnus-topic mm-archive url-http url-gw url-cache
> url-auth url-handlers nnrss xml mm-url url url-proxy url-privacy
> url-expand url-methods url-history url-cookie url-domsuf url-util
> url-parse url-vars nndoc nndraft nnmh utf-7 nnimap utf7 gnutls nnml
> parse-time bbdb-gnus bbdb-snarf mail-extr epa-file epa derived epg netrc
> network-stream auth-source eieio byte-opt bytecomp byte-compile cconv
> starttls tls gnus-agent gnus-srvr gnus-score score-mode nnvirtual nntp
> gnus-cache spam spam-stat bbdb-com advice help-fns message-utils gnus-uu
> yenc gnus-msg gnus-diary gnus-art mm-uu mml2015 epg-config mm-view
> mml-smime smime password-cache dig mailcap nndiary gnus-sum gnus-group
> gnus-undo nnmail mail-source nnoo gnus-start gnus-spec gnus-int
> gnus-range bbdb-autoloads bbdb timezone message format-spec rfc822 mml
> mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
> ietf-drums mailabbrev gmm-utils mailheader gnus-win server rcfiles
> slime-autoloads rcfiles-autoloads auctex-autoloads tex-site info
> easymenu nlinum-autoloads package saveplace disp-table milonga-theme
> cl-macs gv paren gnus gnus-ems nnheader gnus-util mail-utils mm-util
> mail-prsvr wid-edit whitespace cus-start cus-load cl nadvice cl-lib
> time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel ns-win
> tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
> lisp-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 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 ns multi-tty
> emacs)
> 
> -- 
> Resistance is futile. You will be jazzimilated.
> 
> Scientific site:   http://www.lrde.epita.fr/~didier
> Music (Jazz) site: http://www.didierverna.com
> 
> EPITA/LRDE, 14-16 rue Voltaire, 94276 Le Kremlin-Bicêtre, France
> Tel. +33 (0)1 44 08 01 85       Fax. +33 (0)1 53 14 59 22
> 
> 

Message #17 received at 13103 <at> debbugs.gnu.org (full text, mbox):

From: Didier Verna <didier <at> didierverna.net>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 13103 <at> debbugs.gnu.org
Subject: Re: bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU
Date: Thu, 06 Dec 2012 20:57:53 +0100

Jan Djärv <jan.h.d <at> swipnet.se> wrote:

> Did you start Emacs with -Q?

  To be precise: 'open -n /Applications/Emacs.app --args -Q'

> What gcc are you using?

configure:4762: checking for gcc
configure:4778: found /usr/bin/gcc
configure:4789: result: gcc
configure:5018: checking for C compiler version
configure:5027: gcc --version >&5
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)

-- 
ELS 2013, June 3/4, Madrid, Spain:  http://els2013.european-lisp-symposium.org

Scientific site:   http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com

Message #20 received at 13103 <at> debbugs.gnu.org (full text, mbox):

From: Didier Verna <didier <at> didierverna.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 13103 <at> debbugs.gnu.org
Subject: Re: bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU
Date: Thu, 06 Dec 2012 21:03:06 +0100

Eli Zaretskii <eliz <at> gnu.org> wrote:

> When this happens, please attach a debugger to Emacs and show us where
> it loops.  There's some guidance in etc/DEBUG regarding this; search
> for "Emacs fails to respond".

  Problem is, the "loop" doesn't happen when I open Emacs directly with

/Applications/Emacs.app/Contents/MacOS/Emacs -Q

It only happens when I open the application the Mac way ('open',
QuickSilver, double-click etc.). How does one attach a debugger to an app?

-- 
ELS 2013, June 3/4, Madrid, Spain:  http://els2013.european-lisp-symposium.org

Scientific site:   http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com

Message #23 received at 13103 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Didier Verna <didier <at> didierverna.net>
Cc: 13103 <at> debbugs.gnu.org
Subject: Re: bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU
Date: Thu, 06 Dec 2012 22:20:57 +0200

> From:   Didier Verna <didier <at> didierverna.net>
> Cc: 13103 <at> debbugs.gnu.org
> Date: Thu, 06 Dec 2012 21:03:06 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> > When this happens, please attach a debugger to Emacs and show us where
> > it loops.  There's some guidance in etc/DEBUG regarding this; search
> > for "Emacs fails to respond".
> 
>   Problem is, the "loop" doesn't happen when I open Emacs directly with
> 
> /Applications/Emacs.app/Contents/MacOS/Emacs -Q
> 
> It only happens when I open the application the Mac way ('open',
> QuickSilver, double-click etc.). How does one attach a debugger to an app?

"gdb -p PID", where PID is the process ID.

(I assume you can use GDB on MacOS.)

Message #26 received at 13103 <at> debbugs.gnu.org (full text, mbox):

From: Didier Verna <didier <at> didierverna.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 13103 <at> debbugs.gnu.org
Subject: Re: bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU
Date: Thu, 06 Dec 2012 22:24:11 +0100

Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Didier Verna <didier <at> didierverna.net>
>> Date: Thu, 06 Dec 2012 14:41:03 +0100
>> 
>> the Emacs trunk eats 100% CPU on one of my cores at startup, when
>> compiled --with-ns.
>
> When this happens, please attach a debugger to Emacs and show us where
> it loops.  There's some guidance in etc/DEBUG regarding this; search
> for "Emacs fails to respond".

  Here's the result of gdb's 'where' when I kill -TSTP the Emacs.app
  process, after attaching GDB to it. Not sure that's very useful. Also,
  I should point out that Emacs itself does NOT hang or become
  unresponsive. It works like a charm. It's just that the CPU usage goes
  way up.



#0  0x00007fff838dfd7a in mach_msg_trap ()
#1  0x00007fff838e0444 in mach_msg ()
#2  0x00007fff89580902 in __CFRunLoopRun ()
#3  0x00007fff8957fd8f in CFRunLoopRunSpecific ()
#4  0x00007fff809507ee in RunCurrentEventLoopInMode ()
#5  0x00007fff809505f3 in ReceiveNextEventCommon ()
#6  0x00007fff809504ac in BlockUntilNextEventMatchingListInMode ()
#7  0x00007fff83ae4eb2 in _DPSNextEvent ()
#8  0x00007fff83ae4801 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#9  0x00007fff83aaa68f in -[NSApplication run] ()
#10 0x0000000100191d95 in ns_select (nfds=1, readfds=0x7fff5fbfa290, writefds=0x7fff5fbfa210, exceptfds=<value temporarily unavailable, due to optimizations>, timeout=0x7fff5fbfa330, sigmask=<value temporarily unavailable, due to optimizations>) at /usr/local/src/emacs/trunk/src/nsterm.m:3537
#11 0x000000010015dfad in wait_reading_process_output (time_limit=<value temporarily unavailable, due to optimizations>, nsecs=0, read_kbd                                                                                                      #12 0x00000001000ac645 in read_char (commandflag=1, nmaps=2, maps=0x7fff5fbfa790, prev_event=<value temporarily unavailable, due to optimizations>, used_mouse_menu=0x7fff5fbfa9b7, end_time=0x0) at /usr/local/src/emacs/trunk/src/keyboard.c:3784
#13 0x00000001000aed5d in read_key_sequence (keybuf=0x7fff5fbfaa70, bufsize=30, prompt=4320145466, dont_downcase_last                                           #14 0x00000001000b0e3a in command_loop_1 () at /usr/local/src/emacs/trunk/src/keyboard.c:1448
#15 0x0000000100117ea5 in internal_condition_case (bfun=0x1000b0be0 <command_loop_1>, handlers=4320211706, hfun=0x1000a91a0 <cmd_error>) at /usr/local/src/emacs/trunk/src/eval.c:1192
#16 0x00000001000a6e67 in command_loop_2 (ignore=<value temporarily unavailable, due to optimizations>) at /usr/local/src/emacs/trunk/src/keyboard.c:1163
#17 0x0000000100117fae in internal_catch (tag=<value temporarily unavailable, due to optimizations>, func=0x1000a6e30 <command_loop_2>, arg=4320145466) at /usr/local/src/emacs/trunk/src/eval.c:963
#18 0x00000001000a752c in recursive_edit_1 () at /usr/local/src/emacs/trunk/src/keyboard.c:1142
#19 0x00000001000a94d3 in Frecursive_edit () at /usr/local/src/emacs/trunk/src/keyboard.c:838
#20 0x000000010009f77e in main (argc=2, argv=0x7fff5fbfb038) at /usr/local/src/emacs/trunk/src/emacs.c:1560

-- 
ELS 2013, June 3/4, Madrid, Spain:  http://els2013.european-lisp-symposium.org

Scientific site:   http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com

Message #29 received at 13103 <at> debbugs.gnu.org (full text, mbox):

From: Didier Verna <didier <at> didierverna.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 13103 <at> debbugs.gnu.org
Subject: Re: bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU
Date: Thu, 06 Dec 2012 22:59:07 +0100

Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:

> Can you also try with the 24.3 pretest (i.e. 2.4.2.90 or from the
> `emacs-24' branch)?

  I can now confirm that this happens on the emacs-24 branch as well.

-- 
ELS 2013, June 3/4, Madrid, Spain:  http://els2013.european-lisp-symposium.org

Scientific site:   http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com

Message #32 received at 13103 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Didier Verna <didier <at> didierverna.net>
Cc: 13103 <at> debbugs.gnu.org
Subject: Re: bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU
Date: Thu, 06 Dec 2012 20:50:39 -0500

severity 13103 important
thanks

>> Can you also try with the 24.3 pretest (i.e. 2.4.2.90 or from the
>> `emacs-24' branch)?
> I can now confirm that this happens on the emacs-24 branch as well.

Thanks, so it's a regression that we should fix before the 24.3 release.


        Stefan

Message #37 received at 13103 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Didier Verna <didier <at> didierverna.net>
Cc: 13103 <at> debbugs.gnu.org
Subject: Re: bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU
Date: Fri, 07 Dec 2012 08:21:09 +0200

> From:     Didier Verna <didier <at> didierverna.net>
> Cc: 13103 <at> debbugs.gnu.org
> Date: Thu, 06 Dec 2012 22:24:11 +0100
> 
>   Here's the result of gdb's 'where' when I kill -TSTP the Emacs.app
>   process, after attaching GDB to it. Not sure that's very useful. Also,
>   I should point out that Emacs itself does NOT hang or become
>   unresponsive. It works like a charm. It's just that the CPU usage goes
>   way up.
> 
> 
> 
> #0  0x00007fff838dfd7a in mach_msg_trap ()
> #1  0x00007fff838e0444 in mach_msg ()
> #2  0x00007fff89580902 in __CFRunLoopRun ()
> #3  0x00007fff8957fd8f in CFRunLoopRunSpecific ()
> #4  0x00007fff809507ee in RunCurrentEventLoopInMode ()
> #5  0x00007fff809505f3 in ReceiveNextEventCommon ()
> #6  0x00007fff809504ac in BlockUntilNextEventMatchingListInMode ()
> #7  0x00007fff83ae4eb2 in _DPSNextEvent ()
> #8  0x00007fff83ae4801 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
> #9  0x00007fff83aaa68f in -[NSApplication run] ()
> #10 0x0000000100191d95 in ns_select (nfds=1, readfds=0x7fff5fbfa290, writefds=0x7fff5fbfa210, exceptfds=<value temporarily unavailable, due to optimizations>, timeout=0x7fff5fbfa330, sigmask=<value temporarily unavailable, due to optimizations>) at /usr/local/src/emacs/trunk/src/nsterm.m:3537
> #11 0x000000010015dfad in wait_reading_process_output
> #(time_limit=<value temporarily unavailable, due to optimizations>,
> #nsecs=0, read_kbd                  

Next step is to see which file descriptor is being watched here.
(There's only one because nfds = 1.)

Also, I suggest to do this experiment several times, to make sure that
this is indeed related to the call to ns_select.

Message #40 received at 13103 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 13103 <at> debbugs.gnu.org, Didier Verna <didier <at> didierverna.net>
Subject: Re: bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU 
Date: Sat, 8 Dec 2012 10:17:45 +0100

Hello.

7 dec 2012 kl. 07:21 skrev Eli Zaretskii <eliz <at> gnu.org>:

>> From:     Didier Verna <didier <at> didierverna.net>
>> Cc: 13103 <at> debbugs.gnu.org
>> Date: Thu, 06 Dec 2012 22:24:11 +0100
>> 
>>  Here's the result of gdb's 'where' when I kill -TSTP the Emacs.app
>>  process, after attaching GDB to it. Not sure that's very useful. Also,
>>  I should point out that Emacs itself does NOT hang or become
>>  unresponsive. It works like a charm. It's just that the CPU usage goes
>>  way up.
>> 
>> 
>> 
>> #0  0x00007fff838dfd7a in mach_msg_trap ()
>> #1  0x00007fff838e0444 in mach_msg ()
>> #2  0x00007fff89580902 in __CFRunLoopRun ()
>> #3  0x00007fff8957fd8f in CFRunLoopRunSpecific ()
>> #4  0x00007fff809507ee in RunCurrentEventLoopInMode ()
>> #5  0x00007fff809505f3 in ReceiveNextEventCommon ()
>> #6  0x00007fff809504ac in BlockUntilNextEventMatchingListInMode ()
>> #7  0x00007fff83ae4eb2 in _DPSNextEvent ()
>> #8  0x00007fff83ae4801 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
>> #9  0x00007fff83aaa68f in -[NSApplication run] ()
>> #10 0x0000000100191d95 in ns_select (nfds=1, readfds=0x7fff5fbfa290, writefds=0x7fff5fbfa210, exceptfds=<value temporarily unavailable, due to optimizations>, timeout=0x7fff5fbfa330, sigmask=<value temporarily unavailable, due to optimizations>) at /usr/local/src/emacs/trunk/src/nsterm.m:3537
>> #11 0x000000010015dfad in wait_reading_process_output
>> #(time_limit=<value temporarily unavailable, due to optimizations>,
>> #nsecs=0, read_kbd                  
> 
> Next step is to see which file descriptor is being watched here.
> (There's only one because nfds = 1.)
> 
> Also, I suggest to do this experiment several times, to make sure that
> this is indeed related to the call to ns_select.

If Emacs is started with -Q there shouldn't be any fds.  So either something is done after starting Emacs or some plugin/extension is doing something.

Print out the readfds, and figure out what the fd is.  Then use lsof to see what that fd really is.

	Jan D.

Message #45 received at 13103-done <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 13103-done <at> debbugs.gnu.org, Didier Verna <didier <at> didierverna.net>
Subject: Re: bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU 
Date: Sat, 8 Dec 2012 20:04:02 +0100

Hello.

8 dec 2012 kl. 10:17 skrev Jan Djärv <jan.h.d <at> swipnet.se>:

> 
> If Emacs is started with -Q there shouldn't be any fds.  So either something is done after starting Emacs or some plugin/extension is doing something.

Actually, this is a red herring.  nfds is 1 when there are no fd:s to listen to (why I don't know).
I have checked in a fix in the emacs-24 branch, please try it.

Thanks,

	Jan D.

Message #48 received at 13103-done <at> debbugs.gnu.org (full text, mbox):

From: Didier Verna <didier <at> didierverna.net>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 13103-done <at> debbugs.gnu.org,
	Didier Verna <didier <at> didierverna.net>
Subject: Re: bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU
Date: Sun, 09 Dec 2012 21:36:47 +0100

Jan Djärv <jan.h.d <at> swipnet.se> wrote:

> Actually, this is a red herring.  nfds is 1 when there are no fd:s to
> listen to (why I don't know).  I have checked in a fix in the emacs-24
> branch, please try it.

  I Just did. This indeed seems to have fixed the problem.

-- 
ELS 2013, June 3/4, Madrid, Spain:  http://els2013.european-lisp-symposium.org

Scientific site:   http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com

Message #51 received at 13103-done <at> debbugs.gnu.org (full text, mbox):

From: Didier Verna <didier <at> didierverna.net>
To: Didier Verna <didier <at> didierverna.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>,
	Jan Djärv <jan.h.d <at> swipnet.se>, 13103-done <at> debbugs.gnu.org
Subject: Re: bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU
Date: Sun, 30 Dec 2012 12:04:59 +0100

I wrote:

> Jan Djärv <jan.h.d <at> swipnet.se> wrote:
>
>> Actually, this is a red herring.  nfds is 1 when there are no fd:s to
>> listen to (why I don't know).  I have checked in a fix in the emacs-24
>> branch, please try it.
>
>   I Just did. This indeed seems to have fixed the problem.

  Hello,

I'm not seing this fix propagated to the trunk. Is that normal ?

-- 
ELS 2013, June 3/4, Madrid, Spain:  http://els2013.european-lisp-symposium.org

Scientific site:   http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com

Message #54 received at 13103 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Didier Verna <didier <at> didierverna.net>
Cc: 13103 <at> debbugs.gnu.org
Subject: Re: bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU
Date: Sun, 30 Dec 2012 12:58:17 -0500

Didier Verna wrote:

> I'm not seing this fix propagated to the trunk.

It's been there since Dec 10.

http://lists.gnu.org/archive/html/emacs-diffs/2012-12/msg00159.html

Message #57 received at 13103 <at> debbugs.gnu.org (full text, mbox):

From: Didier Verna <didier <at> didierverna.net>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 13103 <at> debbugs.gnu.org
Subject: Re: bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU
Date: Mon, 31 Dec 2012 11:16:04 +0100

Glenn Morris <rgm <at> gnu.org> wrote:

> Didier Verna wrote:
>
>> I'm not seing this fix propagated to the trunk.
>
> It's been there since Dec 10.
>
> http://lists.gnu.org/archive/html/emacs-diffs/2012-12/msg00159.html

  Okay, sorry for the noise. I was fooled by the way bzr works (I'm not
  very familiar with it). I was expecting to see the individual commit
  in the log.

-- 
ELS 2013, June 3/4, Madrid, Spain:  http://els2013.european-lisp-symposium.org

Scientific site:   http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com

Message #60 received at 13103 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Didier Verna <didier <at> didierverna.net>
Cc: rgm <at> gnu.org, 13103 <at> debbugs.gnu.org
Subject: Re: bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU
Date: Mon, 31 Dec 2012 19:17:39 +0200

> From: Didier Verna <didier <at> didierverna.net>
> Date: Mon, 31 Dec 2012 11:16:04 +0100
> Cc: 13103 <at> debbugs.gnu.org
> 
>  I was fooled by the way bzr works (I'm not very familiar with
>   it). I was expecting to see the individual commit in the log.

If you mean you expected to see the revisions merged from a branch,
then using the --include-merged will do that.  (And if that switch
makes bzr unbearably slow for you, install the history_db plugin,
which will recover the original speed even when you use that switch.)

Message #63 received at 13103 <at> debbugs.gnu.org (full text, mbox):

From: Didier Verna <didier <at> didierverna.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rgm <at> gnu.org, 13103 <at> debbugs.gnu.org, Didier Verna <didier <at> didierverna.net>
Subject: Re: bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU
Date: Wed, 02 Jan 2013 15:01:13 +0100

Eli Zaretskii <eliz <at> gnu.org> wrote:

> If you mean you expected to see the revisions merged from a branch,
> then using the --include-merged will do that.  (And if that switch
> makes bzr unbearably slow for you, install the history_db plugin,
> which will recover the original speed even when you use that switch.)

  Very useful, thanks!

-- 
Resistance is futile. You will be jazzimilated.

Scientific site:   http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.