GNU bug report logs - #24091
24.5; High CPU usage at startup while hidden

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 24091 in the body.
You can then email your comments to 24091 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: aiken <acairncross <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.5; High CPU usage at startup while hidden
Date: Thu, 28 Jul 2016 00:11:53 +0100

I am using the i3 window manager. When I launch emacs (via dmenu) while
in a workspace, call it workspace A, and switch to workspace B before
the emacs window appears, then eventually it loads up in A, but during
this time, emacs' CPU usage is very high. It remains high until I switch
back to A, at which point its CPU usage becomes normal. I've also tried
launching emacs with my init.el disabled (commented out) and get the
same result.



In GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
 of 2016-04-17 on lgw01-04, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.11803000
System Description:	Ubuntu 16.04.1 LTS

Configured using:
 `configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-lisp:/usr/share/emacs/site-lisp
 --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
 --libexecdir=/usr/lib --localstatedir=/var/lib
 --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-lisp:/usr/share/emacs/site-lisp
 --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars
 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat
 -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
 -D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro''

Important settings:
  value of $LANG: en_GB.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Message

Minor modes in effect:
  mml-mode: t
  global-linum-mode: t
  linum-mode: t
  show-paren-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
  auto-fill-function: message-do-auto-fill
  transient-mark-mode: t
  abbrev-mode: t

Recent messages:
Sending...
message-send: No methods specified to send by
Mark set
Sending...
message-send: No methods specified to send by
Mark set
Sending...
message-send: No methods specified to send by
Mark set
Mark deactivated

Load-path shadows:
/home/aiken/.emacs.d/elpa/helm-20160715.2117/helm-multi-match hides
/home/aiken/.emacs.d/elpa/helm-core-20160716.3/helm-multi-match
/usr/share/emacs/24.5/site-lisp/debian-startup hides
/usr/share/emacs/site-lisp/debian-startup

Features:
(pp shadow sort gnus-util mail-extr emacsbug message format-spec rfc822
mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
help-fns mail-prsvr mail-utils help-mode ido tango-theme linum edmacro
kmacro cl-loaddefs cl-lib paren cus-start cus-load easymenu package
epg-config 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 148256 14891)
 (symbols 48 23209 0)
 (miscs 40 214 233)
 (strings 32 30777 8686)
 (string-bytes 1 780663)
 (vectors 16 14596)
 (vector-slots 8 441793 11029)
 (floats 8 87 340)
 (intervals 56 789 779)
 (buffers 960 14)
 (heap 1024 45744 1545))

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: aiken <acairncross <at> gmail.com>
Cc: 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Wed, 27 Jul 2016 19:32:56 -0400

On Wed, Jul 27, 2016 at 7:11 PM, aiken <acairncross <at> gmail.com> wrote:
> I am using the i3 window manager. When I launch emacs (via dmenu) while
> in a workspace, call it workspace A, and switch to workspace B before
> the emacs window appears, then eventually it loads up in A,

For me, the emacs window appears in workspace B. Is there some setting
you need to make it appear in the starting workspace?

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

From: Clément Pit--Claudel <clement.pit <at> gmail.com>
To: aiken <acairncross <at> gmail.com>, 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Wed, 27 Jul 2016 22:16:47 -0400

[Message part 1 (text/plain, inline)]

Thanks for the bug report. Just to confirm that this isn't a configuration issue, can you try starting Emacs as `emacs -Q` and reproducing the issue?

If the problem persists in `emacs -Q`, maybe a trace generated by running M-x profiler-start before changing workspaces and M-x profiler-report after returning to the first workspace would help? You can save the profile with profiler-report-save-profile.

Cheers,
Clément.

On 2016-07-27 19:11, aiken wrote:
> I am using the i3 window manager. When I launch emacs (via dmenu) while
> in a workspace, call it workspace A, and switch to workspace B before
> the emacs window appears, then eventually it loads up in A, but during
> this time, emacs' CPU usage is very high. It remains high until I switch
> back to A, at which point its CPU usage becomes normal. I've also tried
> launching emacs with my init.el disabled (commented out) and get the
> same result.
> 
> 
> 
> In GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
>  of 2016-04-17 on lgw01-04, modified by Debian
> Windowing system distributor `The X.Org Foundation', version 11.0.11803000
> System Description:	Ubuntu 16.04.1 LTS
> 
> Configured using:
>  `configure --build x86_64-linux-gnu --prefix=/usr
>  --sharedstatedir=/var/lib --libexecdir=/usr/lib
>  --localstatedir=/var/lib --infodir=/usr/share/info
>  --mandir=/usr/share/man --with-pop=yes
>  --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-lisp:/usr/share/emacs/site-lisp
>  --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
>  --libexecdir=/usr/lib --localstatedir=/var/lib
>  --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes
>  --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-lisp:/usr/share/emacs/site-lisp
>  --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars
>  'CFLAGS=-g -O2 -fstack-protector-strong -Wformat
>  -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
>  -D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro''
> 
> Important settings:
>   value of $LANG: en_GB.UTF-8
>   locale-coding-system: utf-8-unix
> 
> Major mode: Message
> 
> Minor modes in effect:
>   mml-mode: t
>   global-linum-mode: t
>   linum-mode: t
>   show-paren-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
>   auto-fill-function: message-do-auto-fill
>   transient-mark-mode: t
>   abbrev-mode: t
> 
> Recent messages:
> Sending...
> message-send: No methods specified to send by
> Mark set
> Sending...
> message-send: No methods specified to send by
> Mark set
> Sending...
> message-send: No methods specified to send by
> Mark set
> Mark deactivated
> 
> Load-path shadows:
> /home/aiken/.emacs.d/elpa/helm-20160715.2117/helm-multi-match hides
> /home/aiken/.emacs.d/elpa/helm-core-20160716.3/helm-multi-match
> /usr/share/emacs/24.5/site-lisp/debian-startup hides
> /usr/share/emacs/site-lisp/debian-startup
> 
> Features:
> (pp shadow sort gnus-util mail-extr emacsbug message format-spec rfc822
> mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
> gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
> help-fns mail-prsvr mail-utils help-mode ido tango-theme linum edmacro
> kmacro cl-loaddefs cl-lib paren cus-start cus-load easymenu package
> epg-config 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 148256 14891)
>  (symbols 48 23209 0)
>  (miscs 40 214 233)
>  (strings 32 30777 8686)
>  (string-bytes 1 780663)
>  (vectors 16 14596)
>  (vector-slots 8 441793 11029)
>  (floats 8 87 340)
>  (intervals 56 789 779)
>  (buffers 960 14)
>  (heap 1024 45744 1545))
> 
> 
> 
> 

[signature.asc (application/pgp-signature, attachment)]

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

From: aiken <acairncross <at> gmail.com>
To: npostavs <at> users.sourceforge.net, clement.pit <at> gmail.com,
 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Thu, 28 Jul 2016 18:43:38 +0100

Noam: I think my settings are fairly standard, but another way to
reproduce the effect of Emacs launching in a workspace that you're not
currently in (which seems to be the main issue) is to add something like
"assign [class="Emacs24"] 9" to your i3 config. (I've tried this and it
does reproduce the high CPU usage.)

Clément: I still get the problem with `emacs -Q`. Some clarification
about the problem: the high CPU usage starts while Emacs is launching on
some other workspace, and stops as soon as I go to that workspace. I
notice that, when I go to the Emacs workspace and see the Emacs window,
Emacs hasn't actually loaded up fully (e.g. it hasn't loaded my
init.el), and it only finishes a lot of its startup once I'm on that
workspace. Anyway, since the problem stops as soon as I look at Emacs,
the only way I know of running profiler-report for this purpose is by
putting it in a command line option: `emacs -Q --eval "(profiler-start
'cpu)"`. So I've done this (see below for the report), but I'm pretty
sure the profiler-start is only getting evaluated after I've moved to
the Emacs workspace, i.e. after the problem has stopped.


[profiler-profile "24.3" cpu #s(hash-table size 65 test equal
rehash-size 1.5 rehash-threshold 0.8 data ([nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil] 61 [and or and redisplay_internal\
\(C\ function\) nil nil nil nil nil nil nil nil nil nil nil nil] 4
[completing-read-default completing-read read-extended-command byte-code
call-interactively command-execute nil nil nil nil nil nil nil nil nil
nil] 24 [and or and redisplay_internal\ \(C\ function\)
read-from-minibuffer completing-read-default completing-read
read-extended-command byte-code call-interactively command-execute nil
nil nil nil nil] 3 [read-from-minibuffer completing-read-default
completing-read read-extended-command byte-code call-interactively
command-execute nil nil nil nil nil nil nil nil nil] 37
[completion-basic-try-completion "#<compiled 0x4c2287>" "#<compiled
0x4c267f>" funcall completion--some completion--nth-completion
completion-try-completion completion--do-completion
completion--in-region-1 "#<compiled 0x247e21>" apply "#<compiled
0x4c1a7f>" completion--in-region completion-in-region
minibuffer-complete call-interactively] 5
[completion-pcm--all-completions "#<compiled 0x4c3299>" funcall
completion-pcm--find-all-completions completion-pcm-try-completion
"#<compiled 0x4c2287>" "#<compiled 0x4c2a8f>" funcall completion--some
completion--nth-completion completion-try-completion
completion--do-completion completion--in-region-1 "#<compiled 0x247e21>"
apply "#<compiled 0x4c1a7f>"] 4 [completion-emacs22-try-completion
"#<compiled 0x4c2287>" "#<compiled 0x4c3e97>" funcall completion--some
completion--nth-completion completion-try-completion
completion--do-completion completion--in-region-1 "#<compiled 0x247e21>"
apply "#<compiled 0x4c1a7f>" completion--in-region completion-in-region
minibuffer-complete call-interactively] 4 [sit-for minibuffer-message
completion--message completion--do-completion completion--in-region-1
"#<compiled 0x247e21>" apply "#<compiled 0x4c1a7f>"
completion--in-region completion-in-region minibuffer-complete
call-interactively command-execute read-from-minibuffer
completing-read-default completing-read] 2 [delete-backward-char
call-interactively command-execute read-from-minibuffer
completing-read-default completing-read read-extended-command byte-code
call-interactively command-execute nil nil nil nil nil nil] 1
[profiler-cpu-profile profiler-report-cpu profiler-report
call-interactively command-execute execute-extended-command
call-interactively command-execute nil nil nil nil nil nil nil nil] 14
[Automatic\ GC] 2)) (22426 16956 108810 96000) nil]

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

From: Clément Pit--Claudel <clement.pit <at> gmail.com>
To: aiken <acairncross <at> gmail.com>, npostavs <at> users.sourceforge.net,
 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Thu, 28 Jul 2016 15:37:20 -0400

[Message part 1 (text/plain, inline)]

On 2016-07-28 13:43, aiken wrote:
> Clément: I still get the problem with `emacs -Q`. Some clarification
> about the problem: the high CPU usage starts while Emacs is launching on
> some other workspace, and stops as soon as I go to that workspace. I
> notice that, when I go to the Emacs workspace and see the Emacs window,
> Emacs hasn't actually loaded up fully (e.g. it hasn't loaded my
> init.el), and it only finishes a lot of its startup once I'm on that
> workspace. Anyway, since the problem stops as soon as I look at Emacs,
> the only way I know of running profiler-report for this purpose is by
> putting it in a command line option: `emacs -Q --eval "(profiler-start
> 'cpu)"`. So I've done this (see below for the report), but I'm pretty
> sure the profiler-start is only getting evaluated after I've moved to
> the Emacs workspace, i.e. after the problem has stopped.

Interesting, thanks. Indeed, the profile doesn't show much of interest, and does not seem to have run very long.
I'm not very knowledgeable at all about these parts of Emacs, so I hope that an expert can offer more suggestions. I can offer a few suggestions, however:

* You could try enabling C-level profiling, if you're fine with recompiling Emacs; this should capture most of Emacs' activity.
* You could try getting a backtrace while Emacs is busy starting, from the other desktop; either using gdb if it's busy in C-code, or with pkill -SIGUSR2 if it's busy with Lisp code.

Btw, was this profile obtained with Emacs 24.5, or 24.3?

[signature.asc (application/pgp-signature, attachment)]

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

From: aiken <acairncross <at> gmail.com>
To: Clément Pit--Claudel <clement.pit <at> gmail.com>,
 npostavs <at> users.sourceforge.net, 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Thu, 28 Jul 2016 21:21:22 +0100

> Btw, was this profile obtained with Emacs 24.5, or 24.3?

If you're asking because of the "24.3" in the profiler report, I have no
idea why it says that, since the Emacs version is definitely 24.5.

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

From: npostavs <at> users.sourceforge.net
To: aiken <acairncross <at> gmail.com>
Cc: clement.pit <at> gmail.com, 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Thu, 28 Jul 2016 21:45:55 -0400

tags 24091 confirmed
found 24091 25.1-rc1
quit

aiken <acairncross <at> gmail.com> writes:

> Noam: I think my settings are fairly standard, but another way to
> reproduce the effect of Emacs launching in a workspace that you're not
> currently in (which seems to be the main issue) is to add something like
> "assign [class="Emacs24"] 9" to your i3 config. (I've tried this and it
> does reproduce the high CPU usage.)

Thanks, with this I'm able to reproduce also with the latest emacs-25.
I sent SIGSTOP to get a backtrace and found it was in
x_make_frame_visible (src/xterm.c).

Stepping through it with gdb, I saw it's getting stuck in this loop:

    /* Process X events until a MapNotify event has been seen.  */
    while (!FRAME_VISIBLE_P (f))
      {
        /* Force processing of queued events.  */
        x_sync (f);

        /* If on another desktop, the deiconify/map may be ignored and the
           frame never becomes visible.  XMonad does this.
           Prevent an endless loop.  */
        if (FRAME_ICONIFIED_P (f) &&  ++tries > 100)
          break;

       /* This hack is still in use at least for Cygwin.  See
           http://lists.gnu.org/archive/html/emacs-devel/2013-12/msg00351.html.

           Machines that do polling rather than SIGIO have been
           observed to go into a busy-wait here.  So we'll fake an
           alarm signal to let the handler know that there's something
           to be read.  We used to raise a real alarm, but it seems
           that the handler isn't always enabled here.  This is
           probably a bug.  */
        if (input_polling_used ())
          {
            /* It could be confusing if a real alarm arrives while
               processing the fake one.  Turn it off and let the
               handler reset it.  */
            int old_poll_suppress_count = poll_suppress_count;
            poll_suppress_count = 1;
            poll_for_input_1 ();
            poll_suppress_count = old_poll_suppress_count;
          }

        if (XPending (FRAME_X_DISPLAY (f)))
          {
            XEvent xev;
            XNextEvent (FRAME_X_DISPLAY (f), &xev);
            x_dispatch_event (&xev, FRAME_X_DISPLAY (f));
          }
      }


I guess we would like Emacs to hit this case:

        /* If on another desktop, the deiconify/map may be ignored and the
           frame never becomes visible.  XMonad does this.
           Prevent an endless loop.  */
        if (FRAME_ICONIFIED_P (f) &&  ++tries > 100)
          break;

But it seems that FRAME_ICONIFIED_P is returning false, because I see
that tries is never incremented.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: npostavs <at> users.sourceforge.net
Cc: acairncross <at> gmail.com, clement.pit <at> gmail.com, 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Fri, 29 Jul 2016 08:46:22 +0300

> From: npostavs <at> users.sourceforge.net
> Date: Thu, 28 Jul 2016 21:45:55 -0400
> Cc: clement.pit <at> gmail.com, 24091 <at> debbugs.gnu.org
> 
> I guess we would like Emacs to hit this case:
> 
>         /* If on another desktop, the deiconify/map may be ignored and the
>            frame never becomes visible.  XMonad does this.
>            Prevent an endless loop.  */
>         if (FRAME_ICONIFIED_P (f) &&  ++tries > 100)
>           break;
> 
> But it seems that FRAME_ICONIFIED_P is returning false, because I see
> that tries is never incremented.

The question is: what happens if you bypass that loop and let Emacs
proceed with startup?  Does it successfully finish the startup, or
does it error out or crash later on?

If the former, we need to find a way to detect this special situation,
and maybe bypass the loop altogether.  If the latter, we will either
need to find a way to avoid that subsequent crash, or continue
waiting, perhaps with some 'usleep' call in the loop, to avoid hogging
the CPU.

Thanks.

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: acairncross <at> gmail.com, clement.pit <at> gmail.com, 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Sat, 30 Jul 2016 09:54:55 -0400

On Fri, Jul 29, 2016 at 1:46 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: npostavs <at> users.sourceforge.net
>> Date: Thu, 28 Jul 2016 21:45:55 -0400
>> Cc: clement.pit <at> gmail.com, 24091 <at> debbugs.gnu.org
>>
>> I guess we would like Emacs to hit this case:
>>
>>         /* If on another desktop, the deiconify/map may be ignored and the
>>            frame never becomes visible.  XMonad does this.
>>            Prevent an endless loop.  */
>>         if (FRAME_ICONIFIED_P (f) &&  ++tries > 100)
>>           break;
>>
>> But it seems that FRAME_ICONIFIED_P is returning false, because I see
>> that tries is never incremented.
>
> The question is: what happens if you bypass that loop and let Emacs
> proceed with startup?  Does it successfully finish the startup, or
> does it error out or crash later on?

Works fine, no crashes.

>
> If the former, we need to find a way to detect this special situation,
> and maybe bypass the loop altogether.

Hmm, not really sure where to start.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: acairncross <at> gmail.com, clement.pit <at> gmail.com, 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Sat, 30 Jul 2016 18:41:44 +0300

> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
> Date: Sat, 30 Jul 2016 09:54:55 -0400
> Cc: acairncross <at> gmail.com, clement.pit <at> gmail.com, 24091 <at> debbugs.gnu.org
> 
> >> But it seems that FRAME_ICONIFIED_P is returning false, because I see
> >> that tries is never incremented.
> >
> > The question is: what happens if you bypass that loop and let Emacs
> > proceed with startup?  Does it successfully finish the startup, or
> > does it error out or crash later on?
> 
> Works fine, no crashes.
> 
> >
> > If the former, we need to find a way to detect this special situation,
> > and maybe bypass the loop altogether.
> 
> Hmm, not really sure where to start.

I'd start by finding out why FRAME_ICONIFIED_P returns false.

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

From: npostavs <at> users.sourceforge.net
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: acairncross <at> gmail.com, clement.pit <at> gmail.com, 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Sat, 13 Aug 2016 19:57:54 -0400

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

>> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
>> Date: Sat, 30 Jul 2016 09:54:55 -0400
>> Cc: acairncross <at> gmail.com, clement.pit <at> gmail.com, 24091 <at> debbugs.gnu.org
>> 
>> >> But it seems that FRAME_ICONIFIED_P is returning false, because I see
>> >> that tries is never incremented.
>> >
>> > The question is: what happens if you bypass that loop and let Emacs
>> > proceed with startup?  Does it successfully finish the startup, or
>> > does it error out or crash later on?
>> 
>> Works fine, no crashes.
>> 
>> >
>> > If the former, we need to find a way to detect this special situation,
>> > and maybe bypass the loop altogether.
>> 
>> Hmm, not really sure where to start.
>
> I'd start by finding out why FRAME_ICONIFIED_P returns false.

Well, it seems that's because Emacs never receives an UnmapNotify event.
But that doesn't feel like I'm getting any closer to a solution...

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: npostavs <at> users.sourceforge.net
Cc: acairncross <at> gmail.com, clement.pit <at> gmail.com, 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Tue, 16 Aug 2016 05:38:34 +0300

> From: npostavs <at> users.sourceforge.net
> Cc: 24091 <at> debbugs.gnu.org,  acairncross <at> gmail.com,  clement.pit <at> gmail.com
> Date: Sat, 13 Aug 2016 19:57:54 -0400
> 
> >> > The question is: what happens if you bypass that loop and let Emacs
> >> > proceed with startup?  Does it successfully finish the startup, or
> >> > does it error out or crash later on?
> >> 
> >> Works fine, no crashes.
> >> 
> >> >
> >> > If the former, we need to find a way to detect this special situation,
> >> > and maybe bypass the loop altogether.
> >> 
> >> Hmm, not really sure where to start.
> >
> > I'd start by finding out why FRAME_ICONIFIED_P returns false.
> 
> Well, it seems that's because Emacs never receives an UnmapNotify event.
> But that doesn't feel like I'm getting any closer to a solution...

What events does Emacs get in that case?

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Aiken <acairncross <at> gmail.com>,
 Clément Pit--Claudel <clement.pit <at> gmail.com>,
 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Sat, 3 Sep 2016 13:29:39 -0400

On Mon, Aug 15, 2016 at 10:38 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: npostavs <at> users.sourceforge.net
>> Cc: 24091 <at> debbugs.gnu.org,  acairncross <at> gmail.com,  clement.pit <at> gmail.com
>> Date: Sat, 13 Aug 2016 19:57:54 -0400
>>
>> >> > The question is: what happens if you bypass that loop and let Emacs
>> >> > proceed with startup?  Does it successfully finish the startup, or
>> >> > does it error out or crash later on?
>> >>
>> >> Works fine, no crashes.
>> >>
>> >> >
>> >> > If the former, we need to find a way to detect this special situation,
>> >> > and maybe bypass the loop altogether.
>> >>
>> >> Hmm, not really sure where to start.
>> >
>> > I'd start by finding out why FRAME_ICONIFIED_P returns false.
>>
>> Well, it seems that's because Emacs never receives an UnmapNotify event.
>> But that doesn't feel like I'm getting any closer to a solution...
>
> What events does Emacs get in that case?

Emacs is getting PropertyNotify, ConfigureNotify, MapNotify, and
ReparentNotify events.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: acairncross <at> gmail.com, clement.pit <at> gmail.com, 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Sat, 03 Sep 2016 20:45:32 +0300

> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
> Date: Sat, 3 Sep 2016 13:29:39 -0400
> Cc: 24091 <at> debbugs.gnu.org, Aiken <acairncross <at> gmail.com>, 
> 	Clément Pit--Claudel <clement.pit <at> gmail.com>
> 
> >> > I'd start by finding out why FRAME_ICONIFIED_P returns false.
> >>
> >> Well, it seems that's because Emacs never receives an UnmapNotify event.
> >> But that doesn't feel like I'm getting any closer to a solution...
> >
> > What events does Emacs get in that case?
> 
> Emacs is getting PropertyNotify, ConfigureNotify, MapNotify, and
> ReparentNotify events.

Does it work to turn this:

        if (FRAME_ICONIFIED_P (f) &&  ++tries > 100)
          break;

into this:

        if ((FRAME_ICONIFIED_P (f) || FRAME_VISIBLE_P (f)) &&  ++tries > 100)
          break;

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Aiken <acairncross <at> gmail.com>,
 Clément Pit--Claudel <clement.pit <at> gmail.com>,
 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Sat, 3 Sep 2016 13:53:40 -0400

On Sat, Sep 3, 2016 at 1:45 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
>> Date: Sat, 3 Sep 2016 13:29:39 -0400
>> Cc: 24091 <at> debbugs.gnu.org, Aiken <acairncross <at> gmail.com>,
>>       Clément Pit--Claudel <clement.pit <at> gmail.com>
>>
>> >> > I'd start by finding out why FRAME_ICONIFIED_P returns false.
>> >>
>> >> Well, it seems that's because Emacs never receives an UnmapNotify event.
>> >> But that doesn't feel like I'm getting any closer to a solution...
>> >
>> > What events does Emacs get in that case?
>>
>> Emacs is getting PropertyNotify, ConfigureNotify, MapNotify, and
>> ReparentNotify events.
>
> Does it work to turn this:
>
>         if (FRAME_ICONIFIED_P (f) &&  ++tries > 100)
>           break;
>
> into this:
>
>         if ((FRAME_ICONIFIED_P (f) || FRAME_VISIBLE_P (f)) &&  ++tries > 100)
>           break;

No, which sort of makes sense since the frame isn't actually visible.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: acairncross <at> gmail.com, clement.pit <at> gmail.com, 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Sat, 03 Sep 2016 21:35:29 +0300

> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
> Date: Sat, 3 Sep 2016 13:53:40 -0400
> Cc: 24091 <at> debbugs.gnu.org, Aiken <acairncross <at> gmail.com>, 
> 	Clément Pit--Claudel <clement.pit <at> gmail.com>
> 
> >> Emacs is getting PropertyNotify, ConfigureNotify, MapNotify, and
> >> ReparentNotify events.
> >
> > Does it work to turn this:
> >
> >         if (FRAME_ICONIFIED_P (f) &&  ++tries > 100)
> >           break;
> >
> > into this:
> >
> >         if ((FRAME_ICONIFIED_P (f) || FRAME_VISIBLE_P (f)) &&  ++tries > 100)
> >           break;
> 
> No, which sort of makes sense since the frame isn't actually visible.

But you said the MapNotify event was received?  Doesn't that cause the
frame to become marked as visible?

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Aiken <acairncross <at> gmail.com>,
 Clément Pit--Claudel <clement.pit <at> gmail.com>,
 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Sat, 3 Sep 2016 14:40:23 -0400

On Sat, Sep 3, 2016 at 2:35 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
>> Date: Sat, 3 Sep 2016 13:53:40 -0400
>> Cc: 24091 <at> debbugs.gnu.org, Aiken <acairncross <at> gmail.com>,
>>       Clément Pit--Claudel <clement.pit <at> gmail.com>
>>
>> >> Emacs is getting PropertyNotify, ConfigureNotify, MapNotify, and
>> >> ReparentNotify events.
>> >
>> > Does it work to turn this:
>> >
>> >         if (FRAME_ICONIFIED_P (f) &&  ++tries > 100)
>> >           break;
>> >
>> > into this:
>> >
>> >         if ((FRAME_ICONIFIED_P (f) || FRAME_VISIBLE_P (f)) &&  ++tries > 100)
>> >           break;
>>
>> No, which sort of makes sense since the frame isn't actually visible.
>
> But you said the MapNotify event was received?  Doesn't that cause the
> frame to become marked as visible?

Only if x_top_window_to_frame returns non-nil, which it does not.

    case MapNotify:
      /* We use x_top_window_to_frame because map events can
         come for sub-windows and they don't mean that the
         frame is visible.  */
      f = x_top_window_to_frame (dpyinfo, event->xmap.window);
      if (f)
        {
...
          SET_FRAME_VISIBLE (f, 1);
...
        }
      goto OTHER;

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: acairncross <at> gmail.com, clement.pit <at> gmail.com, 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Sat, 03 Sep 2016 21:51:16 +0300

> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
> Date: Sat, 3 Sep 2016 14:40:23 -0400
> Cc: 24091 <at> debbugs.gnu.org, Aiken <acairncross <at> gmail.com>, 
> 	Clément Pit--Claudel <clement.pit <at> gmail.com>
> 
> >> >         if ((FRAME_ICONIFIED_P (f) || FRAME_VISIBLE_P (f)) &&  ++tries > 100)
> >> >           break;
> >>
> >> No, which sort of makes sense since the frame isn't actually visible.
> >
> > But you said the MapNotify event was received?  Doesn't that cause the
> > frame to become marked as visible?
> 
> Only if x_top_window_to_frame returns non-nil, which it does not.

Why doesn't it, in this case, and how are things different with a
"normal" startup, which doesn't infloop?

Btw, I'm only asking these questions on the assumption that we have no
working idea for how to solve this.  If that assumption is false, feel
free to ignore me.

Thanks.

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Aiken <acairncross <at> gmail.com>,
 Clément Pit--Claudel <clement.pit <at> gmail.com>,
 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Sat, 3 Sep 2016 16:03:33 -0400

On Sat, Sep 3, 2016 at 2:51 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
>> Date: Sat, 3 Sep 2016 14:40:23 -0400
>> Cc: 24091 <at> debbugs.gnu.org, Aiken <acairncross <at> gmail.com>,
>>       Clément Pit--Claudel <clement.pit <at> gmail.com>
>>
>> >> >         if ((FRAME_ICONIFIED_P (f) || FRAME_VISIBLE_P (f)) &&  ++tries > 100)
>> >> >           break;
>> >>
>> >> No, which sort of makes sense since the frame isn't actually visible.
>> >
>> > But you said the MapNotify event was received?  Doesn't that cause the
>> > frame to become marked as visible?
>>
>> Only if x_top_window_to_frame returns non-nil, which it does not.
>
> Why doesn't it, in this case, and how are things different with a
> "normal" startup, which doesn't infloop?

Hmm, it's hard to tell. In the case where Emacs is opening in the
current workspace, event->xmap.window corresponds XtWindow
(f->output_data.x->widget) and in the problematic case of opening
Emacs in another workspace, it doesn't. The contents of event are
created in the guts of Xlib I guess, which makes it somewhat
mysterious.

>
> Btw, I'm only asking these questions on the assumption that we have no
> working idea for how to solve this.  If that assumption is false, feel
> free to ignore me.

No firm ideas, but as I've been stepping around this code, I'm more
and more wondering why we have this loop at all. The comment above
x_make_frame_visible says

/* This tries to wait until the frame is really visible.
   However, if the window manager asks the user where to position
   the frame, this will return before the user finishes doing that.
   The frame will not actually be visible at that time,
   but it will become visible later when the window manager
   finishes with it.  */

So I guess the loop is the part that "tries to wait". But if that
doesn't even work some of the time, why is it really necessary at all?
The code running after this function returns can't rely on this
working, so it would have to handle the not-yet-visible case anyway...

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

From: martin rudalics <rudalics <at> gmx.at>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>, 
 Eli Zaretskii <eliz <at> gnu.org>
Cc: Aiken <acairncross <at> gmail.com>,
 Clément Pit--Claudel <clement.pit <at> gmail.com>,
 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Sun, 04 Sep 2016 09:33:35 +0200

> Only if x_top_window_to_frame returns non-nil, which it does not.
>
>      case MapNotify:
>        /* We use x_top_window_to_frame because map events can
>           come for sub-windows and they don't mean that the
>           frame is visible.  */
>        f = x_top_window_to_frame (dpyinfo, event->xmap.window);

Where in x_window_to_frame does it fail?

martin

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Aiken <acairncross <at> gmail.com>,
 Clément Pit--Claudel <clement.pit <at> gmail.com>,
 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Sun, 4 Sep 2016 08:35:06 -0400

On Sun, Sep 4, 2016 at 3:33 AM, martin rudalics <rudalics <at> gmx.at> wrote:
>> Only if x_top_window_to_frame returns non-nil, which it does not.
>>
>>      case MapNotify:
>>        /* We use x_top_window_to_frame because map events can
>>           come for sub-windows and they don't mean that the
>>           frame is visible.  */
>>        f = x_top_window_to_frame (dpyinfo, event->xmap.window);
>
> Where in x_window_to_frame does it fail?

In case of opening Emacs on a different workspace, there are 2
MapNotify events before the infloop of x_make_frame_visible.

x_window_to_frame has a FOR_EACH_FRAME loop.

The 1st time, there is only one iteration of the frame loop and
FRAME_X_P (f) is false.
The 2nd time, there are two iterations of the frame loop. In the first
iteration, (wdesc == XtWindow (x->widget)) is false. In the second
iteration, FRAME_X_P (f) is false, like in the 1st MapNotify event.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Aiken <acairncross <at> gmail.com>,
 Clément Pit--Claudel <clement.pit <at> gmail.com>,
 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Sun, 04 Sep 2016 15:15:11 +0200

> The 2nd time, there are two iterations of the frame loop. In the first
> iteration, (wdesc == XtWindow (x->widget)) is false.

I suppose this happens for the frame x_make_frame_visible is waiting for
to become visible.  Correct?

martin

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Aiken <acairncross <at> gmail.com>,
 Clément Pit--Claudel <clement.pit <at> gmail.com>,
 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Sun, 4 Sep 2016 09:40:53 -0400

On Sun, Sep 4, 2016 at 9:15 AM, martin rudalics <rudalics <at> gmx.at> wrote:
>> The 2nd time, there are two iterations of the frame loop. In the first
>> iteration, (wdesc == XtWindow (x->widget)) is false.
>
> I suppose this happens for the frame x_make_frame_visible is waiting for
> to become visible.  Correct?

Having trouble parsing your sentence. This happens before
x_make_frame_visible gets called, and before the actual frame is
visible. Is that what you're asking?

During the infloop[1] of x_make_frame_visible, I can see an indication
for a new window coming up in the target workspace, but the frame is
still not visible because I haven't switched to the workspace yet. The
infloop gets one ConfigureNotify event, and then nothing else.


[1]: This one:
    /* Process X events until a MapNotify event has been seen.  */
    while (!FRAME_VISIBLE_P (f))

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

From: martin rudalics <rudalics <at> gmx.at>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Aiken <acairncross <at> gmail.com>,
 Clément Pit--Claudel <clement.pit <at> gmail.com>,
 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Sun, 04 Sep 2016 17:56:37 +0200

> Having trouble parsing your sentence. This happens before
> x_make_frame_visible gets called, and before the actual frame is
> visible. Is that what you're asking?

Sorry for being unclear: In x_make_frame_visible we have this loop:

    while (!FRAME_VISIBLE_P (f))

What I wanted to know is whether the frame f here is the _same_ frame
you see in x_top_window_to_frame where IIUC

	  if (wdesc == XtWindow (x->widget))
	    return f;

fails.  I see no other place where "(wdesc == XtWindow (x->widget)) is
false" would apply.  Or am I missing something?

martin

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Aiken <acairncross <at> gmail.com>,
 Clément Pit--Claudel <clement.pit <at> gmail.com>,
 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Sun, 4 Sep 2016 12:21:20 -0400

On Sun, Sep 4, 2016 at 11:56 AM, martin rudalics <rudalics <at> gmx.at> wrote:
> In x_make_frame_visible we have this loop:
>
>     while (!FRAME_VISIBLE_P (f))
>
> What I wanted to know is whether the frame f here is the _same_ frame
> you see in x_top_window_to_frame where IIUC
>
>           if (wdesc == XtWindow (x->widget))
>             return f;

Oh, I see. Yes, it is the same frame.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: rudalics <at> gmx.at, acairncross <at> gmail.com, clement.pit <at> gmail.com,
 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Tue, 06 Sep 2016 19:05:31 +0300

> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
> Date: Sun, 4 Sep 2016 12:21:20 -0400
> Cc: Aiken <acairncross <at> gmail.com>,
> 	Clément Pit--Claudel <clement.pit <at> gmail.com>,
> 	24091 <at> debbugs.gnu.org
> 
> On Sun, Sep 4, 2016 at 11:56 AM, martin rudalics <rudalics <at> gmx.at> wrote:
> > In x_make_frame_visible we have this loop:
> >
> >     while (!FRAME_VISIBLE_P (f))
> >
> > What I wanted to know is whether the frame f here is the _same_ frame
> > you see in x_top_window_to_frame where IIUC
> >
> >           if (wdesc == XtWindow (x->widget))
> >             return f;
> 
> Oh, I see. Yes, it is the same frame.

Maybe we should stop waiting after some time has passed, like 0.5
sec.  Does that work in this case?  Does the frame always appears
within half a second when workspaces are not involved?

Thanks.

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

From: Dominik Schrempf <dominik.schrempf <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24091 <at> debbugs.gnu.org, acairncross <at> gmail.com, clement.pit <at> gmail.com,
 Noam Postavsky <npostavs <at> users.sourceforge.net>
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Fri, 13 Jan 2017 11:19:52 +0100

Hello,

I do not want to bring up old threads, but I am having the exact same
problem with Emacs+XMonad for years now.  Did you come to a conclusion
or find a fix back in September?

Thanks,
Dominik

On Tue, Sep 06 2016, Eli Zaretskii wrote:
>> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
>> Date: Sun, 4 Sep 2016 12:21:20 -0400
>> Cc: Aiken <acairncross <at> gmail.com>,
>> 	Clément Pit--Claudel <clement.pit <at> gmail.com>,
>> 	24091 <at> debbugs.gnu.org
>> 
>> On Sun, Sep 4, 2016 at 11:56 AM, martin rudalics <rudalics <at> gmx.at> wrote:
>> > In x_make_frame_visible we have this loop:
>> >
>> >     while (!FRAME_VISIBLE_P (f))
>> >
>> > What I wanted to know is whether the frame f here is the _same_ frame
>> > you see in x_top_window_to_frame where IIUC
>> >
>> >           if (wdesc == XtWindow (x->widget))
>> >             return f;
>> 
>> Oh, I see. Yes, it is the same frame.
>
> Maybe we should stop waiting after some time has passed, like 0.5
> sec.  Does that work in this case?  Does the frame always appears
> within half a second when workspaces are not involved?
>
> Thanks.

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

From: npostavs <at> users.sourceforge.net
To: Dominik Schrempf <dominik.schrempf <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, acairncross <at> gmail.com, clement.pit <at> gmail.com,
 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Fri, 13 Jan 2017 20:38:02 -0500

[Message part 1 (text/plain, inline)]

tags 24091 patch
quit

Dominik Schrempf <dominik.schrempf <at> gmail.com> writes:

> I do not want to bring up old threads,

On the contrary, please do feel free to bring up any open bug thread.

> but I am having the exact same problem with Emacs+XMonad for years
> now.

That's interesting information, because I thought that loop was supposed
to be working for XMonad.

> Did you come to a conclusion or find a fix back in September?

We left things inconclusive, but revisiting this now, I see no reason
against simply removing this waiting loop:

[v1-0001-Don-t-wait-for-frame-to-become-visible.patch (text/plain, attachment)]

[Message part 3 (text/plain, inline)]

> On Tue, Sep 06 2016, Eli Zaretskii wrote:
>>
>> Maybe we should stop waiting after some time has passed, like 0.5
>> sec.  Does that work in this case?  Does the frame always appears
>> within half a second when workspaces are not involved?

I don't think any particular timed wait can be guaranteed to work in all
cases, since this involves multiple processes.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: npostavs <at> users.sourceforge.net, Ken Raeburn <raeburn <at> raeburn.org>
Cc: dominik.schrempf <at> gmail.com, acairncross <at> gmail.com, clement.pit <at> gmail.com,
 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Sat, 14 Jan 2017 09:52:23 +0200

> From: npostavs <at> users.sourceforge.net
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  24091 <at> debbugs.gnu.org,  acairncross <at> gmail.com,  clement.pit <at> gmail.com
> Date: Fri, 13 Jan 2017 20:38:02 -0500
> 
> We left things inconclusive, but revisiting this now, I see no reason
> against simply removing this waiting loop:

Are you saying that the loop has no purpose at all?  If it does, what
will happen with the code which needs that loop?  E.g., AFAIK some
stuff is impossible to do without the frame actually being shown on
display.

But maybe I'm wrong.  Ken, can you comment on this, please?

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

From: Ken Raeburn <raeburn <at> raeburn.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: dominik.schrempf <at> gmail.com, 24091 <at> debbugs.gnu.org, acairncross <at> gmail.com,
 clement.pit <at> gmail.com, npostavs <at> users.sourceforge.net
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Mon, 16 Jan 2017 18:36:05 -0500

On Jan 14, 2017, at 02:52, Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: npostavs <at> users.sourceforge.net
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  24091 <at> debbugs.gnu.org,  acairncross <at> gmail.com,  clement.pit <at> gmail.com
>> Date: Fri, 13 Jan 2017 20:38:02 -0500
>> 
>> We left things inconclusive, but revisiting this now, I see no reason
>> against simply removing this waiting loop:
> 
> Are you saying that the loop has no purpose at all?  If it does, what
> will happen with the code which needs that loop?  E.g., AFAIK some
> stuff is impossible to do without the frame actually being shown on
> display.
> 
> But maybe I'm wrong.  Ken, can you comment on this, please?

As I understand it, from the function’s comments and stuff I’ve read so far about the X11 and window manager protocols, the function already cannot guarantee that the window is visible when it returns, it can only request of the window manager that it make the window visible, which may or may not happen soon.  In that sense, I think Noam’s right and we could just discard the loop.

On the other hand, there are probably environments and situations (depending on the use of virtual desktops, choice of window manager, etc) where the current code does, in fact, wait for the window to appear, and won’t any more if we remove the loop.  Given that we should redraw things on expose events anyway, I’m not sure it'll matter, unless someone’s following up a call to make-frame-visible with some other action that needs to be delayed until after the window is actually visible.  I think it’s probably worth trying it to see if any differences are noticed under any of the environments people are using.

Ken

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Raeburn <raeburn <at> raeburn.org>
Cc: dominik.schrempf <at> gmail.com, 24091 <at> debbugs.gnu.org, acairncross <at> gmail.com,
 clement.pit <at> gmail.com, npostavs <at> users.sourceforge.net
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Tue, 17 Jan 2017 05:40:02 +0200

> From: Ken Raeburn <raeburn <at> raeburn.org>
> Date: Mon, 16 Jan 2017 18:36:05 -0500
> Cc: npostavs <at> users.sourceforge.net,
>  dominik.schrempf <at> gmail.com,
>  24091 <at> debbugs.gnu.org,
>  acairncross <at> gmail.com,
>  clement.pit <at> gmail.com
> 
> > But maybe I'm wrong.  Ken, can you comment on this, please?
> 
> As I understand it, from the function’s comments and stuff I’ve read so far about the X11 and window manager protocols, the function already cannot guarantee that the window is visible when it returns, it can only request of the window manager that it make the window visible, which may or may not happen soon.  In that sense, I think Noam’s right and we could just discard the loop.
> 
> On the other hand, there are probably environments and situations (depending on the use of virtual desktops, choice of window manager, etc) where the current code does, in fact, wait for the window to appear, and won’t any more if we remove the loop.  Given that we should redraw things on expose events anyway, I’m not sure it'll matter, unless someone’s following up a call to make-frame-visible with some other action that needs to be delayed until after the window is actually visible.  I think it’s probably worth trying it to see if any differences are noticed under any of the environments people are using.

OK, let's try.

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

From: npostavs <at> users.sourceforge.net
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: dominik.schrempf <at> gmail.com, Ken Raeburn <raeburn <at> raeburn.org>,
 acairncross <at> gmail.com, clement.pit <at> gmail.com, 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Tue, 17 Jan 2017 21:21:20 -0500

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

>> From: Ken Raeburn <raeburn <at> raeburn.org>
>> Given that we
>> should redraw things on expose events anyway, I’m not sure it'll
>> matter, unless someone’s following up a call to make-frame-visible
>> with some other action that needs to be delayed until after the
>> window is actually visible.

Do we know about any operations that require the frame be visible?  What
happens when they're run with an invisible frame?  Error?  Corrupted
display?  Hang?

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

From: Ken Raeburn <raeburn <at> raeburn.org>
To: npostavs <at> users.sourceforge.net
Cc: dominik.schrempf <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>,
 acairncross <at> gmail.com, clement.pit <at> gmail.com, 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Fri, 20 Jan 2017 00:16:24 -0500

On Jan 17, 2017, at 21:21, npostavs <at> users.sourceforge.net wrote:
> 
> Do we know about any operations that require the frame be visible?  What
> happens when they're run with an invisible frame?  Error?  Corrupted
> display?  Hang?

If drawing is done to an unmapped window, the X server can discard the data, but once the window is made visible, we should get an Expose event which would cause us to repaint the window.  The size and position of the window could be set by the window manager, and dropping the loop may mean we get to run a little more code than we used to before we get notified of the changes.  But these are things we have to deal with anyway, not just at window creation.  If we’re doing it right, AFAIK, we should be okay….

Ken

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

From: npostavs <at> users.sourceforge.net
To: Ken Raeburn <raeburn <at> raeburn.org>
Cc: dominik.schrempf <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>,
 acairncross <at> gmail.com, clement.pit <at> gmail.com, 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Fri, 20 Jan 2017 23:54:23 -0500

merge 24091 17237
tags 24091 fixed
close 24091 26.1
quit

Ken Raeburn <raeburn <at> raeburn.org> writes:

> On Jan 17, 2017, at 21:21, npostavs <at> users.sourceforge.net wrote:
>> 
>> Do we know about any operations that require the frame be visible?  What
>> happens when they're run with an invisible frame?  Error?  Corrupted
>> display?  Hang?
>
> If drawing is done to an unmapped window, the X server can discard the
> data, but once the window is made visible, we should get an Expose
> event which would cause us to repaint the window.  The size and
> position of the window could be set by the window manager, and
> dropping the loop may mean we get to run a little more code than we
> used to before we get notified of the changes.  But these are things
> we have to deal with anyway, not just at window creation.  If we’re
> doing it right, AFAIK, we should be okay….

Okay, pushed to master [1: 6a788d2], let's see if we're doing it right.

PS Dominik I merged #17237 into this one since it appears to be the same
problem which should be fixed by this patch, please report back if it's
not.

1: 2017-01-20 23:36:26 -0500 6a788d2fc18c23dcfc5d0352649b2f690e9cbff7
  Don't wait for frame to become visible

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

From: npostavs <at> users.sourceforge.net
To: control <at> debbugs.gnu.org
Cc: 24091 <at> debbugs.gnu.org
Subject: Re: control message for bug #20335
Date: Sat, 21 Jan 2017 00:03:54 -0500

# I really got mixed up with bug numbers.  Closing for the last (?) time.
close 20335 
quit

npostavs <at> users.sourceforge.net writes:

> forcemerge 20335 24091
> quit

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

From: Dominik Schrempf <dominik.schrempf <at> gmail.com>
To: npostavs <at> users.sourceforge.net
Cc: Eli Zaretskii <eliz <at> gnu.org>, Ken Raeburn <raeburn <at> raeburn.org>,
 acairncross <at> gmail.com, clement.pit <at> gmail.com, 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Mon, 23 Jan 2017 18:14:07 +0100

Works like a charm.  So far, it didn't lead to any problems.
Thank you very much!

Dominik

On Fri, Jan 20 2017, npostavs <at> users.sourceforge.net wrote:
> merge 24091 17237
> tags 24091 fixed
> close 24091 26.1
> quit
>
> Ken Raeburn <raeburn <at> raeburn.org> writes:
>
>> On Jan 17, 2017, at 21:21, npostavs <at> users.sourceforge.net wrote:
>>> 
>>> Do we know about any operations that require the frame be visible?  What
>>> happens when they're run with an invisible frame?  Error?  Corrupted
>>> display?  Hang?
>>
>> If drawing is done to an unmapped window, the X server can discard the
>> data, but once the window is made visible, we should get an Expose
>> event which would cause us to repaint the window.  The size and
>> position of the window could be set by the window manager, and
>> dropping the loop may mean we get to run a little more code than we
>> used to before we get notified of the changes.  But these are things
>> we have to deal with anyway, not just at window creation.  If we’re
>> doing it right, AFAIK, we should be okay….
>
> Okay, pushed to master [1: 6a788d2], let's see if we're doing it right.
>
> PS Dominik I merged #17237 into this one since it appears to be the same
> problem which should be fixed by this patch, please report back if it's
> not.
>
> 1: 2017-01-20 23:36:26 -0500 6a788d2fc18c23dcfc5d0352649b2f690e9cbff7
>   Don't wait for frame to become visible

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

From: Ken Brown <kbrown <at> cornell.edu>
To: 24091 <at> debbugs.gnu.org
Cc: Noam Postavsky <npostavs <at> users.sourceforge.net>
Subject: Problem caused by the fix for this bug
Date: Thu, 26 Oct 2017 13:22:51 -0400

I've just discovered that the fix for this bug (commit 
6a788d2fc18c23dcfc5d0352649b2f690e9cbff7) causes problems on the X11 
build of Emacs on Cygwin.  See the comments and code near the following 
comment that was removed in that commit:

"This hack is still in use at least for Cygwin.  See
http://lists.gnu.org/archive/html/emacs-devel/2013-12/msg00351.html."

The symptom, which I admit is purely cosmetic, is that the image at the 
top of the splash screen is not displayed on startup.  I hope the people 
who worked on this bug know how to fix this, because I don't know 
anything about how X11 and polling for input work.  If not, I'll try to 
dig into it.

Ken

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: Problem caused by the fix for this bug
Date: Thu, 26 Oct 2017 13:42:03 -0400

On Thu, Oct 26, 2017 at 1:22 PM, Ken Brown <kbrown <at> cornell.edu> wrote:
> I've just discovered that the fix for this bug (commit
> 6a788d2fc18c23dcfc5d0352649b2f690e9cbff7) causes problems on the X11 build
> of Emacs on Cygwin

This was later modified in [1: e1f6e31]; do you see problems before
that commit, or after it (or both)?

[1: e1f6e31]: 2017-09-29 18:40:06 -0400
  Bring back the busy wait after x_make_frame_visible (Bug#25521)
  http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=e1f6e3127a292e6ba66d27c49ddda4fe949569f5

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

From: Ken Brown <kbrown <at> cornell.edu>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: Problem caused by the fix for this bug
Date: Thu, 26 Oct 2017 14:12:03 -0400

On 10/26/2017 1:42 PM, Noam Postavsky wrote:
> On Thu, Oct 26, 2017 at 1:22 PM, Ken Brown <kbrown <at> cornell.edu> wrote:
>> I've just discovered that the fix for this bug (commit
>> 6a788d2fc18c23dcfc5d0352649b2f690e9cbff7) causes problems on the X11 build
>> of Emacs on Cygwin
> 
> This was later modified in [1: e1f6e31]; do you see problems before
> that commit, or after it (or both)?

The commit I cited was the first bad one (as determined by git bisect). 
The problem still exists in the current HEAD of the emacs-26 branch.

Ken

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: Problem caused by the fix for this bug
Date: Thu, 26 Oct 2017 16:40:02 -0400

On Thu, Oct 26, 2017 at 2:12 PM, Ken Brown <kbrown <at> cornell.edu> wrote:

> The commit I cited was the first bad one (as determined by git bisect). The
> problem still exists in the current HEAD of the emacs-26 branch.

Okay. I removed the code because my understanding of the comment was
that it was needed to prevent a hang during the busy wait for
visibility. Therefore, when I removed that busy wait, I thought that
poll_for_input_1 was no longer needed either.

However, from what you say, it sounds like it's rather needed after
creating a frame, unrelated to the waiting per se. I don't really
understand what the code does, but I guess you could try putting the
poll_for_input_1 stuff back in either before, inside, or after the
x_wait_for_event at the end of x_make_frame_visible and see what
helps?

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

From: Ken Brown <kbrown <at> cornell.edu>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: Problem caused by the fix for this bug
Date: Fri, 27 Oct 2017 10:11:19 -0400

[Message part 1 (text/plain, inline)]

On 10/26/2017 4:40 PM, Noam Postavsky wrote:
> On Thu, Oct 26, 2017 at 2:12 PM, Ken Brown <kbrown <at> cornell.edu> wrote:
> 
>> The commit I cited was the first bad one (as determined by git bisect). The
>> problem still exists in the current HEAD of the emacs-26 branch.
> 
> Okay. I removed the code because my understanding of the comment was
> that it was needed to prevent a hang during the busy wait for
> visibility. Therefore, when I removed that busy wait, I thought that
> poll_for_input_1 was no longer needed either.
> 
> However, from what you say, it sounds like it's rather needed after
> creating a frame, unrelated to the waiting per se. I don't really
> understand what the code does, but I guess you could try putting the
> poll_for_input_1 stuff back in either before, inside, or after the
> x_wait_for_event at the end of x_make_frame_visible and see what
> helps?

Putting it before the x_wait_for_event fixes the problem.  Patch attached.

Eli, is it OK to push this to the release branch?

Ken

[0001-Fix-startup-display-on-Cygwin.patch (text/plain, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: 24091 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#24091: Problem caused by the fix for this bug
Date: Fri, 27 Oct 2017 20:26:51 +0300

> Cc: 24091 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
> From: Ken Brown <kbrown <at> cornell.edu>
> Date: Fri, 27 Oct 2017 10:11:19 -0400
> 
> Eli, is it OK to push this to the release branch?

Since this a Cygwin-only problem, I'd prefer that fix will be
Cygwin-specific.  Then it will be okay for the release branch.

Thanks.

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

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24091 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#24091: Problem caused by the fix for this bug
Date: Fri, 27 Oct 2017 13:53:53 -0400

On 10/27/2017 1:26 PM, Eli Zaretskii wrote:
> Since this a Cygwin-only problem, I'd prefer that fix will be
> Cygwin-specific.  Then it will be okay for the release branch.

OK, I've pushed it with that change.

Ken

Previous Next

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