* Emacs Slowdown
@ 2015-03-09 11:48 Phillip Lord
2015-03-09 16:16 ` Eli Zaretskii
` (2 more replies)
0 siblings, 3 replies; 19+ messages in thread
From: Phillip Lord @ 2015-03-09 11:48 UTC (permalink / raw)
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Emacs Slowdown
2015-03-09 11:48 Emacs Slowdown Phillip Lord
@ 2015-03-09 16:16 ` Eli Zaretskii
2015-03-09 21:50 ` Stefan Monnier
2015-03-10 12:37 ` Phillip Lord
2015-03-09 21:59 ` Stefan Monnier
2015-03-12 11:36 ` Phillip Lord
2 siblings, 2 replies; 19+ messages in thread
From: Eli Zaretskii @ 2015-03-09 16:16 UTC (permalink / raw)
To: help-gnu-emacs
> 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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Emacs Slowdown
2015-03-09 16:16 ` Eli Zaretskii
@ 2015-03-09 21:50 ` Stefan Monnier
2015-03-10 12:37 ` Phillip Lord
1 sibling, 0 replies; 19+ messages in thread
From: Stefan Monnier @ 2015-03-09 21:50 UTC (permalink / raw)
To: help-gnu-emacs
> 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Emacs Slowdown
2015-03-09 11:48 Emacs Slowdown Phillip Lord
2015-03-09 16:16 ` Eli Zaretskii
@ 2015-03-09 21:59 ` Stefan Monnier
2015-03-10 12:39 ` Phillip Lord
2015-03-12 11:36 ` Phillip Lord
2 siblings, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2015-03-09 21:59 UTC (permalink / raw)
To: help-gnu-emacs
> 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Emacs Slowdown
2015-03-09 16:16 ` Eli Zaretskii
2015-03-09 21:50 ` Stefan Monnier
@ 2015-03-10 12:37 ` Phillip Lord
2015-03-10 19:00 ` Eli Zaretskii
1 sibling, 1 reply; 19+ messages in thread
From: Phillip Lord @ 2015-03-10 12:37 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Emacs Slowdown
2015-03-09 21:59 ` Stefan Monnier
@ 2015-03-10 12:39 ` Phillip Lord
2015-03-10 13:22 ` Stefan Monnier
0 siblings, 1 reply; 19+ messages in thread
From: Phillip Lord @ 2015-03-10 12:39 UTC (permalink / raw)
To: Stefan Monnier; +Cc: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Emacs Slowdown
2015-03-10 12:39 ` Phillip Lord
@ 2015-03-10 13:22 ` Stefan Monnier
0 siblings, 0 replies; 19+ messages in thread
From: Stefan Monnier @ 2015-03-10 13:22 UTC (permalink / raw)
To: help-gnu-emacs
> 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Emacs Slowdown
2015-03-10 12:37 ` Phillip Lord
@ 2015-03-10 19:00 ` Eli Zaretskii
0 siblings, 0 replies; 19+ messages in thread
From: Eli Zaretskii @ 2015-03-10 19:00 UTC (permalink / raw)
To: help-gnu-emacs
> 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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Emacs Slowdown
2015-03-09 11:48 Emacs Slowdown Phillip Lord
2015-03-09 16:16 ` Eli Zaretskii
2015-03-09 21:59 ` Stefan Monnier
@ 2015-03-12 11:36 ` Phillip Lord
2015-03-16 11:41 ` Phillip Lord
2 siblings, 1 reply; 19+ messages in thread
From: Phillip Lord @ 2015-03-12 11:36 UTC (permalink / raw)
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Emacs Slowdown
2015-03-12 11:36 ` Phillip Lord
@ 2015-03-16 11:41 ` Phillip Lord
2015-03-16 12:36 ` Stefan Monnier
0 siblings, 1 reply; 19+ messages in thread
From: Phillip Lord @ 2015-03-16 11:41 UTC (permalink / raw)
To: help-gnu-emacs
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%
- ...
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Emacs Slowdown
2015-03-16 11:41 ` Phillip Lord
@ 2015-03-16 12:36 ` Stefan Monnier
2015-03-16 16:51 ` Phillip Lord
0 siblings, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2015-03-16 12:36 UTC (permalink / raw)
To: help-gnu-emacs
> 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Emacs Slowdown
2015-03-16 12:36 ` Stefan Monnier
@ 2015-03-16 16:51 ` Phillip Lord
2015-03-18 12:23 ` Phillip Lord
0 siblings, 1 reply; 19+ messages in thread
From: Phillip Lord @ 2015-03-16 16:51 UTC (permalink / raw)
To: Stefan Monnier; +Cc: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Emacs Slowdown
2015-03-16 16:51 ` Phillip Lord
@ 2015-03-18 12:23 ` Phillip Lord
2015-03-18 12:44 ` Stefan Monnier
0 siblings, 1 reply; 19+ messages in thread
From: Phillip Lord @ 2015-03-18 12:23 UTC (permalink / raw)
To: help-gnu-emacs
[-- 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)
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Emacs Slowdown
2015-03-18 12:23 ` Phillip Lord
@ 2015-03-18 12:44 ` Stefan Monnier
2015-03-18 14:13 ` Phillip Lord
2015-03-18 16:32 ` Eli Zaretskii
0 siblings, 2 replies; 19+ messages in thread
From: Stefan Monnier @ 2015-03-18 12:44 UTC (permalink / raw)
To: help-gnu-emacs
> 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Emacs Slowdown
2015-03-18 12:44 ` Stefan Monnier
@ 2015-03-18 14:13 ` Phillip Lord
2015-03-18 14:53 ` Stefan Monnier
2015-03-18 16:32 ` Eli Zaretskii
1 sibling, 1 reply; 19+ messages in thread
From: Phillip Lord @ 2015-03-18 14:13 UTC (permalink / raw)
To: Stefan Monnier; +Cc: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Emacs Slowdown
2015-03-18 14:13 ` Phillip Lord
@ 2015-03-18 14:53 ` Stefan Monnier
2015-03-18 16:34 ` Phillip Lord
0 siblings, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2015-03-18 14:53 UTC (permalink / raw)
To: Phillip Lord; +Cc: help-gnu-emacs
>> 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Emacs Slowdown
2015-03-18 12:44 ` Stefan Monnier
2015-03-18 14:13 ` Phillip Lord
@ 2015-03-18 16:32 ` Eli Zaretskii
2015-03-18 17:04 ` Phillip Lord
1 sibling, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2015-03-18 16:32 UTC (permalink / raw)
To: help-gnu-emacs
> 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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Emacs Slowdown
2015-03-18 14:53 ` Stefan Monnier
@ 2015-03-18 16:34 ` Phillip Lord
0 siblings, 0 replies; 19+ messages in thread
From: Phillip Lord @ 2015-03-18 16:34 UTC (permalink / raw)
To: Stefan Monnier; +Cc: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Emacs Slowdown
2015-03-18 16:32 ` Eli Zaretskii
@ 2015-03-18 17:04 ` Phillip Lord
0 siblings, 0 replies; 19+ messages in thread
From: Phillip Lord @ 2015-03-18 17:04 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: help-gnu-emacs
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!
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2015-03-18 17:04 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-03-09 11:48 Emacs Slowdown Phillip Lord
2015-03-09 16:16 ` Eli Zaretskii
2015-03-09 21:50 ` Stefan Monnier
2015-03-10 12:37 ` Phillip Lord
2015-03-10 19:00 ` Eli Zaretskii
2015-03-09 21:59 ` Stefan Monnier
2015-03-10 12:39 ` Phillip Lord
2015-03-10 13:22 ` Stefan Monnier
2015-03-12 11:36 ` Phillip Lord
2015-03-16 11:41 ` Phillip Lord
2015-03-16 12:36 ` Stefan Monnier
2015-03-16 16:51 ` Phillip Lord
2015-03-18 12:23 ` Phillip Lord
2015-03-18 12:44 ` Stefan Monnier
2015-03-18 14:13 ` Phillip Lord
2015-03-18 14:53 ` Stefan Monnier
2015-03-18 16:34 ` Phillip Lord
2015-03-18 16:32 ` Eli Zaretskii
2015-03-18 17:04 ` Phillip Lord
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).