Emacs Slowdown

Emacs Slowdown

[Phillip Lord]

I am suffering a rather disasterous slowdown in my emacs. It feels like
a memory leak, as my emacs gets slower over time. It mostly seems to be
affected auctex, where there is considerable lag in cursor movement to
the point that typing becomes difficult.

I've tried the profiler. After a long run, I find this for memory usage:

- redisplay_internal (C function)                       2,853,658,459  79%
 - and                                                  2,682,842,214  74%
  - directory-files                                           110,636   0%
   - concat                                                    74,740   0%
      regexp-quote                                             57,316   0%
    file-directory-p

which is a bit strange. I have no idea when "and" should be getting
called so much. The top of the CPU profile looks like this...


- command-execute                                                3996  73%
 - call-interactively                                            3996  73%
  - apply                                                        3996  73%
   - ad-Advice-call-interactively                                3996  73%
    - #<subr call-interactively>                                 3993  73%
     - ido-find-file                                             2231  40%
      - ido-file-internal                                        2231  40%
       - ido-read-internal                                       2181  39%
        - apply                                                  2181  39%
         - ad-Advice-ido-read-internal                           2181  39%
          + #<compiled 0xce6205>     



One other thing that I have noticed is that define-global-minor-mode
adds to the post-command-hook. Currently, this means that my
post-command-hook looks like this....


(global-font-lock-mode-check-buffers global-lentic-mode-check-buffers
global-pabbrev-mode-check-buffers yas-global-mode-check-buffers
global-eval-pulse-mode-check-buffers
global-auto-complete-mode-check-buffers
projectile-global-mode-check-buffers
global-wide-column-mode-check-buffers
wide-column-post-command-hook-function phil-show-paren-mode-check
winner-save-old-configurations mode-local-post-major-mode-change)

which is an awful lot of functions to be called on every keypress. I
realise that I may have gone a bit overboard here, especially as five of
those functions are mine!

I am sort of at a loss as to how to debug this further. Clever ideas
appreciated.

Phil

Re: Emacs Slowdown

[Eli Zaretskii]

> From: phillip.lord@newcastle.ac.uk (Phillip Lord)
> Date: Mon, 09 Mar 2015 11:48:47 +0000
> 
> I am suffering a rather disasterous slowdown in my emacs. It feels like
> a memory leak, as my emacs gets slower over time. It mostly seems to be
> affected auctex, where there is considerable lag in cursor movement to
> the point that typing becomes difficult.

For starters, customize garbage-collection-messages to a non-nil
value, and see if Emacs announces GC while cursor movement is
sluggish.

> I've tried the profiler. After a long run, I find this for memory usage:
> 
> - redisplay_internal (C function)                       2,853,658,459  79%
>  - and                                                  2,682,842,214  74%
>   - directory-files                                           110,636   0%
>    - concat                                                    74,740   0%
>       regexp-quote                                             57,316   0%
>     file-directory-p
> 
> which is a bit strange. I have no idea when "and" should be getting
> called so much. The top of the CPU profile looks like this...

Forget the memory-usage profile, it doesn't measure what you think it
does, and is mostly useless, except in very specialized situations,
and then for people who really understand what this means (I don't).

If you want to test the hypothesis of a memory leak, it's easier to
look at your Emacs process's virtual memory size, either in 'top' or
in "M-x proced".  Take a few snapshots of the value and try to
correlate that with the values reported by 'garbage-collect'.  If
those values stay approximately stable, or go down, but the VSS of the
process goes up, you can suspect a memory leak; otherwise the problem
is elsewhere.

(Personally, I wouldn't pursue the memory leak avenue first,
especially if this is an official release, not a development version
of Emacs: I think other possible reasons are much more probable.  But
that's me.)

> One other thing that I have noticed is that define-global-minor-mode
> adds to the post-command-hook. Currently, this means that my
> post-command-hook looks like this....
> 
> 
> (global-font-lock-mode-check-buffers global-lentic-mode-check-buffers
> global-pabbrev-mode-check-buffers yas-global-mode-check-buffers
> global-eval-pulse-mode-check-buffers
> global-auto-complete-mode-check-buffers
> projectile-global-mode-check-buffers
> global-wide-column-mode-check-buffers
> wide-column-post-command-hook-function phil-show-paren-mode-check
> winner-save-old-configurations mode-local-post-major-mode-change)
> 
> which is an awful lot of functions to be called on every keypress. I
> realise that I may have gone a bit overboard here, especially as five of
> those functions are mine!

The question is: what do those hook do, on average?  If they are very
lightweight (profile them to see if they are), then this isn't your
villain.

Also, try removing most of the hooks when you see sluggish operation,
and see if that brings any significant speedup; if not, these aren't
what you are looking for.

Re: Emacs Slowdown

[Stefan Monnier]

> Forget the memory-usage profile, it doesn't measure what you think it
> does, and is mostly useless, except in very specialized situations,
> and then for people who really understand what this means (I don't).

Agreed (except maybe for the "I don't" part ;-), we should at least
"hide" it.  It was mostly a hack to work around the lack of timer-based
sampling in some platform in the early versions of the profiler code.


        Stefan

Re: Emacs Slowdown

[Stefan Monnier]

> which is a bit strange. I have no idea when "and" should be getting
> called so much. The top of the CPU profile looks like this...

> - command-execute                                                3996  73%
>  - call-interactively                                            3996  73%
>   - apply                                                        3996  73%
>    - ad-Advice-call-interactively                                3996  73%
>     - #<subr call-interactively>                                 3993  73%
>      - ido-find-file                                             2231  40%
>       - ido-file-internal                                        2231  40%
>        - ido-read-internal                                       2181  39%
>         - apply                                                  2181  39%
>          - ad-Advice-ido-read-internal                           2181  39%
>           + #<compiled 0xce6205>

This looks like rather few samples.  Try to take a profile of a longer
duration with more commands (especially those you think should be very
quick and yet take a long time).

> (global-font-lock-mode-check-buffers global-lentic-mode-check-buffers
> global-pabbrev-mode-check-buffers yas-global-mode-check-buffers
> global-eval-pulse-mode-check-buffers
> global-auto-complete-mode-check-buffers
> projectile-global-mode-check-buffers
> global-wide-column-mode-check-buffers
> wide-column-post-command-hook-function phil-show-paren-mode-check
> winner-save-old-configurations mode-local-post-major-mode-change)

Those should only appear on post-command-hook transiently (i.e. only
after a command whose execution called a major-mode).


        Stefan

Re: Emacs Slowdown

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: phillip.lord@newcastle.ac.uk (Phillip Lord)
>> Date: Mon, 09 Mar 2015 11:48:47 +0000
>> 
>> I am suffering a rather disasterous slowdown in my emacs. It feels like
>> a memory leak, as my emacs gets slower over time. It mostly seems to be
>> affected auctex, where there is considerable lag in cursor movement to
>> the point that typing becomes difficult.
>
> For starters, customize garbage-collection-messages to a non-nil
> value, and see if Emacs announces GC while cursor movement is
> sluggish.


Ah, yes, forgotten that one.


> If you want to test the hypothesis of a memory leak, it's easier to
> look at your Emacs process's virtual memory size, either in 'top' or
> in "M-x proced".  Take a few snapshots of the value and try to
> correlate that with the values reported by 'garbage-collect'.  If
> those values stay approximately stable, or go down, but the VSS of the
> process goes up, you can suspect a memory leak; otherwise the problem
> is elsewhere.
>
> (Personally, I wouldn't pursue the memory leak avenue first,
> especially if this is an official release, not a development version
> of Emacs: I think other possible reasons are much more probable.  But
> that's me.)


I've been using both using both releases and development. I'd agree,
I've not found many memory leaks in my time.


>> which is an awful lot of functions to be called on every keypress. I
>> realise that I may have gone a bit overboard here, especially as five of
>> those functions are mine!
>
> The question is: what do those hook do, on average?  If they are very
> lightweight (profile them to see if they are), then this isn't your
> villain.
>
> Also, try removing most of the hooks when you see sluggish operation,
> and see if that brings any significant speedup; if not, these aren't
> what you are looking for.

Saw Stefan's post and think these are a red-herring also.

Phil

Re: Emacs Slowdown

[Phillip Lord]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> which is a bit strange. I have no idea when "and" should be getting
>> called so much. The top of the CPU profile looks like this...
>
>> - command-execute                                                3996  73%
>>  - call-interactively                                            3996  73%
>>   - apply                                                        3996  73%
>>    - ad-Advice-call-interactively                                3996  73%
>>     - #<subr call-interactively>                                 3993  73%
>>      - ido-find-file                                             2231  40%
>>       - ido-file-internal                                        2231  40%
>>        - ido-read-internal                                       2181  39%
>>         - apply                                                  2181  39%
>>          - ad-Advice-ido-read-internal                           2181  39%
>>           + #<compiled 0xce6205>
>
> This looks like rather few samples.  Try to take a profile of a longer
> duration with more commands (especially those you think should be very
> quick and yet take a long time).

I'll try that.


>
>> (global-font-lock-mode-check-buffers global-lentic-mode-check-buffers
>> global-pabbrev-mode-check-buffers yas-global-mode-check-buffers
>> global-eval-pulse-mode-check-buffers
>> global-auto-complete-mode-check-buffers
>> projectile-global-mode-check-buffers
>> global-wide-column-mode-check-buffers
>> wide-column-post-command-hook-function phil-show-paren-mode-check
>> winner-save-old-configurations mode-local-post-major-mode-change)
>
> Those should only appear on post-command-hook transiently (i.e. only
> after a command whose execution called a major-mode).

Ah, yes, I didn't understand the help screen correctly.
define-global-minor-mode adds to the default value and then takes these
off buffer local once they have run?

Phil

Re: Emacs Slowdown

[Stefan Monnier]

> Ah, yes, I didn't understand the help screen correctly.
> define-global-minor-mode adds to the default value and then takes these
> off buffer local once they have run?

Exactly.  Of course, it may be that some hook somewhere ends up calling
a major-mode every time we run a command, which could lead these things
to be constantly re-added to post-command-hook.

Still: even running all those functions all the time shouldn't slow you
down, unless one of those functions takes a long time to execute.


        Stefan

Re: Emacs Slowdown

[Eli Zaretskii]

> From: phillip.lord@newcastle.ac.uk (Phillip Lord)
> Cc: <help-gnu-emacs@gnu.org>
> Date: Tue, 10 Mar 2015 12:37:15 +0000
> 
> >> which is an awful lot of functions to be called on every keypress. I
> >> realise that I may have gone a bit overboard here, especially as five of
> >> those functions are mine!
> >
> > The question is: what do those hook do, on average?  If they are very
> > lightweight (profile them to see if they are), then this isn't your
> > villain.
> >
> > Also, try removing most of the hooks when you see sluggish operation,
> > and see if that brings any significant speedup; if not, these aren't
> > what you are looking for.
> 
> Saw Stefan's post and think these are a red-herring also.

So if turning on GC messages doesn't give any hints, I'd suggest to
wait until you see a sluggish cursor movement, then start a CPU
profiler, perform several such cursor movements, produce the report,
and post that here.

Re: Emacs Slowdown

[Phillip Lord]

Phillip Lord <phillip.lord@newcastle.ac.uk> writes:

> - command-execute                                                3996  73%
>  - call-interactively                                            3996  73%
>   - apply                                                        3996  73%
>    - ad-Advice-call-interactively                                3996  73%
>     - #<subr call-interactively>                                 3993  73%
>      - ido-find-file                                             2231  40%
>       - ido-file-internal                                        2231  40%
>        - ido-read-internal                                       2181  39%
>         - apply                                                  2181  39%
>          - ad-Advice-ido-read-internal                           2181  39%
>           + #<compiled 0xce6205>     



Okay, I think that I have chased down the issue here (at least to a
first approximation.

This bit of trace above was what was confusing me, as I couldn't see why
there were so many calls to ido-find-file, or the time taken in
ad-Advice-call-interactively. Actually most of this seems to be coming
from ido-ubiquitous.el which advinces call-interactively. Certainly the
problem goes away without ido-ubiquitous.

I haven't worked out yet whether there is a specific problem with
ubiquitous yet, or whether it really is leaking memory. Or whether, it's
just the nature of the beast.

Phil

Re: Emacs Slowdown

[Phillip Lord]

Phillip Lord <phillip.lord@newcastle.ac.uk> writes:

> Phillip Lord <phillip.lord@newcastle.ac.uk> writes:
>
>> - command-execute                                                3996  73%
>>  - call-interactively                                            3996  73%
>>   - apply                                                        3996  73%
>>    - ad-Advice-call-interactively                                3996  73%
>>     - #<subr call-interactively>                                 3993  73%
>>      - ido-find-file                                             2231  40%
>>       - ido-file-internal                                        2231  40%
>>        - ido-read-internal                                       2181  39%
>>         - apply                                                  2181  39%
>>          - ad-Advice-ido-read-internal                           2181  39%
>>           + #<compiled 0xce6205>     
>
>
>
> Okay, I think that I have chased down the issue here (at least to a
> first approximation.
>
> Certainly the problem goes away without ido-ubiquitous.


Okay, I may have been premature here. I am still getting slowdown
anyway. Here is the top level of a longish profile (difficult to do
because Emacs is so slow that it's hard to type).

Slight worried that one of my own packages is in the list although, it's
does not appear to be called often. To my knowledge I didn't actually
drag-region during this period, so am confused about this. This emacs
hung eventually and had to be xkill'd.

- command-execute                                               20646  93%
 - call-interactively                                           20643  93%
  - mouse-drag-region                                           15591  70%
   - mouse-drag-track                                           15591  70%
    - eval                                                      15474  69%
     - track-mouse                                              15471  69%
      - funcall                                                 12410  55%
       - #<compiled 0x5d65117>                                  12410  55%
        - read-event                                            12379  55%
         - redisplay_internal (C function)                         62   0%
          + #<compiled 0x40a92d>                                   30   0%
            and                                                    19   0%
          - msb-menu-bar-update-buffers                            13   0%
           - msb--create-buffer-menu                               13   0%
            - msb--create-buffer-menu-2                            13   0%
               msb--mode-menu-cond                                 13   0%
    - mouse-set-point                                             110   0%
     - posn-set-point                                             110   0%
      - select-window                                             110   0%
       - run-hooks                                                110   0%
        - lentic-mode-buffer-list-update-hook                     110   0%
         - if                                                     110   0%
          - -map                                                  110   0%
           - mapcar                                               110   0%
            + #<lambda 0x2aa4c8f82b1b222c>                        110   0%
  + byte-code                                                    3163  14%
  + list                                                         1360   6%
  + Info-mouse-follow-nearest-node                                213   0%
  + Info-index                                                    113   0%
  + next-line                                                      45   0%
  + info                                                           33   0%
  + previous-line                                                  31   0%
  + save-buffer                                                    23   0%
  + Info-index-next                                                18   0%
  + newline                                                        13   0%
  + execute-extended-command                                       11   0%
  + mouse-set-point                                                 8   0%
  + move-end-of-line                                                5   0%
  + paredit-close-round                                             5   0%
  + indent-for-tab-command                                          4   0%
  + paredit-open-round                                              3   0%
    self-insert-command                                             1   0%
- ...                         

Re: Emacs Slowdown

[Stefan Monnier]

> Slight worried that one of my own packages is in the list although, it's
> does not appear to be called often.  To my knowledge I didn't actually
> drag-region during this period, so am confused about this.

The down part of a single mouse-click calls mouse-drag-region (because
at that point we don't know yet whether you're about to drag or just to
click).

I don't see any tell-tale problem in the Elisp profile.

> This Emacs hung eventually and had to be xkill'd.

Ah, then a C-level backtrace might be helpful.  I.e. instead of killing
the beast, attach to it with GDB.


        Stefan

Re: Emacs Slowdown

[Phillip Lord]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Slight worried that one of my own packages is in the list although, it's
>> does not appear to be called often.  To my knowledge I didn't actually
>> drag-region during this period, so am confused about this.
>
> The down part of a single mouse-click calls mouse-drag-region (because
> at that point we don't know yet whether you're about to drag or just to
> click).
>
> I don't see any tell-tale problem in the Elisp profile.

I will try and see if this is repeatable.


>> This Emacs hung eventually and had to be xkill'd.
>
> Ah, then a C-level backtrace might be helpful.  I.e. instead of killing
> the beast, attach to it with GDB.


Okay, that's going to take a bit more learning on my behalf, bit I will
work on this next.

Phil

Re: Emacs Slowdown

[Phillip Lord]

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

Phillip Lord <phillip.lord@newcastle.ac.uk> writes:
>>> This Emacs hung eventually and had to be xkill'd.
>>
>> Ah, then a C-level backtrace might be helpful.  I.e. instead of killing
>> the beast, attach to it with GDB.
>
>
> Okay, that's going to take a bit more learning on my behalf, bit I will
> work on this next.

Apologies if I have not done the right thing here -- I've not written
much C nor used gdb before.

Here are a set of backtraces at some random points within an emacs
session. I let it go till it hung. The last two backtraces are after it
has become non-responsive, up till the kill.

This was, again, while using auctex.


[-- Attachment #2: crash.txt --]
[-- Type: text/plain, Size: 30147 bytes --]

---Type <return> to continue, or q <return> to quit---
	set auto-load safe-path /
line to your configuration file "/home/phillord/.gdbinit".
For more information about this security protection, see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
	info "(gdb)Auto-loading safe path"
(gdb) continue
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x00007fbb04d70e79 in __pselect (nfds=nfds@entry=20, 
    readfds=readfds@entry=0x7fff3fade550, 
    writefds=writefds@entry=0x7fff3fade5d0, exceptfds=exceptfds@entry=0x0, 
    timeout=<optimised out>, timeout@entry=0x7fff3fadeb30, 
    sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/pselect.c:77
77	in ../sysdeps/unix/sysv/linux/pselect.c
(gdb) bt
#0  0x00007fbb04d70e79 in __pselect (nfds=nfds@entry=20, 
    readfds=readfds@entry=0x7fff3fade550, 
    writefds=writefds@entry=0x7fff3fade5d0, exceptfds=exceptfds@entry=0x0, 
    timeout=<optimised out>, timeout@entry=0x7fff3fadeb30, 
    sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/pselect.c:77
#1  0x00000000005cc63b in xg_select (fds_lim=20, 
    rfds=rfds@entry=0x7fff3fadeb40, wfds=wfds@entry=0x7fff3fadebc0, 
    efds=efds@entry=0x0, timeout=timeout@entry=0x7fff3fadeb30, 
    sigmask=sigmask@entry=0x0) at xgselect.c:114
#2  0x000000000059555d in wait_reading_process_output (
    time_limit=time_limit@entry=30, nsecs=nsecs@entry=0, 
    read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true, 
    wait_for_cell=12140850, wait_proc=wait_proc@entry=0x0, 
    just_wait_proc=just_wait_proc@entry=0) at process.c:4606
#3  0x0000000000421a54 in sit_for (timeout=<optimised out>, 
    reading=reading@entry=true, display_option=display_option@entry=1)
    at dispnew.c:5867
#4  0x00000000004f0b04 in read_char (commandflag=1, map=map@entry=244440758, 
    prev_event=12140850, used_mouse_menu=used_mouse_menu@entry=0x7fff3fadf1bb, 
    end_time=end_time@entry=0x0) at keyboard.c:2810
#5  0x00000000004f1fdf in read_key_sequence (
    keybuf=keybuf@entry=0x7fff3fadf290, prompt=12140850, 
    dont_downcase_last=dont_downcase_last@entry=false, 
---Type <return> to continue, or q <return> to quit---
    can_return_switch_frame=can_return_switch_frame@entry=true, 
    fix_current_buffer=fix_current_buffer@entry=true, 
    prevent_redisplay=prevent_redisplay@entry=false, bufsize=30)
    at keyboard.c:9089
#6  0x00000000004f3bd0 in command_loop_1 () at keyboard.c:1453
#7  0x00000000005557ae in internal_condition_case (
    bfun=bfun@entry=0x4f39e0 <command_loop_1>, handlers=<optimised out>, 
    hfun=hfun@entry=0x4ea950 <cmd_error>) at eval.c:1348
#8  0x00000000004e608e in command_loop_2 (ignore=ignore@entry=12140850)
    at keyboard.c:1178
#9  0x00000000005556bb in internal_catch (tag=12188354, 
    func=func@entry=0x4e6070 <command_loop_2>, arg=12140850) at eval.c:1112
#10 0x00000000004ea577 in command_loop () at keyboard.c:1157
#11 recursive_edit_1 () at keyboard.c:778
#12 0x00000000004ea88d in Frecursive_edit () at keyboard.c:849
#13 0x0000000000417c95 in main (argc=<optimised out>, argv=0x7fff3fadf5e8)
    at emacs.c:1642
(gdb) 
(gdb) continue
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x00007fbb04d70e79 in __pselect (nfds=nfds@entry=20, 
    readfds=readfds@entry=0x7fff3fade550, 
    writefds=writefds@entry=0x7fff3fade5d0, exceptfds=exceptfds@entry=0x0, 
    timeout=<optimised out>, timeout@entry=0x7fff3fadeb30, 
    sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/pselect.c:77
77	in ../sysdeps/unix/sysv/linux/pselect.c
(gdb) bt
#0  0x00007fbb04d70e79 in __pselect (nfds=nfds@entry=20, 
    readfds=readfds@entry=0x7fff3fade550, 
    writefds=writefds@entry=0x7fff3fade5d0, exceptfds=exceptfds@entry=0x0, 
    timeout=<optimised out>, timeout@entry=0x7fff3fadeb30, 
    sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/pselect.c:77
#1  0x00000000005cc63b in xg_select (fds_lim=20, 
    rfds=rfds@entry=0x7fff3fadeb40, wfds=wfds@entry=0x7fff3fadebc0, 
    efds=efds@entry=0x0, timeout=timeout@entry=0x7fff3fadeb30, 
    sigmask=sigmask@entry=0x0) at xgselect.c:114
#2  0x000000000059555d in wait_reading_process_output (
    time_limit=time_limit@entry=30, nsecs=nsecs@entry=0, 
    read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true, 
    wait_for_cell=12140850, wait_proc=wait_proc@entry=0x0, 
    just_wait_proc=just_wait_proc@entry=0) at process.c:4606
#3  0x0000000000421a54 in sit_for (timeout=<optimised out>, 
    reading=reading@entry=true, display_option=display_option@entry=1)
    at dispnew.c:5867
#4  0x00000000004f0b04 in read_char (commandflag=1, map=map@entry=189430662, 
    prev_event=12140850, used_mouse_menu=used_mouse_menu@entry=0x7fff3fadf1bb, 
    end_time=end_time@entry=0x0) at keyboard.c:2810
#5  0x00000000004f1fdf in read_key_sequence (
    keybuf=keybuf@entry=0x7fff3fadf290, prompt=12140850, 
    dont_downcase_last=dont_downcase_last@entry=false, 
---Type <return> to continue, or q <return> to quit---
    can_return_switch_frame=can_return_switch_frame@entry=true, 
    fix_current_buffer=fix_current_buffer@entry=true, 
    prevent_redisplay=prevent_redisplay@entry=false, bufsize=30)
    at keyboard.c:9089
#6  0x00000000004f3bd0 in command_loop_1 () at keyboard.c:1453
#7  0x00000000005557ae in internal_condition_case (
    bfun=bfun@entry=0x4f39e0 <command_loop_1>, handlers=<optimised out>, 
    hfun=hfun@entry=0x4ea950 <cmd_error>) at eval.c:1348
#8  0x00000000004e608e in command_loop_2 (ignore=ignore@entry=12140850)
    at keyboard.c:1178
#9  0x00000000005556bb in internal_catch (tag=12188354, 
    func=func@entry=0x4e6070 <command_loop_2>, arg=12140850) at eval.c:1112
#10 0x00000000004ea577 in command_loop () at keyboard.c:1157
#11 recursive_edit_1 () at keyboard.c:778
#12 0x00000000004ea88d in Frecursive_edit () at keyboard.c:849
#13 0x0000000000417c95 in main (argc=<optimised out>, argv=0x7fff3fadf5e8)
    at emacs.c:1642
(gdb) continue
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x00007fbb04d70e79 in __pselect (nfds=nfds@entry=20, 
    readfds=readfds@entry=0x7fff3fade550, 
    writefds=writefds@entry=0x7fff3fade5d0, exceptfds=exceptfds@entry=0x0, 
    timeout=<optimised out>, timeout@entry=0x7fff3fadeb30, 
    sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/pselect.c:77
77	in ../sysdeps/unix/sysv/linux/pselect.c
(gdb) continue
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x00007fbb04d70e79 in __pselect (nfds=nfds@entry=20, 
    readfds=readfds@entry=0x7fff3fadcbe0, 
    writefds=writefds@entry=0x7fff3fadcc60, exceptfds=exceptfds@entry=0x0, 
    timeout=<optimised out>, timeout@entry=0x7fff3fadd1c0, 
    sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/pselect.c:77
77	in ../sysdeps/unix/sysv/linux/pselect.c
(gdb) bt
#0  0x00007fbb04d70e79 in __pselect (nfds=nfds@entry=20, 
    readfds=readfds@entry=0x7fff3fadcbe0, 
    writefds=writefds@entry=0x7fff3fadcc60, exceptfds=exceptfds@entry=0x0, 
    timeout=<optimised out>, timeout@entry=0x7fff3fadd1c0, 
    sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/pselect.c:77
#1  0x00000000005cc63b in xg_select (fds_lim=20, 
    rfds=rfds@entry=0x7fff3fadd1d0, wfds=wfds@entry=0x7fff3fadd250, 
    efds=efds@entry=0x0, timeout=timeout@entry=0x7fff3fadd1c0, 
    sigmask=sigmask@entry=0x0) at xgselect.c:114
#2  0x000000000059555d in wait_reading_process_output (
    time_limit=<optimised out>, nsecs=999263354, read_kbd=read_kbd@entry=-1, 
    do_display=do_display@entry=true, wait_for_cell=12140850, 
    wait_proc=wait_proc@entry=0x0, just_wait_proc=just_wait_proc@entry=0)
    at process.c:4606
#3  0x00000000004ece3e in kbd_buffer_get_event (end_time=0x7fff3fadd9d0, 
    used_mouse_menu=<optimised out>, kbp=<synthetic pointer>)
    at keyboard.c:3886
#4  read_event_from_main_queue (used_mouse_menu=<optimised out>, 
    local_getcjmp=<optimised out>, end_time=0x7fff3fadd9d0) at keyboard.c:2247
#5  read_decoded_event_from_main_queue (
    end_time=end_time@entry=0x7fff3fadd9d0, 
    local_getcjmp=local_getcjmp@entry=0x7fff3fadd7c0, 
    prev_event=prev_event@entry=12140850, 
---Type <return> to continue, or q <return> to quit---
    used_mouse_menu=used_mouse_menu@entry=0x0) at keyboard.c:2310
#6  0x00000000004f120c in read_char (commandflag=commandflag@entry=0, 
    map=12140850, prev_event=12140850, 
    used_mouse_menu=used_mouse_menu@entry=0x0, end_time=0x7fff3fadd9d0)
    at keyboard.c:2896
#7  0x00000000005746c0 in read_filtered_event (no_switch_frame=false, 
    ascii_required=false, error_nonascii=false, input_method=true, 
    seconds=<optimised out>) at lread.c:632
#8  0x0000000000557390 in Ffuncall (nargs=<optimised out>, 
    args=<optimised out>) at eval.c:2818
#9  0x000000000058b655 in exec_byte_code (bytestr=-514, 
    vector=140734261742560, maxdepth=140734261742688, args_template=3076, 
    nargs=140734261746344, args=0x4) at bytecode.c:916
#10 0x0000000000556ed7 in funcall_lambda (fun=140734261749248, 
    fun@entry=8772789, nargs=nargs@entry=1, arg_vector=0x85dce1 <pure+123745>, 
    arg_vector@entry=0x7fff3faddb70) at eval.c:2978
#11 0x00000000005562d8 in apply_lambda (fun=8772789, args=<optimised out>, 
    count=count@entry=26) at eval.c:2919
#12 0x000000000055667c in eval_sub (form=<optimised out>) at eval.c:2256
#13 0x0000000000556ba5 in Fprogn (body=20) at eval.c:462
#14 0x0000000000556976 in eval_sub (form=<optimised out>) at eval.c:2131
#15 0x0000000000556976 in eval_sub (form=<optimised out>) at eval.c:2131
#16 0x0000000000556ba5 in Fprogn (body=20) at eval.c:462
---Type <return> to continue, or q <return> to quit---
#17 0x00000000005597c5 in Flet (args=53965126) at eval.c:970
#18 0x0000000000556976 in eval_sub (form=<optimised out>) at eval.c:2131
#19 0x0000000000556ba5 in Fprogn (body=20) at eval.c:462
#20 0x0000000000556f3c in funcall_lambda (fun=fun@entry=53965094, 
    nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x7fff3fade0a0)
    at eval.c:3037
#21 0x00000000005562d8 in apply_lambda (fun=53965094, args=<optimised out>, 
    count=count@entry=17) at eval.c:2919
#22 0x000000000055667c in eval_sub (form=<optimised out>) at eval.c:2256
#23 0x0000000000556976 in eval_sub (form=<optimised out>) at eval.c:2131
#24 0x0000000000556ba5 in Fprogn (body=20, body@entry=53945542) at eval.c:462
#25 0x000000000054aa65 in Fsave_current_buffer (args=53945542) at editfns.c:954
#26 0x0000000000556976 in eval_sub (form=<optimised out>) at eval.c:2131
#27 0x0000000000556ba5 in Fprogn (body=20) at eval.c:462
#28 0x0000000000556f3c in funcall_lambda (fun=53945510, nargs=nargs@entry=0, 
    arg_vector=arg_vector@entry=0x7fff3fade5b8) at eval.c:3037
#29 0x00000000005571b3 in Ffuncall (nargs=nargs@entry=1, 
    args=args@entry=0x7fff3fade5b0) at eval.c:2872
#30 0x000000000055861c in Fapply (nargs=2, args=0x7fff3fade5b0) at eval.c:2293
#31 0x0000000000557291 in Ffuncall (nargs=<optimised out>, 
    args=<optimised out>) at eval.c:2792
#32 0x000000000058b655 in exec_byte_code (bytestr=-514, 
    vector=140734261742560, maxdepth=140734261742688, args_template=12140850, 
---Type <return> to continue, or q <return> to quit---
    nargs=140734261749176, args=0x3) at bytecode.c:916
#33 0x0000000000556850 in eval_sub (form=form@entry=10005110) at eval.c:2187
#34 0x0000000000559b59 in internal_lisp_condition_case (var=<optimised out>, 
    bodyform=10005110, handlers=<optimised out>) at eval.c:1317
#35 0x000000000058c61d in exec_byte_code (bytestr=-514, 
    vector=140734261742560, maxdepth=140734261742688, args_template=12140850, 
    nargs=140734261749720, args=0x8f) at bytecode.c:1162
#36 0x0000000000556e3f in funcall_lambda (fun=10004797, nargs=nargs@entry=1, 
    arg_vector=arg_vector@entry=0x7fff3fade988) at eval.c:3044
#37 0x00000000005571b3 in Ffuncall (nargs=nargs@entry=2, 
    args=args@entry=0x7fff3fade980) at eval.c:2872
#38 0x00000000005574fa in call1 (fn=<optimised out>, arg1=arg1@entry=54120877)
    at eval.c:2610
#39 0x00000000004eb2bf in timer_check_2 (idle_timers=<optimised out>, 
    timers=<optimised out>) at keyboard.c:4515
#40 timer_check () at keyboard.c:4582
#41 0x00000000004eb5d1 in readable_events (flags=1) at keyboard.c:3448
#42 0x00000000004ec998 in get_input_pending (flags=1) at keyboard.c:6766
#43 0x00000000004efde4 in detect_input_pending_run_timers (
    do_display=do_display@entry=true) at keyboard.c:9895
#44 0x0000000000595756 in wait_reading_process_output (
    time_limit=time_limit@entry=30, nsecs=nsecs@entry=0, 
    read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true, 
---Type <return> to continue, or q <return> to quit---
    wait_for_cell=12140850, wait_proc=wait_proc@entry=0x0, 
    just_wait_proc=just_wait_proc@entry=0) at process.c:4702
#45 0x0000000000421a54 in sit_for (timeout=<optimised out>, 
    reading=reading@entry=true, display_option=display_option@entry=1)
    at dispnew.c:5867
#46 0x00000000004f0b04 in read_char (commandflag=1, map=map@entry=190228950, 
    prev_event=12140850, used_mouse_menu=used_mouse_menu@entry=0x7fff3fadf1bb, 
    end_time=end_time@entry=0x0) at keyboard.c:2810
#47 0x00000000004f1fdf in read_key_sequence (
    keybuf=keybuf@entry=0x7fff3fadf290, prompt=12140850, 
    dont_downcase_last=dont_downcase_last@entry=false, 
    can_return_switch_frame=can_return_switch_frame@entry=true, 
    fix_current_buffer=fix_current_buffer@entry=true, 
    prevent_redisplay=prevent_redisplay@entry=false, bufsize=30)
    at keyboard.c:9089
#48 0x00000000004f3bd0 in command_loop_1 () at keyboard.c:1453
#49 0x00000000005557ae in internal_condition_case (
    bfun=bfun@entry=0x4f39e0 <command_loop_1>, handlers=<optimised out>, 
    hfun=hfun@entry=0x4ea950 <cmd_error>) at eval.c:1348
#50 0x00000000004e608e in command_loop_2 (ignore=ignore@entry=12140850)
    at keyboard.c:1178
#51 0x00000000005556bb in internal_catch (tag=12188354, 
    func=func@entry=0x4e6070 <command_loop_2>, arg=12140850) at eval.c:1112
---Type <return> to continue, or q <return> to quit---
#52 0x00000000004ea577 in command_loop () at keyboard.c:1157
#53 recursive_edit_1 () at keyboard.c:778
#54 0x00000000004ea88d in Frecursive_edit () at keyboard.c:849
#55 0x0000000000417c95 in main (argc=<optimised out>, argv=0x7fff3fadf5e8)
    at emacs.c:1642
(gdb) continue
Continuing.

^C
Program received signal SIGINT, Interrupt.
0x00007fbb04d6c12d in poll () at ../sysdeps/unix/syscall-template.S:81
81	../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) bt
#0  0x00007fbb04d6c12d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007fbb01850b72 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x00007fbb0185264f in xcb_wait_for_event ()
   from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x00007fbb081b4198 in _XReadEvents ()
   from /usr/lib/x86_64-linux-gnu/libX11.so.6
#4  0x00007fbb0819c751 in XIfEvent ()
   from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5  0x00007fbb081e2f24 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6  0x00007fbb081e3b80 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#7  0x00007fbb081e3e71 in _XimRead ()
   from /usr/lib/x86_64-linux-gnu/libX11.so.6
#8  0x00007fbb081d28a6 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#9  0x00007fbb081c0b3d in XSetICValues ()
   from /usr/lib/x86_64-linux-gnu/libX11.so.6
#10 0x00000000004cbd23 in xic_set_preeditarea (w=w@entry=0x11508e0, 
    x=x@entry=275, y=y@entry=0) at xfns.c:2107
#11 0x00000000004ba975 in x_draw_window_cursor (w=0x11508e0, 
    glyph_row=<optimised out>, x=275, y=0, cursor_type=<optimised out>, 
    cursor_width=<optimised out>, on_p=<optimised out>, 
    active_p=<optimised out>) at xterm.c:7331
#12 0x0000000000457f03 in display_and_set_cursor (w=w@entry=0x11508e0, 
    on=on@entry=true, hpos=25, vpos=0, x=275, y=0) at xdisp.c:27634
---Type <return> to continue, or q <return> to quit---
#13 0x00000000004b968c in x_update_window_end (w=0x11508e0, 
    cursor_on_p=<optimised out>, mouse_face_overwritten_p=<optimised out>)
    at xterm.c:582
#14 0x000000000041d45d in update_window (w=w@entry=0x11508e0, 
    force_p=<optimised out>, force_p@entry=true) at dispnew.c:3541
#15 0x000000000041e72b in update_window_tree (w=0x11508e0, w@entry=0xb5d99a8, 
    force_p=force_p@entry=true) at dispnew.c:3216
#16 0x0000000000420c7d in update_frame (f=f@entry=0x114e878, 
    force_p=<optimised out>, force_p@entry=false, 
    inhibit_hairy_id_p=inhibit_hairy_id_p@entry=false) at dispnew.c:3105
#17 0x000000000044e957 in redisplay_internal () at xdisp.c:13961
#18 0x0000000000450745 in redisplay () at xdisp.c:13201
#19 0x00000000004f0661 in read_char (commandflag=1, map=map@entry=283856358, 
    prev_event=12140850, used_mouse_menu=used_mouse_menu@entry=0x7fff3fade38b, 
    end_time=end_time@entry=0x0) at keyboard.c:2571
#20 0x00000000004f1fdf in read_key_sequence (
    keybuf=keybuf@entry=0x7fff3fade460, prompt=12140850, 
    dont_downcase_last=dont_downcase_last@entry=false, 
    can_return_switch_frame=can_return_switch_frame@entry=true, 
    fix_current_buffer=fix_current_buffer@entry=true, 
    prevent_redisplay=prevent_redisplay@entry=false, bufsize=30)
    at keyboard.c:9089
#21 0x00000000004f3bd0 in command_loop_1 () at keyboard.c:1453
---Type <return> to continue, or q <return> to quit---
#22 0x00000000005557ae in internal_condition_case (
    bfun=bfun@entry=0x4f39e0 <command_loop_1>, handlers=<optimised out>, 
    hfun=hfun@entry=0x4ea950 <cmd_error>) at eval.c:1348
#23 0x00000000004e608e in command_loop_2 (ignore=ignore@entry=12140850)
    at keyboard.c:1178
#24 0x00000000005556bb in internal_catch (tag=12265170, 
    func=func@entry=0x4e6070 <command_loop_2>, arg=12140850) at eval.c:1112
#25 0x00000000004ea503 in command_loop () at keyboard.c:1149
#26 recursive_edit_1 () at keyboard.c:778
#27 0x0000000000512b67 in read_minibuf (map=map@entry=16051638, 
    initial=initial@entry=12140850, prompt=<optimised out>, 
    prompt@entry=279789009, expflag=<optimised out>, 
    histvar=histvar@entry=12305634, histpos=0, defalt=defalt@entry=189286897, 
    allow_props=false, inherit_input_method=false) at minibuf.c:674
#28 0x00000000005131ce in Fread_from_minibuffer (prompt=279789009, 
    initial_contents=12140850, keymap=16051638, read=12140850, 
    hist=<optimised out>, default_value=189286897, 
    inherit_input_method=12140850) at minibuf.c:957
#29 0x0000000000557328 in Ffuncall (nargs=<optimised out>, 
    args=<optimised out>) at eval.c:2837
#30 0x000000000058b655 in exec_byte_code (bytestr=-516, vector=1, 
    maxdepth=4294967295, args_template=8200, nargs=140734261749672, args=0x8)
    at bytecode.c:916
---Type <return> to continue, or q <return> to quit---
#31 0x0000000000556ed7 in funcall_lambda (fun=140734261750496, 
    nargs=nargs@entry=8, arg_vector=0x917141 <pure+882625>, 
    arg_vector@entry=0x7fff3fade918) at eval.c:2978
#32 0x00000000005571b3 in Ffuncall (nargs=nargs@entry=9, 
    args=args@entry=0x7fff3fade910) at eval.c:2872
#33 0x0000000000510c00 in Fcompleting_read (prompt=279789009, 
    collection=88850886, predicate=12140850, require_match=12140850, 
    initial_input=12140850, hist=12140850, def=189286897, 
    inherit_input_method=12140850) at minibuf.c:1674
#34 0x00000000005573f1 in Ffuncall (nargs=<optimised out>, 
    args=<optimised out>) at eval.c:2844
#35 0x000000000058b655 in exec_byte_code (bytestr=-516, vector=1, 
    maxdepth=4294967295, args_template=12140850, nargs=140734261750384, 
    args=0x8) at bytecode.c:916
#36 0x0000000000556e3f in funcall_lambda (fun=186153037, nargs=nargs@entry=0, 
    arg_vector=arg_vector@entry=0x7fff3fadec98) at eval.c:3044
#37 0x00000000005571b3 in Ffuncall (nargs=1, args=0x7fff3fadec90)
    at eval.c:2872
#38 0x0000000000557449 in funcall_nil (nargs=<optimised out>, 
    args=<optimised out>) at eval.c:2362
#39 0x0000000000555c6d in run_hook_with_args (nargs=1, args=0x7fff3fadec90, 
    funcall=0x557440 <funcall_nil>) at eval.c:2547
#40 0x0000000000555d96 in Frun_hooks (nargs=1, args=0x7fff3faded40)
---Type <return> to continue, or q <return> to quit---
    at eval.c:2389
#41 0x0000000000557291 in Ffuncall (nargs=<optimised out>, 
    args=<optimised out>) at eval.c:2792
#42 0x000000000058b655 in exec_byte_code (bytestr=-516, vector=1, 
    maxdepth=4294967295, args_template=12140850, nargs=140734261751088, 
    args=0x2) at bytecode.c:916
#43 0x0000000000556e3f in funcall_lambda (fun=187962589, nargs=nargs@entry=1, 
    arg_vector=arg_vector@entry=0x7fff3fadef28) at eval.c:3044
#44 0x00000000005571b3 in Ffuncall (nargs=nargs@entry=2, 
    args=args@entry=0x7fff3fadef20) at eval.c:2872
#45 0x0000000000553740 in Fcall_interactively (function=<optimised out>, 
    record_flag=<optimised out>, keys=<optimised out>) at callint.c:836
#46 0x0000000000557390 in Ffuncall (nargs=<optimised out>, 
    args=<optimised out>) at eval.c:2818
#47 0x000000000058b655 in exec_byte_code (bytestr=-516, vector=1, 
    maxdepth=4294967295, args_template=4100, nargs=140734261752048, args=0x4)
    at bytecode.c:916
#48 0x0000000000556ed7 in funcall_lambda (fun=0, nargs=nargs@entry=1, 
    arg_vector=0x91f9d9 <pure+917593>, arg_vector@entry=0x7fff3fadf248)
    at eval.c:2978
#49 0x00000000005571b3 in Ffuncall (nargs=nargs@entry=2, 
    args=args@entry=0x7fff3fadf240) at eval.c:2872
#50 0x00000000005574fa in call1 (fn=<optimised out>, arg1=<optimised out>)
---Type <return> to continue, or q <return> to quit---
    at eval.c:2610
#51 0x00000000004f3d6d in command_loop_1 () at keyboard.c:1560
#52 0x00000000005557ae in internal_condition_case (
    bfun=bfun@entry=0x4f39e0 <command_loop_1>, handlers=<optimised out>, 
    hfun=hfun@entry=0x4ea950 <cmd_error>) at eval.c:1348
#53 0x00000000004e608e in command_loop_2 (ignore=ignore@entry=12140850)
    at keyboard.c:1178
#54 0x00000000005556bb in internal_catch (tag=12188354, 
    func=func@entry=0x4e6070 <command_loop_2>, arg=12140850) at eval.c:1112
#55 0x00000000004ea577 in command_loop () at keyboard.c:1157
#56 recursive_edit_1 () at keyboard.c:778
#57 0x00000000004ea88d in Frecursive_edit () at keyboard.c:849
#58 0x0000000000417c95 in main (argc=<optimised out>, argv=0x7fff3fadf5e8)
    at emacs.c:1642
(gdb) continue
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x00007fbb04d6c12d in poll () at ../sysdeps/unix/syscall-template.S:81
81	in ../sysdeps/unix/syscall-template.S
(gdb) bt
#0  0x00007fbb04d6c12d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007fbb01850b72 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x00007fbb0185264f in xcb_wait_for_event ()
   from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x00007fbb081b4198 in _XReadEvents ()
   from /usr/lib/x86_64-linux-gnu/libX11.so.6
#4  0x00007fbb0819c751 in XIfEvent ()
   from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5  0x00007fbb081e2f24 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6  0x00007fbb081e3b80 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#7  0x00007fbb081e3e71 in _XimRead ()
   from /usr/lib/x86_64-linux-gnu/libX11.so.6
#8  0x00007fbb081d28a6 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#9  0x00007fbb081c0b3d in XSetICValues ()
   from /usr/lib/x86_64-linux-gnu/libX11.so.6
#10 0x00000000004cbd23 in xic_set_preeditarea (w=w@entry=0x11508e0, 
    x=x@entry=275, y=y@entry=0) at xfns.c:2107
#11 0x00000000004ba975 in x_draw_window_cursor (w=0x11508e0, 
    glyph_row=<optimised out>, x=275, y=0, cursor_type=<optimised out>, 
    cursor_width=<optimised out>, on_p=<optimised out>, 
    active_p=<optimised out>) at xterm.c:7331
#12 0x0000000000457f03 in display_and_set_cursor (w=w@entry=0x11508e0, 
    on=on@entry=true, hpos=25, vpos=0, x=275, y=0) at xdisp.c:27634
---Type <return> to continue, or q <return> to quit---
#13 0x00000000004b968c in x_update_window_end (w=0x11508e0, 
    cursor_on_p=<optimised out>, mouse_face_overwritten_p=<optimised out>)
    at xterm.c:582
#14 0x000000000041d45d in update_window (w=w@entry=0x11508e0, 
    force_p=<optimised out>, force_p@entry=true) at dispnew.c:3541
#15 0x000000000041e72b in update_window_tree (w=0x11508e0, w@entry=0xb5d99a8, 
    force_p=force_p@entry=true) at dispnew.c:3216
#16 0x0000000000420c7d in update_frame (f=f@entry=0x114e878, 
    force_p=<optimised out>, force_p@entry=false, 
    inhibit_hairy_id_p=inhibit_hairy_id_p@entry=false) at dispnew.c:3105
#17 0x000000000044e957 in redisplay_internal () at xdisp.c:13961
#18 0x0000000000450745 in redisplay () at xdisp.c:13201
#19 0x00000000004f0661 in read_char (commandflag=1, map=map@entry=283856358, 
    prev_event=12140850, used_mouse_menu=used_mouse_menu@entry=0x7fff3fade38b, 
    end_time=end_time@entry=0x0) at keyboard.c:2571
#20 0x00000000004f1fdf in read_key_sequence (
    keybuf=keybuf@entry=0x7fff3fade460, prompt=12140850, 
    dont_downcase_last=dont_downcase_last@entry=false, 
    can_return_switch_frame=can_return_switch_frame@entry=true, 
    fix_current_buffer=fix_current_buffer@entry=true, 
    prevent_redisplay=prevent_redisplay@entry=false, bufsize=30)
    at keyboard.c:9089
#21 0x00000000004f3bd0 in command_loop_1 () at keyboard.c:1453
---Type <return> to continue, or q <return> to quit---
#22 0x00000000005557ae in internal_condition_case (
    bfun=bfun@entry=0x4f39e0 <command_loop_1>, handlers=<optimised out>, 
    hfun=hfun@entry=0x4ea950 <cmd_error>) at eval.c:1348
#23 0x00000000004e608e in command_loop_2 (ignore=ignore@entry=12140850)
    at keyboard.c:1178
#24 0x00000000005556bb in internal_catch (tag=12265170, 
    func=func@entry=0x4e6070 <command_loop_2>, arg=12140850) at eval.c:1112
#25 0x00000000004ea503 in command_loop () at keyboard.c:1149
#26 recursive_edit_1 () at keyboard.c:778
#27 0x0000000000512b67 in read_minibuf (map=map@entry=16051638, 
    initial=initial@entry=12140850, prompt=<optimised out>, 
    prompt@entry=279789009, expflag=<optimised out>, 
    histvar=histvar@entry=12305634, histpos=0, defalt=defalt@entry=189286897, 
    allow_props=false, inherit_input_method=false) at minibuf.c:674
#28 0x00000000005131ce in Fread_from_minibuffer (prompt=279789009, 
    initial_contents=12140850, keymap=16051638, read=12140850, 
    hist=<optimised out>, default_value=189286897, 
    inherit_input_method=12140850) at minibuf.c:957
#29 0x0000000000557328 in Ffuncall (nargs=<optimised out>, 
    args=<optimised out>) at eval.c:2837
#30 0x000000000058b655 in exec_byte_code (bytestr=-516, vector=1, 
    maxdepth=4294967295, args_template=8200, nargs=140734261749672, args=0x8)
    at bytecode.c:916
---Type <return> to continue, or q <return> to quit---
#31 0x0000000000556ed7 in funcall_lambda (fun=140734261750496, 
    nargs=nargs@entry=8, arg_vector=0x917141 <pure+882625>, 
    arg_vector@entry=0x7fff3fade918) at eval.c:2978
#32 0x00000000005571b3 in Ffuncall (nargs=nargs@entry=9, 
    args=args@entry=0x7fff3fade910) at eval.c:2872
#33 0x0000000000510c00 in Fcompleting_read (prompt=279789009, 
    collection=88850886, predicate=12140850, require_match=12140850, 
    initial_input=12140850, hist=12140850, def=189286897, 
    inherit_input_method=12140850) at minibuf.c:1674
#34 0x00000000005573f1 in Ffuncall (nargs=<optimised out>, 
    args=<optimised out>) at eval.c:2844
#35 0x000000000058b655 in exec_byte_code (bytestr=-516, vector=1, 
    maxdepth=4294967295, args_template=12140850, nargs=140734261750384, 
    args=0x8) at bytecode.c:916
#36 0x0000000000556e3f in funcall_lambda (fun=186153037, nargs=nargs@entry=0, 
    arg_vector=arg_vector@entry=0x7fff3fadec98) at eval.c:3044
#37 0x00000000005571b3 in Ffuncall (nargs=1, args=0x7fff3fadec90)
    at eval.c:2872
#38 0x0000000000557449 in funcall_nil (nargs=<optimised out>, 
    args=<optimised out>) at eval.c:2362
#39 0x0000000000555c6d in run_hook_with_args (nargs=1, args=0x7fff3fadec90, 
    funcall=0x557440 <funcall_nil>) at eval.c:2547
#40 0x0000000000555d96 in Frun_hooks (nargs=1, args=0x7fff3faded40)
---Type <return> to continue, or q <return> to quit---
    at eval.c:2389
#41 0x0000000000557291 in Ffuncall (nargs=<optimised out>, 
    args=<optimised out>) at eval.c:2792
#42 0x000000000058b655 in exec_byte_code (bytestr=-516, vector=1, 
    maxdepth=4294967295, args_template=12140850, nargs=140734261751088, 
    args=0x2) at bytecode.c:916
#43 0x0000000000556e3f in funcall_lambda (fun=187962589, nargs=nargs@entry=1, 
    arg_vector=arg_vector@entry=0x7fff3fadef28) at eval.c:3044
#44 0x00000000005571b3 in Ffuncall (nargs=nargs@entry=2, 
    args=args@entry=0x7fff3fadef20) at eval.c:2872
#45 0x0000000000553740 in Fcall_interactively (function=<optimised out>, 
    record_flag=<optimised out>, keys=<optimised out>) at callint.c:836
#46 0x0000000000557390 in Ffuncall (nargs=<optimised out>, 
    args=<optimised out>) at eval.c:2818
#47 0x000000000058b655 in exec_byte_code (bytestr=-516, vector=1, 
    maxdepth=4294967295, args_template=4100, nargs=140734261752048, args=0x4)
    at bytecode.c:916
#48 0x0000000000556ed7 in funcall_lambda (fun=0, nargs=nargs@entry=1, 
    arg_vector=0x91f9d9 <pure+917593>, arg_vector@entry=0x7fff3fadf248)
    at eval.c:2978
#49 0x00000000005571b3 in Ffuncall (nargs=nargs@entry=2, 
    args=args@entry=0x7fff3fadf240) at eval.c:2872
#50 0x00000000005574fa in call1 (fn=<optimised out>, arg1=<optimised out>)
---Type <return> to continue, or q <return> to quit---
    at eval.c:2610
#51 0x00000000004f3d6d in command_loop_1 () at keyboard.c:1560
#52 0x00000000005557ae in internal_condition_case (
    bfun=bfun@entry=0x4f39e0 <command_loop_1>, handlers=<optimised out>, 
    hfun=hfun@entry=0x4ea950 <cmd_error>) at eval.c:1348
#53 0x00000000004e608e in command_loop_2 (ignore=ignore@entry=12140850)
    at keyboard.c:1178
#54 0x00000000005556bb in internal_catch (tag=12188354, 
    func=func@entry=0x4e6070 <command_loop_2>, arg=12140850) at eval.c:1112
#55 0x00000000004ea577 in command_loop () at keyboard.c:1157
#56 recursive_edit_1 () at keyboard.c:778
#57 0x00000000004ea88d in Frecursive_edit () at keyboard.c:849
#58 0x0000000000417c95 in main (argc=<optimised out>, argv=0x7fff3fadf5e8)
    at emacs.c:1642
(gdb) 
Continuing.

Program received signal SIGTERM, Terminated.
0x00007fbb0819c709 in XIfEvent () from /usr/lib/x86_64-linux-gnu/libX11.so.6
(gdb) 

Re: Emacs Slowdown

[Stefan Monnier]

> Apologies if I have not done the right thing here -- I've not written
> much C nor used gdb before.

Looks useful, thank you.  AFAICT in all those backtraces, Emacs is not
"busy" but it is simply waiting for input (a process monitor such as
"top" should be able to confirm that the Emacs process is not using any
significant amount of CPU at those times).

When Emacs feels slow, what happens if you keep typing without waiting
for Emacs's response?

> The last two backtraces are after it
> has become non-responsive, up till the kill.

The last two backtraces are actually different: Emacs is also waiting
but it's doing so elsewhere at a spot I find weird (it's actually inside
an X11 library call waiting for some input event (in "XimRead" the "im"
stands for "input method"), while in the middle of redrawing part of
Emacs's display).  I'm not sufficiently familiar with this code to go
much further with it, so please M-x report-emacs-bug and include the
last backtrace (the last 2 are identical, AFAICT).


        Stefan

Re: Emacs Slowdown

[Phillip Lord]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Apologies if I have not done the right thing here -- I've not written
>> much C nor used gdb before.
>
> Looks useful, thank you.  AFAICT in all those backtraces, Emacs is not
> "busy" but it is simply waiting for input (a process monitor such as
> "top" should be able to confirm that the Emacs process is not using any
> significant amount of CPU at those times).

Oh, sorry, forgot to mention that. Indeed, emacs is not chewing up the
CPU, nor memory. I didn't think to check iotop. I can do that if needed.


> When Emacs feels slow, what happens if you keep typing without waiting
> for Emacs's response?

It catches up eventually. It *seems* to get some keystrokes garbled
(i.e. in the wrong order) although typing without visual feedback is
fairly hard work, so I might just be hitting the wrong keys.

This is up to the point that it dies -- then it seems to really hang
(repaint stops for instance). I've let it alone for several minutes and
get not keypresses at all.



>
>> The last two backtraces are after it
>> has become non-responsive, up till the kill.
>
> The last two backtraces are actually different: Emacs is also waiting
> but it's doing so elsewhere at a spot I find weird (it's actually inside
> an X11 library call waiting for some input event (in "XimRead" the "im"
> stands for "input method"), while in the middle of redrawing part of
> Emacs's display).  I'm not sufficiently familiar with this code to go
> much further with it, so please M-x report-emacs-bug and include the
> last backtrace (the last 2 are identical, AFAICT).
>

Okay, I will do so!


Phil

Re: Emacs Slowdown

[Stefan Monnier]

>> When Emacs feels slow, what happens if you keep typing without waiting
>> for Emacs's response?
> It catches up eventually.

Hmm... so providing input doesn't actually "wake it up": sometimes,
I introduced bugs which caused Emacs to redisplay just before the next
command rather than right after a command, which made it look like
Emacs was terribly slow, even tho it was just that the screen update
was happening at the wrong time.
But It looks like your situation is not one of those.


        Stefan

Re: Emacs Slowdown

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 18 Mar 2015 08:44:14 -0400
> 
> The last two backtraces are actually different: Emacs is also waiting
> but it's doing so elsewhere at a spot I find weird (it's actually inside
> an X11 library call waiting for some input event (in "XimRead" the "im"
> stands for "input method"), while in the middle of redrawing part of
> Emacs's display).  I'm not sufficiently familiar with this code to go
> much further with it, so please M-x report-emacs-bug and include the
> last backtrace (the last 2 are identical, AFAICT).

I think the last two backtraces look very similar to bug#20036, which
see.

Re: Emacs Slowdown

[Phillip Lord]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> When Emacs feels slow, what happens if you keep typing without waiting
>>> for Emacs's response?
>> It catches up eventually.
>
> Hmm... so providing input doesn't actually "wake it up": sometimes,
> I introduced bugs which caused Emacs to redisplay just before the next
> command rather than right after a command, which made it look like
> Emacs was terribly slow, even tho it was just that the screen update
> was happening at the wrong time.
> But It looks like your situation is not one of those.

I think not. I'm trying out with older versions of Emacs to see whether
the problem is recent.

Phil

Re: Emacs Slowdown

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Wed, 18 Mar 2015 08:44:14 -0400
>> 
>> The last two backtraces are actually different: Emacs is also waiting
>> but it's doing so elsewhere at a spot I find weird (it's actually inside
>> an X11 library call waiting for some input event (in "XimRead" the "im"
>> stands for "input method"), while in the middle of redrawing part of
>> Emacs's display).  I'm not sufficiently familiar with this code to go
>> much further with it, so please M-x report-emacs-bug and include the
>> last backtrace (the last 2 are identical, AFAICT).
>
> I think the last two backtraces look very similar to bug#20036, which
> see.


Not auctex related in those cases. I will try and see if it is version
specific, and building from a 24.4 tar ball, rather than the git build I
am on at the moment.

Thanks!