bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU

bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU

[Didier Verna]

  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@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

bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU

[Stefan Monnier]

> 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

bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU

[Eli Zaretskii]

> From: Didier Verna <didier@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.

bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU

[Jan Djärv]

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@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@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
> 
> 

bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU

[Didier Verna]

Jan Djärv <jan.h.d@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

bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU

[Didier Verna]

Eli Zaretskii <eliz@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

bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU

[Eli Zaretskii]

> From:   Didier Verna <didier@didierverna.net>
> Cc: 13103@debbugs.gnu.org
> Date: Thu, 06 Dec 2012 21:03:06 +0100
> 
> Eli Zaretskii <eliz@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.)

bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU

[Didier Verna]

Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Didier Verna <didier@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

bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU

[Didier Verna]

Stefan Monnier <monnier@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

bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU

[Stefan Monnier]

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

bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU

[Eli Zaretskii]

> From:     Didier Verna <didier@didierverna.net>
> Cc: 13103@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.

bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU

[Jan Djärv]

Hello.

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

>> From:     Didier Verna <didier@didierverna.net>
>> Cc: 13103@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.

bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU

[Jan Djärv]

Hello.

8 dec 2012 kl. 10:17 skrev Jan Djärv <jan.h.d@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.

bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU

[Didier Verna]

Jan Djärv <jan.h.d@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

bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU

[Didier Verna]

I wrote:

> Jan Djärv <jan.h.d@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

bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU

[Glenn Morris]

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

bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU

[Didier Verna]

Glenn Morris <rgm@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

bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU

[Eli Zaretskii]

> From: Didier Verna <didier@didierverna.net>
> Date: Mon, 31 Dec 2012 11:16:04 +0100
> Cc: 13103@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.)

bug#13103: 24.3.50; Trunk --with-ns eats 100% CPU

[Didier Verna]

Eli Zaretskii <eliz@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