* 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 5:15 ` Daniel Colascione
@ 2014-03-17 17:19 ` Glenn Morris
2014-03-17 22:28 ` Andrew Beekhof
0 siblings, 1 reply; 13+ messages in thread
From: Glenn Morris @ 2014-03-17 17:19 UTC (permalink / raw)
To: Daniel Colascione; +Cc: Andrew Beekhof, 16995
Daniel Colascione wrote:
> No repro on trunk.
So once again I encourage the OP to try Emacs trunk, to avoid wasting
time debugging something that's already fixed there.
^ 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
* bug#16995: 24.3; CPU usage spikes to 100% for minutes at a time
2014-03-17 17:19 ` Glenn Morris
@ 2014-03-17 22:28 ` Andrew Beekhof
0 siblings, 0 replies; 13+ messages in thread
From: Andrew Beekhof @ 2014-03-17 22:28 UTC (permalink / raw)
To: Glenn Morris; +Cc: 16995
[-- Attachment #1: Type: text/plain, Size: 475 bytes --]
On 18 Mar 2014, at 4:19 am, Glenn Morris <rgm@gnu.org> wrote:
> Daniel Colascione wrote:
>
>> No repro on trunk.
>
> So once again I encourage the OP to try Emacs trunk, to avoid wasting
> time debugging something that's already fixed there.
>
I'll probably take the path of least resistance and try not to write crappy code in the first place.
Its good to know that trunk is fixed though, because that means the patch will eventually show up in fedora.
[-- 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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
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).