* bug#16995: 24.3; CPU usage spikes to 100% for minutes at a time
@ 2014-03-12 7:08 Andrew Beekhof
2014-03-12 8:13 ` Michael Heerdegen
2014-03-12 16:17 ` Eli Zaretskii
0 siblings, 2 replies; 13+ messages in thread
From: Andrew Beekhof @ 2014-03-12 7:08 UTC (permalink / raw)
To: 16995
[-- Attachment #1: Type: text/plain, Size: 24738 bytes --]
# Please describe exactly what actions triggered the bug, and
# the precise symptoms of the bug. If you can, give a recipe
# starting from `emacs -Q':
I've been editing lots of python files in the last few days and noticed
that Emacs has begun locking up for minutes at a time, for no apparent
reason.
Example actions that can trigger the problem C-s (isearch-forward),
pressing 'y' in response to query-replace prompts, typing, etc.
Whether the buffer is saved or not makes no difference.
The only thing that really seems to help is switching back to a .c file.
Is this a known problem?
Example top output:
top - 17:44:11 up 29 days, 22:26, 3 users, load average: 0.44, 0.50, 0.42
Tasks: 236 total, 2 running, 233 sleeping, 0 stopped, 1 zombie
%Cpu(s): 12.6 us, 0.1 sy, 0.0 ni, 87.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 7871472 total, 7538448 used, 333024 free, 305676 buffers
KiB Swap: 6029308 total, 731032 used, 5298276 free, 2390156 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22971 beekhof 20 0 644976 49236 16308 R 100.1 0.6 19:33.79 emacs
26689 root 20 0 53020 272 176 S 0.7 0.0 308:17.91 plymouthd
A random blog suggested the following command might show something of
interest. All I can tell is that thread 1 is quite deep.
# echo 't a a where' > gdb.cmd; gdb /usr/bin/emacs -p 22971 -x gdb.cmd 2>&1 </dev/null | tee /tmp/emacs.crash.backtrace
GNU gdb (GDB) Fedora 7.6.50.20130731-19.fc20
[snip]
Loaded symbols for /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so
mark_object (arg=<optimized out>) at /usr/src/debug/emacs-24.3/src/alloc.c:5801
5801 register struct Lisp_Symbol *ptr = XSYMBOL (obj);
Traceback (most recent call last):
File "/usr/share/gdb/auto-load/usr/lib64/libgobject-2.0.so.0.3800.2-gdb.py", line 9, in <module>
from gobject import register
File "/usr/share/glib-2.0/gdb/gobject.py", line 3, in <module>
import gdb.backtrace
ImportError: No module named backtrace
Thread 3 (Thread 0x7f9469b4e700 (LWP 22983)):
#0 0x0000003cbb4ea9dd in poll () at ../sysdeps/unix/syscall-template.S:81
#1 0x0000003cbe0495b4 in g_main_context_poll (priority=2147483647, n_fds=1,
fds=0x7f94640010e0, timeout=-1, context=0xca2e00) at gmain.c:4007
#2 g_main_context_iterate (context=context@entry=0xca2e00,
block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
at gmain.c:3708
#3 0x0000003cbe0496dc in g_main_context_iteration (context=0xca2e00,
may_block=1) at gmain.c:3774
#4 0x00007f9469b55b7d in dconf_gdbus_worker_thread ()
from /usr/lib64/gio/modules/libdconfsettings.so
#5 0x0000003cbe06ea45 in g_thread_proxy (data=0xc8ee30) at gthread.c:798
#6 0x0000003cbbc07f33 in start_thread (arg=0x7f9469b4e700)
at pthread_create.c:309
#7 0x0000003cbb4f4ded in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
Thread 2 (Thread 0x7f946934d700 (LWP 22985)):
#0 0x0000003cbb4ea9dd in poll () at ../sysdeps/unix/syscall-template.S:81
#1 0x0000003cbe0495b4 in g_main_context_poll (priority=2147483647, n_fds=3,
fds=0x7f945c0010c0, timeout=-1, context=0x7f946400dc90) at gmain.c:4007
#2 g_main_context_iterate (context=0x7f946400dc90, block=block@entry=1,
dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3708
#3 0x0000003cbe049a3a in g_main_loop_run (loop=0x7f9464010fc0) at gmain.c:3907
#4 0x0000003cbf0d0376 in gdbus_shared_thread_func (user_data=0x7f94640107d0)
at gdbusprivate.c:278
#5 0x0000003cbe06ea45 in g_thread_proxy (data=0xddc2d0) at gthread.c:798
#6 0x0000003cbbc07f33 in start_thread (arg=0x7f946934d700)
at pthread_create.c:309
#7 0x0000003cbb4f4ded in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
Thread 1 (Thread 0x7f9470966ac0 (LWP 22971)):
#0 mark_object (arg=<optimized out>)
at /usr/src/debug/emacs-24.3/src/alloc.c:5801
#1 0x000000000053ab54 in mark_object (arg=<optimized out>)
at /usr/src/debug/emacs-24.3/src/alloc.c:5914
#2 0x000000000053ab54 in mark_object (arg=<optimized out>)
at /usr/src/debug/emacs-24.3/src/alloc.c:5914
#3 0x000000000053b3c4 in Fgarbage_collect ()
at /usr/src/debug/emacs-24.3/src/alloc.c:5185
#4 0x0000000000552143 in maybe_gc ()
at /usr/src/debug/emacs-24.3/src/lisp.h:3716
#5 eval_sub (form=form@entry=75972854)
at /usr/src/debug/emacs-24.3/src/eval.c:2039
#6 0x0000000000555828 in internal_lisp_condition_case (var=<optimized out>,
bodyform=75972854, handlers=75972758)
at /usr/src/debug/emacs-24.3/src/eval.c:1243
#7 0x0000000000589018 in exec_byte_code (bytestr=8618752, vector=2833333,
maxdepth=137, args_template=4611686018430533632,
nargs=4611686018695757824, args=0x7fff3c2062c8)
at /usr/src/debug/emacs-24.3/src/bytecode.c:1096
#8 0x000000000055296d in funcall_lambda (fun=9899117, nargs=nargs@entry=0,
arg_vector=0x970c49 <pure+1280329>, arg_vector@entry=0x7fff3c206470)
at /usr/src/debug/emacs-24.3/src/eval.c:2944
#9 0x0000000000552e9b in Ffuncall (nargs=1, args=0x7fff3c206468)
at /usr/src/debug/emacs-24.3/src/eval.c:2839
#10 0x000000000058846b in exec_byte_code (bytestr=8618752, vector=2833333,
maxdepth=137, args_template=4611686018430533632,
nargs=4611686018695757824, args=0x0)
at /usr/src/debug/emacs-24.3/src/bytecode.c:900
#11 0x0000000000552b8f in funcall_lambda (fun=56922965, nargs=nargs@entry=1,
arg_vector=arg_vector@entry=0x7fff3c206630)
at /usr/src/debug/emacs-24.3/src/eval.c:3010
#12 0x0000000000552e9b in Ffuncall (nargs=2, args=0x7fff3c206628)
at /usr/src/debug/emacs-24.3/src/eval.c:2839
#13 0x000000000058846b in exec_byte_code (bytestr=8618752, vector=2833333,
maxdepth=137, args_template=4611686018430533632,
nargs=4611686018695757824, args=0x7fff3c206620)
at /usr/src/debug/emacs-24.3/src/bytecode.c:900
#14 0x0000000000552b8f in funcall_lambda (fun=66746821, nargs=nargs@entry=0,
arg_vector=arg_vector@entry=0x7fff3c2067f0)
at /usr/src/debug/emacs-24.3/src/eval.c:3010
#15 0x0000000000552e9b in Ffuncall (nargs=1, args=0x7fff3c2067e8)
at /usr/src/debug/emacs-24.3/src/eval.c:2839
#16 0x000000000058846b in exec_byte_code (bytestr=8618752, vector=2833333,
maxdepth=137, args_template=4611686018430533632,
nargs=4611686018695757824, args=0x7fff3c2067e0)
at /usr/src/debug/emacs-24.3/src/bytecode.c:900
#17 0x0000000000552b8f in funcall_lambda (fun=71257589, nargs=nargs@entry=0,
arg_vector=arg_vector@entry=0x7fff3c2069b0)
at /usr/src/debug/emacs-24.3/src/eval.c:3010
#18 0x0000000000552e9b in Ffuncall (nargs=1, args=0x7fff3c2069a8)
at /usr/src/debug/emacs-24.3/src/eval.c:2839
#19 0x000000000058846b in exec_byte_code (bytestr=8618752, vector=2833333,
maxdepth=137, args_template=4611686018430533632,
nargs=4611686018695757824, args=0x7fff3c2069a0)
at /usr/src/debug/emacs-24.3/src/bytecode.c:900
#20 0x0000000000552b8f in funcall_lambda (fun=66026605, nargs=nargs@entry=1,
arg_vector=arg_vector@entry=0x7fff3c206b80)
at /usr/src/debug/emacs-24.3/src/eval.c:3010
#21 0x0000000000552e9b in Ffuncall (nargs=2, args=0x7fff3c206b78)
at /usr/src/debug/emacs-24.3/src/eval.c:2839
#22 0x000000000058846b in exec_byte_code (bytestr=8618752, vector=2833333,
maxdepth=137, args_template=4611686018430533632,
nargs=4611686018695757824, args=0x7fff3c206b70)
at /usr/src/debug/emacs-24.3/src/bytecode.c:900
#23 0x0000000000552b8f in funcall_lambda (fun=66026397, nargs=nargs@entry=0,
arg_vector=arg_vector@entry=0x7fff3c206d40)
at /usr/src/debug/emacs-24.3/src/eval.c:3010
#24 0x0000000000552e9b in Ffuncall (nargs=1, args=0x7fff3c206d38)
at /usr/src/debug/emacs-24.3/src/eval.c:2839
#25 0x000000000058846b in exec_byte_code (bytestr=8618752, vector=2833333,
maxdepth=137, args_template=4611686018430533632,
nargs=4611686018695757824, args=0x7fff3c206d30)
at /usr/src/debug/emacs-24.3/src/bytecode.c:900
#26 0x0000000000552b8f in funcall_lambda (fun=66378405, nargs=nargs@entry=1,
arg_vector=arg_vector@entry=0x7fff3c206f10)
at /usr/src/debug/emacs-24.3/src/eval.c:3010
#27 0x0000000000552e9b in Ffuncall (nargs=2, args=0x7fff3c206f08)
at /usr/src/debug/emacs-24.3/src/eval.c:2839
#28 0x000000000058846b in exec_byte_code (bytestr=8618752, vector=2833333,
maxdepth=137, args_template=4611686018430533632,
nargs=4611686018695757824, args=0x7fff3c206f00)
at /usr/src/debug/emacs-24.3/src/bytecode.c:900
#29 0x0000000000552b8f in funcall_lambda (fun=66378573, nargs=nargs@entry=1,
arg_vector=arg_vector@entry=0x7fff3c2070d0)
at /usr/src/debug/emacs-24.3/src/eval.c:3010
#30 0x0000000000552e9b in Ffuncall (nargs=2, args=0x7fff3c2070c8)
at /usr/src/debug/emacs-24.3/src/eval.c:2839
#31 0x000000000058846b in exec_byte_code (bytestr=8618752, vector=2833333,
maxdepth=137, args_template=4611686018430533632,
nargs=4611686018695757824, args=0x0)
at /usr/src/debug/emacs-24.3/src/bytecode.c:900
#32 0x0000000000552545 in eval_sub (form=form@entry=67860310)
at /usr/src/debug/emacs-24.3/src/eval.c:2149
#33 0x0000000000551341 in internal_catch (tag=<optimized out>,
func=0x552080 <eval_sub>, arg=67860310)
at /usr/src/debug/emacs-24.3/src/eval.c:1060
#34 0x0000000000588bf9 in exec_byte_code (bytestr=8618752, vector=2833333,
maxdepth=137, args_template=4611686018430533632,
nargs=4611686018695757824, args=0x7fff3c2073d8)
at /usr/src/debug/emacs-24.3/src/bytecode.c:1081
#35 0x0000000000552b8f in funcall_lambda (fun=66745701, nargs=nargs@entry=0,
arg_vector=arg_vector@entry=0x7fff3c2076a8)
at /usr/src/debug/emacs-24.3/src/eval.c:3010
#36 0x0000000000552e9b in Ffuncall (nargs=1, args=0x7fff3c2076a0)
at /usr/src/debug/emacs-24.3/src/eval.c:2839
#37 0x00000000005519fd in run_hook_with_args (nargs=1, args=0x7fff3c2076a0,
funcall=0x552c70 <Ffuncall>) at /usr/src/debug/emacs-24.3/src/eval.c:2509
#38 0x000000000055308f in Ffuncall (nargs=<optimized out>,
args=<optimized out>) at /usr/src/debug/emacs-24.3/src/eval.c:2759
#39 0x000000000058846b in exec_byte_code (bytestr=8618752, vector=2833333,
maxdepth=137, args_template=4611686018430533632,
nargs=4611686018695757824, args=0x0)
at /usr/src/debug/emacs-24.3/src/bytecode.c:900
#40 0x0000000000552b8f in funcall_lambda (fun=14442245, nargs=nargs@entry=0,
arg_vector=arg_vector@entry=0x7fff3c207890)
at /usr/src/debug/emacs-24.3/src/eval.c:3010
#41 0x0000000000552e9b in Ffuncall (nargs=1, args=0x7fff3c207888)
at /usr/src/debug/emacs-24.3/src/eval.c:2839
#42 0x000000000058846b in exec_byte_code (bytestr=8618752, vector=2833333,
maxdepth=137, args_template=4611686018430533632,
nargs=4611686018695757824, args=0x0)
at /usr/src/debug/emacs-24.3/src/bytecode.c:900
#43 0x0000000000552545 in eval_sub (form=form@entry=64459542)
at /usr/src/debug/emacs-24.3/src/eval.c:2149
#44 0x0000000000555828 in internal_lisp_condition_case (var=<optimized out>,
bodyform=64459542, handlers=64459686)
at /usr/src/debug/emacs-24.3/src/eval.c:1243
#45 0x0000000000589018 in exec_byte_code (bytestr=8618752, vector=2833333,
maxdepth=137, args_template=4611686018430533632,
nargs=4611686018695757824, args=0x7fff3c207bd8)
at /usr/src/debug/emacs-24.3/src/bytecode.c:1096
#46 0x0000000000552b8f in funcall_lambda (fun=63149709, nargs=nargs@entry=1,
arg_vector=arg_vector@entry=0x7fff3c207da0)
at /usr/src/debug/emacs-24.3/src/eval.c:3010
#47 0x0000000000552e9b in Ffuncall (nargs=2, args=0x7fff3c207d98)
at /usr/src/debug/emacs-24.3/src/eval.c:2839
#48 0x000000000058846b in exec_byte_code (bytestr=8618752, vector=2833333,
maxdepth=137, args_template=4611686018430533632,
nargs=4611686018695757824, args=0x0)
at /usr/src/debug/emacs-24.3/src/bytecode.c:900
#49 0x0000000000552b8f in funcall_lambda (fun=63176797, nargs=nargs@entry=0,
arg_vector=arg_vector@entry=0x7fff3c208068)
at /usr/src/debug/emacs-24.3/src/eval.c:3010
#50 0x0000000000552e9b in Ffuncall (nargs=nargs@entry=1,
args=args@entry=0x7fff3c208060)
at /usr/src/debug/emacs-24.3/src/eval.c:2839
#51 0x000000000055424c in Fapply (nargs=2, args=0x7fff3c208060)
at /usr/src/debug/emacs-24.3/src/eval.c:2255
#52 0x000000000055308f in Ffuncall (nargs=<optimized out>,
args=<optimized out>) at /usr/src/debug/emacs-24.3/src/eval.c:2759
#53 0x000000000058846b in exec_byte_code (bytestr=8618752, vector=2833333,
maxdepth=137, args_template=4611686018430533632,
nargs=4611686018695757824, args=0x7fff3c208068)
at /usr/src/debug/emacs-24.3/src/bytecode.c:900
#54 0x0000000000552545 in eval_sub (form=form@entry=9979182)
at /usr/src/debug/emacs-24.3/src/eval.c:2149
#55 0x0000000000555828 in internal_lisp_condition_case (var=<optimized out>,
bodyform=9979182, handlers=8751934)
at /usr/src/debug/emacs-24.3/src/eval.c:1243
#56 0x0000000000589018 in exec_byte_code (bytestr=8618752, vector=2833333,
maxdepth=137, args_template=4611686018430533632,
nargs=4611686018695757824, args=0x7fff3c2083a8)
at /usr/src/debug/emacs-24.3/src/bytecode.c:1096
#57 0x0000000000552b8f in funcall_lambda (fun=9978869, nargs=nargs@entry=1,
arg_vector=arg_vector@entry=0x7fff3c208578)
at /usr/src/debug/emacs-24.3/src/eval.c:3010
#58 0x0000000000552e9b in Ffuncall (nargs=nargs@entry=2,
args=args@entry=0x7fff3c208570)
at /usr/src/debug/emacs-24.3/src/eval.c:2839
#59 0x00000000005531ea in call1 (fn=<optimized out>, arg1=arg1@entry=72156685)
at /usr/src/debug/emacs-24.3/src/eval.c:2572
#60 0x00000000004e4c35 in timer_check_2 (idle_timers=<optimized out>,
timers=<optimized out>) at /usr/src/debug/emacs-24.3/src/keyboard.c:4387
#61 timer_check () at /usr/src/debug/emacs-24.3/src/keyboard.c:4454
#62 0x00000000004e4f31 in readable_events (flags=1)
at /usr/src/debug/emacs-24.3/src/keyboard.c:3351
#63 0x00000000004e6658 in get_input_pending (flags=1)
at /usr/src/debug/emacs-24.3/src/keyboard.c:6680
#64 0x00000000004e8e04 in detect_input_pending_run_timers (
do_display=do_display@entry=true)
at /usr/src/debug/emacs-24.3/src/keyboard.c:10273
#65 0x0000000000592a19 in wait_reading_process_output (
time_limit=time_limit@entry=525, nsecs=nsecs@entry=0,
read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true,
wait_for_cell=12140690, wait_proc=wait_proc@entry=0x0,
just_wait_proc=just_wait_proc@entry=0)
at /usr/src/debug/emacs-24.3/src/process.c:4743
#66 0x00000000004209c4 in sit_for (timeout=<optimized out>,
reading=<optimized out>, display_option=<optimized out>)
at /usr/src/debug/emacs-24.3/src/dispnew.c:5978
#67 0x00000000004ea3a9 in read_char (commandflag=1, nmaps=nmaps@entry=2,
maps=maps@entry=0x7fff3c208d30, prev_event=12140690,
used_mouse_menu=used_mouse_menu@entry=0x7fff3c208e47,
end_time=end_time@entry=0x0)
at /usr/src/debug/emacs-24.3/src/keyboard.c:2669
#68 0x00000000004ebba8 in read_key_sequence (
keybuf=keybuf@entry=0x7fff3c208f20, prompt=12140690,
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, bufsize=30)
at /usr/src/debug/emacs-24.3/src/keyboard.c:9231
#69 0x00000000004edf6d in command_loop_1 ()
at /usr/src/debug/emacs-24.3/src/keyboard.c:1459
#70 0x000000000055149a in internal_condition_case (
bfun=bfun@entry=0x4edd70 <command_loop_1>, handlers=12192370,
hfun=hfun@entry=0x4e4220 <cmd_error>)
at /usr/src/debug/emacs-24.3/src/eval.c:1289
#71 0x00000000004df55e in command_loop_2 (ignore=ignore@entry=12140690)
at /usr/src/debug/emacs-24.3/src/keyboard.c:1168
#72 0x0000000000551341 in internal_catch (tag=<optimized out>,
func=func@entry=0x4df540 <command_loop_2>, arg=12140690)
at /usr/src/debug/emacs-24.3/src/eval.c:1060
#73 0x00000000004e3d47 in command_loop ()
at /usr/src/debug/emacs-24.3/src/keyboard.c:1147
#74 recursive_edit_1 () at /usr/src/debug/emacs-24.3/src/keyboard.c:779
#75 0x00000000004e4044 in Frecursive_edit ()
at /usr/src/debug/emacs-24.3/src/keyboard.c:843
#76 0x0000000000417125 in main (argc=<optimized out>, argv=0x7fff3c2094f8)
at /usr/src/debug/emacs-24.3/src/emacs.c:1528
Missing separate debuginfos, use: debuginfo-install adwaita-gtk3-theme-3.10.0-1.fc20.x86_64 at-spi2-atk-2.10.2-1.fc20.x86_64 at-spi2-core-2.10.2-1.fc20.x86_64 dconf-0.18.0-2.fc20.x86_64 fftw-libs-double-3.3.3-7.fc20.x86_64 harfbuzz-0.9.24-1.fc20.x86_64 jbigkit-libs-2.0-9.fc20.x86_64 keyutils-libs-1.5.9-1.fc20.x86_64 krb5-libs-1.11.5-4.fc20.x86_64 lcms2-2.5-2.fc20.x86_64 libXau-1.0.8-2.fc20.x86_64 libXcomposite-0.4.4-4.fc20.x86_64 libXcursor-1.1.14-2.fc20.x86_64 libXdamage-1.1.4-4.fc20.x86_64 libXext-1.3.2-2.fc20.x86_64 libXfixes-5.0.1-2.fc20.x86_64 libXi-1.7.2-2.fc20.x86_64 libXinerama-1.1.3-2.fc20.x86_64 libXrandr-1.4.1-2.fc20.x86_64 libXt-1.1.4-7.fc20.x86_64 libXxf86vm-1.1.3-2.fc20.x86_64 libcom_err-1.42.8-3.fc20.x86_64 libcroco-0.6.8-3.fc20.x86_64 libdrm-2.4.52-1.fc20.x86_64 libffi-3.0.13-5.fc20.x86_64 libtasn1-3.3-2.fc20.x86_64 libwayland-client-1.2.0-3.fc20.x86_64 libwayland-cursor-1.2.0-3.fc20.x86_64 libwayland-server-1.2.0-3.fc20.x86_64 libxcb-1.9.1-3.fc20.x86_64 libxkbcommon-0.3.1-1.fc20.x86_64 mesa-libEGL-9.2.5-1.20131220.fc20.x86_64 mesa-libGL-9.2.5-1.20131220.fc20.x86_64 mesa-libgbm-9.2.5-1.20131220.fc20.x86_64 mesa-libglapi-9.2.5-1.20131220.fc20.x86_64 openssl-libs-1.0.1e-37.fc20.x86_64 pixman-0.30.0-3.fc20.x86_64 systemd-libs-208-15.fc20.x86_64 trousers-0.3.11.2-1.fc20.x86_64
(gdb) quit
A debugging session is active.
Inferior 1 [process 22971] will be detached.
Quit anyway? (y or n) [answered Y; input not from terminal]
Detaching from program: /usr/bin/emacs, process 22971
If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
`bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
/usr/share/emacs/24.3/etc/DEBUG.
In GNU Emacs 24.3.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.9.10)
of 2013-08-15 on buildvm-17.phx2.fedoraproject.org
Windowing system distributor `The X.Org Foundation', version 11.0.11404000
Configured using:
`configure '--build=x86_64-redhat-linux-gnu'
'--host=x86_64-redhat-linux-gnu' '--program-prefix='
'--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr'
'--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
'--datadir=/usr/share' '--includedir=/usr/include'
'--libdir=/usr/lib64' '--libexecdir=/usr/libexec'
'--localstatedir=/var' '--sharedstatedir=/var/lib'
'--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-dbus'
'--with-gif' '--with-jpeg' '--with-png' '--with-rsvg' '--with-tiff'
'--with-xft' '--with-xpm' '--with-x-toolkit=gtk3' '--with-gpm=no'
'build_alias=x86_64-redhat-linux-gnu'
'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g
-pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4
-grecord-gcc-switches -m64 -mtune=generic' 'LDFLAGS=-Wl,-z,relro ''
Important settings:
value of $LANG: en_AU.UTF-8
locale-coding-system: utf-8-unix
default enable-multibyte-characters: t
Major mode: C/lah
Minor modes in effect:
cwarn-mode: t
which-function-mode: t
tooltip-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
column-number-mode: 1
line-number-mode: t
transient-mark-mode: t
abbrev-mode: t
Recent input:
C-d C-d C-d C-x C-s <prior> <down> <down> <down> <down>
<down> <down> <down> <down> <down> <down> <down> <down>
<down> <return> <up> <tab> s e l f . l o g g e r SPC
= SPC L o g F a c t M-/ * ( <backspace> <backspace>
( ) C-x C-s C-s E n v <C-right> <C-left> <left> <left>
C-g C-g C-g C-g <right> <right> <C-backspace> <C-backspace>
C-s C-s C-s C-s C-s C-s C-s C-s C-s C-g C-x C-s M-<
C-s C M . r s h C-g C-g <next> <down> <down> <down>
<down> <down> <down> <down> <down> <down> <down> <down>
<down> C-s s e l f . E n v C-s C-s C-s C-s C-s <down>
<down> <down> <down> C-s C-s C-s C-s C-s <down-mouse-1>
<mouse-1> <up> <down-mouse-1> <mouse-1> C-g C-g C-g
C-g C-g M-< <down-mouse-1> <mouse-1> <next> <down-mouse-1>
<mouse-1> M-% s e l f . l o g <return> <up> <C-right>
<C-right> g e r . l o g <return> n n y y y y y y y
y y y y y y y y y y y y y y y y y y y y y y y y y y
y y y y y y y y y y y y y y y y y y y y y y y y y y
y y y y y y y y y y y y y <backspace> <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> <backspace>
<backspace> <backspace> <backspace> <up> <up> <down-mouse-1>
<mouse-1> <down-mouse-1> <mouse-1> C-x C-s <up> <up>
<up> <up> M-x <up> <up> <up> C-g C-x b C-x b x m l
. c <return> <down> <down> <down> <down> <down> <down>
<down> <down> <up> <up> <up> <up> <up> <up> <up> <up>
M-x r e p o <tab> r <tab> <return>
Recent messages:
Mark saved where search started [2 times]
Quit [6 times]
Mark set [2 times]
Replaced 63 occurrences
Saving file /home/beekhof/Development/sources/pacemaker/devel/cts/CTStests.py...
Wrote /home/beekhof/Development/sources/pacemaker/devel/cts/CTStests.py
user-error: Beginning of history; no preceding item
Quit
completing-read-default: Command attempted to use minibuffer while in minibuffer
Making completion list...
Load-path shadows:
/home/beekhof/.emacs.d/elpa/color-theme-6.5.5/color-theme hides ~/.beekhof/emacs/color-theme
/home/beekhof/.emacs.d/elpa/repository-root-1.0.3/repository-root hides ~/.beekhof/emacs/repository-root
/home/beekhof/.emacs.d/elpa/grep-o-matic-1.0.4/grep-o-matic hides ~/.beekhof/emacs/grep-o-matic
Features:
(shadow sort gnus-util mail-extr emacsbug message cl-macs gv format-spec
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils sh-script smie executable python rx
make-mode subword dabbrev help-mode misearch multi-isearch nxml-uchnm
rng-xsd xsd-regexp rng-cmpct rng-nxml rng-valid rng-loc rng-uri
rng-parse nxml-parse rng-match rng-dt rng-util rng-pttrn nxml-ns
nxml-mode nxml-outln nxml-rap nxml-util nxml-glyph nxml-enc xmltok etags
add-log vc-git cwarn which-func imenu cc-langs cc-mode cc-fonts cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs
browse-kill-ring grep-o-matic grep compile comint ansi-color ring
repository-root color-theme-tomorrow-night-bright
color-theme-tomorrow-night-blue color-theme-tomorrow-night-eighties
color-theme-tomorrow-night color-theme-tomorrow color-theme easymenu
wid-edit cl edmacro kmacro ibuffer skeleton uniquify advice help-fns
cl-lib advice-preload server browse-kill-ring-autoloads
color-theme-autoloads color-theme-sanityinc-tomorrow-autoloads
grep-a-lot-autoloads grep-o-matic-autoloads repository-root-autoloads
package time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel
x-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list
newcomment lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty emacs)
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 841 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#16995: 24.3; CPU usage spikes to 100% for minutes at a time
2014-03-12 7:08 bug#16995: 24.3; CPU usage spikes to 100% for minutes at a time Andrew Beekhof
@ 2014-03-12 8:13 ` Michael Heerdegen
2014-03-12 16:17 ` Eli Zaretskii
1 sibling, 0 replies; 13+ messages in thread
From: Michael Heerdegen @ 2014-03-12 8:13 UTC (permalink / raw)
To: Andrew Beekhof; +Cc: 16995
Andrew Beekhof <andrew@beekhof.net> writes:
> I've been editing lots of python files in the last few days and noticed
> that Emacs has begun locking up for minutes at a time, for no apparent
> reason.
Maybe you face the same symptoms as in bug#15295? The report was
related to `which-func-mode '. Parts of python.el are quite
inefficient, it's important to fix this.
Michael.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#16995: 24.3; CPU usage spikes to 100% for minutes at a time
2014-03-12 7:08 bug#16995: 24.3; CPU usage spikes to 100% for minutes at a time Andrew Beekhof
2014-03-12 8:13 ` Michael Heerdegen
@ 2014-03-12 16:17 ` Eli Zaretskii
2014-03-13 0:30 ` Andrew Beekhof
1 sibling, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2014-03-12 16:17 UTC (permalink / raw)
To: Andrew Beekhof; +Cc: 16995
> From: Andrew Beekhof <andrew@beekhof.net>
> Date: Wed, 12 Mar 2014 18:08:27 +1100
>
> I've been editing lots of python files in the last few days and noticed
> that Emacs has begun locking up for minutes at a time, for no apparent
> reason.
>
> Example actions that can trigger the problem C-s (isearch-forward),
> pressing 'y' in response to query-replace prompts, typing, etc.
> Whether the buffer is saved or not makes no difference.
>
> The only thing that really seems to help is switching back to a .c file.
>
> Is this a known problem?
>
> Example top output:
>
> top - 17:44:11 up 29 days, 22:26, 3 users, load average: 0.44, 0.50, 0.42
> Tasks: 236 total, 2 running, 233 sleeping, 0 stopped, 1 zombie
> %Cpu(s): 12.6 us, 0.1 sy, 0.0 ni, 87.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
> KiB Mem: 7871472 total, 7538448 used, 333024 free, 305676 buffers
> KiB Swap: 6029308 total, 731032 used, 5298276 free, 2390156 cached
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 22971 beekhof 20 0 644976 49236 16308 R 100.1 0.6 19:33.79 emacs
> 26689 root 20 0 53020 272 176 S 0.7 0.0 308:17.91 plymouthd
>
> A random blog suggested the following command might show something of
> interest. All I can tell is that thread 1 is quite deep.
>
> # echo 't a a where' > gdb.cmd; gdb /usr/bin/emacs -p 22971 -x gdb.cmd 2>&1 </dev/null | tee /tmp/emacs.crash.backtrace
> GNU gdb (GDB) Fedora 7.6.50.20130731-19.fc20
The backtrace you posted indicates that Emacs is in garbage
collection. To see if this is indeed the cause of those "lockups",
could you please customize garbage-collection-messages to a non-nil
value, and then see if every time Emacs locks up there's a message in
the echo area announcing GC?
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#16995: 24.3; CPU usage spikes to 100% for minutes at a time
2014-03-12 16:17 ` Eli Zaretskii
@ 2014-03-13 0:30 ` Andrew Beekhof
2014-03-13 3:49 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Andrew Beekhof @ 2014-03-13 0:30 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 16995
[-- Attachment #1: Type: text/plain, Size: 3667 bytes --]
On 13 Mar 2014, at 3:17 am, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Andrew Beekhof <andrew@beekhof.net>
>> Date: Wed, 12 Mar 2014 18:08:27 +1100
>>
>> I've been editing lots of python files in the last few days and noticed
>> that Emacs has begun locking up for minutes at a time, for no apparent
>> reason.
>>
>> Example actions that can trigger the problem C-s (isearch-forward),
>> pressing 'y' in response to query-replace prompts, typing, etc.
>> Whether the buffer is saved or not makes no difference.
>>
>> The only thing that really seems to help is switching back to a .c file.
>>
>> Is this a known problem?
>>
>> Example top output:
>>
>> top - 17:44:11 up 29 days, 22:26, 3 users, load average: 0.44, 0.50, 0.42
>> Tasks: 236 total, 2 running, 233 sleeping, 0 stopped, 1 zombie
>> %Cpu(s): 12.6 us, 0.1 sy, 0.0 ni, 87.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
>> KiB Mem: 7871472 total, 7538448 used, 333024 free, 305676 buffers
>> KiB Swap: 6029308 total, 731032 used, 5298276 free, 2390156 cached
>>
>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>> 22971 beekhof 20 0 644976 49236 16308 R 100.1 0.6 19:33.79 emacs
>> 26689 root 20 0 53020 272 176 S 0.7 0.0 308:17.91 plymouthd
>>
>> A random blog suggested the following command might show something of
>> interest. All I can tell is that thread 1 is quite deep.
>>
>> # echo 't a a where' > gdb.cmd; gdb /usr/bin/emacs -p 22971 -x gdb.cmd 2>&1 </dev/null | tee /tmp/emacs.crash.backtrace
>> GNU gdb (GDB) Fedora 7.6.50.20130731-19.fc20
>
> The backtrace you posted indicates that Emacs is in garbage
> collection. To see if this is indeed the cause of those "lockups",
> could you please customize garbage-collection-messages to a non-nil
> value, and then see if every time Emacs locks up there's a message in
> the echo area announcing GC?
It took about 2 hours of solid editing to hit it again this morning, but eventually I did.
For the first while I saw 'Garbage collecting...done', with the 'done' part flashing.
Then it switched to 'Garbage collecting...'
At some point I must have hit C-l (goto-line) because after I came back from making breakfast (I wasn't exaggerating when I said 'minutes') it was prompting for a line number.
Pressing C-g (cancel) at this point resulted in the buffer flashing between displaying 'Quit' and 'Garbage collecting...'
After it stopped doing this, I used the pointer to move the cursor which got me back to the 'Garbage collecting...' phase followed by 'Garbage collecting...done', with the 'done' part flashing again.
Top says:
22971 beekhof 20 0 658092 61636 15584 R 99.1 0.8 37:03.28 emacs
(note that its still the same process from yesterday)
If I now switch to a .c file, things appear normal.
Switching back to the .py file and doing anything results in more garbage collection.
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 841 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#16995: 24.3; CPU usage spikes to 100% for minutes at a time
2014-03-13 0:30 ` Andrew Beekhof
@ 2014-03-13 3:49 ` Eli Zaretskii
2014-03-13 13:40 ` Stefan Monnier
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2014-03-13 3:49 UTC (permalink / raw)
To: Andrew Beekhof; +Cc: 16995
> From: Andrew Beekhof <andrew@beekhof.net>
> Date: Thu, 13 Mar 2014 11:30:15 +1100
> Cc: 16995@debbugs.gnu.org
>
> > The backtrace you posted indicates that Emacs is in garbage
> > collection. To see if this is indeed the cause of those "lockups",
> > could you please customize garbage-collection-messages to a non-nil
> > value, and then see if every time Emacs locks up there's a message in
> > the echo area announcing GC?
>
> It took about 2 hours of solid editing to hit it again this morning, but eventually I did.
>
> For the first while I saw 'Garbage collecting...done', with the 'done' part flashing.
>
> Then it switched to 'Garbage collecting...'
>
> At some point I must have hit C-l (goto-line) because after I came back from making breakfast (I wasn't exaggerating when I said 'minutes') it was prompting for a line number.
> Pressing C-g (cancel) at this point resulted in the buffer flashing between displaying 'Quit' and 'Garbage collecting...'
>
> After it stopped doing this, I used the pointer to move the cursor which got me back to the 'Garbage collecting...' phase followed by 'Garbage collecting...done', with the 'done' part flashing again.
>
> Top says:
>
> 22971 beekhof 20 0 658092 61636 15584 R 99.1 0.8 37:03.28 emacs
>
> (note that its still the same process from yesterday)
>
>
> If I now switch to a .c file, things appear normal.
> Switching back to the .py file and doing anything results in more garbage collection.
So I guess the question now becomes why does Python mode conses so
many Lisp objects that it triggers GC so frequently.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#16995: 24.3; CPU usage spikes to 100% for minutes at a time
2014-03-13 3:49 ` Eli Zaretskii
@ 2014-03-13 13:40 ` Stefan Monnier
2014-03-13 15:56 ` Glenn Morris
2014-03-17 5:12 ` Andrew Beekhof
0 siblings, 2 replies; 13+ messages in thread
From: Stefan Monnier @ 2014-03-13 13:40 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Andrew Beekhof, 16995
> So I guess the question now becomes why does Python mode conses so
> many Lisp objects that it triggers GC so frequently.
M-x profiler-start RET mem RET
...reproduce the heavy allocation problem...
M-x profiler-report RET
might be a good start.
Stefan
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#16995: 24.3; CPU usage spikes to 100% for minutes at a time
2014-03-13 13:40 ` Stefan Monnier
@ 2014-03-13 15:56 ` Glenn Morris
2014-03-17 5:12 ` Andrew Beekhof
1 sibling, 0 replies; 13+ messages in thread
From: Glenn Morris @ 2014-03-13 15:56 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Andrew Beekhof, 16995
I think it makes more sense to first try the Emacs trunk and see if the
issue is already fixed.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#16995: 24.3; CPU usage spikes to 100% for minutes at a time
2014-03-13 13:40 ` Stefan Monnier
2014-03-13 15:56 ` Glenn Morris
@ 2014-03-17 5:12 ` Andrew Beekhof
2014-03-17 5:15 ` Daniel Colascione
2014-03-17 15:04 ` Stefan
1 sibling, 2 replies; 13+ messages in thread
From: Andrew Beekhof @ 2014-03-17 5:12 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 16995
[-- Attachment #1: Type: text/plain, Size: 4036 bytes --]
On 14 Mar 2014, at 12:40 am, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> So I guess the question now becomes why does Python mode conses so
>> many Lisp objects that it triggers GC so frequently.
>
> M-x profiler-start RET mem RET
> ...reproduce the heavy allocation problem...
> M-x profiler-report RET
>
> might be a good start.
bwahahaha. I can go one better and give you a reproducer.
Time wasn't a factor, it was switching to a particular file that triggered the (worst of the) problem.
http://paste.fedoraproject.org/85549/13948345/
I had a bug in the file that was causing issues for soemthing:
@@ -90,7 +92,7 @@ class CTSTest:
self.logger.log(args)
def debug(self, args):
- self.logger.debug(args
+ self.logger.debug(args)
Clearly user error, but ideally emacs wouldn't grind to a halt as a result.
Here's the profiler report.
+ timer-event-handler 278,246,734 42%
+ which-func-update 163,238,117 24%
+ redisplay_internal (C function) 87,767,721 13%
+ which-func-update-1 48,416,290 7%
+ call-interactively 35,478,972 5%
+ apply 18,737,232 2%
+ byte-code 5,265,147 0%
+ which-function 4,192,656 0%
+ jit-lock-function 2,876,348 0%
+ redisplay 2,237,092 0%
+ sit-for 1,867,352 0%
+ read-from-minibuffer 1,418,935 0%
+ find-file 1,333,035 0%
+ xselect-convert-to-string 810,557 0%
+ vc-state-refresh 698,757 0%
+ isearch-lazy-highlight-new-loop 649,320 0%
+ isearch-update 589,542 0%
+ minibuffer-message 208,140 0%
+ completion--message 168,120 0%
+ isearch-process-search-string 153,114 0%
+ isearch-search-and-update 145,286 0%
+ jit-lock-fontify-now 136,240 0%
+ x-set-selection 82,873 0%
+ minibuffer-complete 46,642 0%
+ completion--do-completion 38,266 0%
+ deactivate-mark 36,976 0%
+ run-hook-with-args-until-success 24,764 0%
+ run-hooks 22,286 0%
+ run-hook-with-args 17,952 0%
+ xselect-convert-to-targets 17,443 0%
+ find-file-noselect 12,432 0%
+ self-insert-command 8,188 0%
+ c-mode 8,188 0%
+ find-tag 7,000 0%
+ mouse-fixup-help-message 6,144 0%
+ find-file-read-args 5,120 0%
+ funcall 4,096 0%
+ vc-find-file-hook 3,720 0%
+ vc-registered 2,487 0%
+ find-file-noselect-1 2,026 0%
+ file-truename 1,260 0%
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 841 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#16995: 24.3; CPU usage spikes to 100% for minutes at a time
2014-03-17 5:12 ` Andrew Beekhof
@ 2014-03-17 5:15 ` Daniel Colascione
2014-03-17 17:19 ` Glenn Morris
2014-03-17 15:04 ` Stefan
1 sibling, 1 reply; 13+ messages in thread
From: Daniel Colascione @ 2014-03-17 5:15 UTC (permalink / raw)
To: Andrew Beekhof, Stefan Monnier; +Cc: 16995
[-- Attachment #1: Type: text/plain, Size: 925 bytes --]
On 03/16/2014 10:12 PM, Andrew Beekhof wrote:
>
> On 14 Mar 2014, at 12:40 am, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>>> So I guess the question now becomes why does Python mode conses so
>>> many Lisp objects that it triggers GC so frequently.
>>
>> M-x profiler-start RET mem RET
>> ...reproduce the heavy allocation problem...
>> M-x profiler-report RET
>>
>> might be a good start.
>
>
> bwahahaha. I can go one better and give you a reproducer.
> Time wasn't a factor, it was switching to a particular file that triggered the (worst of the) problem.
>
> http://paste.fedoraproject.org/85549/13948345/
>
> I had a bug in the file that was causing issues for soemthing:
>
> @@ -90,7 +92,7 @@ class CTSTest:
> self.logger.log(args)
>
> def debug(self, args):
> - self.logger.debug(args
> + self.logger.debug(args)
>
>
No repro on trunk.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#16995: 24.3; CPU usage spikes to 100% for minutes at a time
2014-03-17 5:12 ` Andrew Beekhof
2014-03-17 5:15 ` Daniel Colascione
@ 2014-03-17 15:04 ` Stefan
2014-03-17 20:44 ` Andrew Beekhof
1 sibling, 1 reply; 13+ messages in thread
From: Stefan @ 2014-03-17 15:04 UTC (permalink / raw)
To: Andrew Beekhof; +Cc: 16995
> + timer-event-handler 278,246,734 42%
> + which-func-update 163,238,117 24%
> + redisplay_internal (C function) 87,767,721 13%
Could you hit C-u RET on those to see the inside?
Stefan
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#16995: 24.3; CPU usage spikes to 100% for minutes at a time
2014-03-17 15:04 ` Stefan
@ 2014-03-17 20:44 ` Andrew Beekhof
0 siblings, 0 replies; 13+ messages in thread
From: Andrew Beekhof @ 2014-03-17 20:44 UTC (permalink / raw)
To: Stefan; +Cc: 16995
[-- Attachment #1: Type: text/plain, Size: 4113 bytes --]
On 18 Mar 2014, at 2:04 am, Stefan <monnier@iro.umontreal.ca> wrote:
>> + timer-event-handler 278,246,734 42%
>> + which-func-update 163,238,117 24%
>> + redisplay_internal (C function) 87,767,721 13%
>
> Could you hit C-u RET on those to see the inside?
- timer-event-handler 278,246,734 42%
- byte-code 232,219,728 35%
- apply 232,219,728 35%
- which-func-update 232,156,176 35%
- which-func-update-1 232,156,176 35%
- byte-code 232,152,016 35%
- which-function 232,152,016 35%
- run-hook-with-args-until-success 232,137,652 35%
- python-info-current-defun 232,137,652 35%
- byte-code 232,076,332 35%
- python-nav-beginning-of-statement 223,523,054 34%
- python-info-line-ends-backslash 222,980,681 34%
- python-syntax-context 222,963,339 34%
- syntax-ppss 190,698,616 29%
+ vconcat 87,050,385 13%
+ make-byte-code 39,649,234 6%
+ vector 35,847,977 5%
Automatic GC 10,494,908 1%
+ funcall 4,192 0%
+ eql 32,264,723 4%
Automatic GC 3,774 0%
+ python-syntax-context 520,437 0%
+ python-nav-end-of-defun 5,995,614 0%
+ python-nav-beginning-of-defun 2,037,676 0%
current-indentation 437,600 0%
match-data 43,152 0%
+ match-string-no-properties 24,564 0%
current-indentation 38,640 0%
mapconcat 16,376 0%
+ add-log-current-defun 12,284 0%
reverse 2,080 0%
internal--before-with-selected-window 4,160 0%
+ jit-lock-context-fontify 36,400 0%
+ blink-cursor-start 27,152 0%
+ timer-inc-time 31,783,254 4%
+ timer-until 9,210,331 1%
current-time 4,922,320 0%
Automatic GC 98,621 0%
+ timer-activate-when-idle 12,480 0%
- which-func-update 163,238,117 24%
- which-func-update-1 163,238,117 24%
- byte-code 163,238,117 24%
- which-function 163,238,117 24%
+ run-hook-with-args-until-success 163,238,117 24%
- redisplay_internal (C function) 87,767,721 13%
+ jit-lock-function 17,436,266 2%
+ file-remote-p 1,437,050 0%
+ eval 958,755 0%
+ menu-bar-update-buffers 48,468 0%
+ keymap-canonicalize 17,680 0%
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 841 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2014-03-17 22:28 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-03-12 7:08 bug#16995: 24.3; CPU usage spikes to 100% for minutes at a time Andrew Beekhof
2014-03-12 8:13 ` Michael Heerdegen
2014-03-12 16:17 ` Eli Zaretskii
2014-03-13 0:30 ` Andrew Beekhof
2014-03-13 3:49 ` Eli Zaretskii
2014-03-13 13:40 ` Stefan Monnier
2014-03-13 15:56 ` Glenn Morris
2014-03-17 5:12 ` Andrew Beekhof
2014-03-17 5:15 ` Daniel Colascione
2014-03-17 17:19 ` Glenn Morris
2014-03-17 22:28 ` Andrew Beekhof
2014-03-17 15:04 ` Stefan
2014-03-17 20:44 ` Andrew Beekhof
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.