Package: emacs;
Reported by: Andrew Beekhof <andrew <at> beekhof.net>
Date: Wed, 12 Mar 2014 07:17:02 UTC
Severity: normal
Tags: moreinfo
Found in version 24.3
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16995 in the body.
You can then email your comments to 16995 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-gnu-emacs <at> gnu.org:bug#16995; Package emacs.
(Wed, 12 Mar 2014 07:17:02 GMT) Full text and rfc822 format available.Andrew Beekhof <andrew <at> beekhof.net>:bug-gnu-emacs <at> gnu.org.
(Wed, 12 Mar 2014 07:17:03 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Andrew Beekhof <andrew <at> beekhof.net> To: bug-gnu-emacs <at> gnu.org Subject: 24.3; CPU usage spikes to 100% for minutes at a time Date: Wed, 12 Mar 2014 18:08:27 +1100
[Message part 1 (text/plain, inline)]
# 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 <at> entry=0xca2e00,
block=block <at> entry=1, dispatch=dispatch <at> 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 <at> entry=1,
dispatch=dispatch <at> 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 <at> 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 <at> entry=0,
arg_vector=0x970c49 <pure+1280329>, arg_vector <at> 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 <at> entry=1,
arg_vector=arg_vector <at> 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 <at> entry=0,
arg_vector=arg_vector <at> 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 <at> entry=0,
arg_vector=arg_vector <at> 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 <at> entry=1,
arg_vector=arg_vector <at> 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 <at> entry=0,
arg_vector=arg_vector <at> 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 <at> entry=1,
arg_vector=arg_vector <at> 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 <at> entry=1,
arg_vector=arg_vector <at> 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 <at> 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 <at> entry=0,
arg_vector=arg_vector <at> 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 <at> entry=0,
arg_vector=arg_vector <at> 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 <at> 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 <at> entry=1,
arg_vector=arg_vector <at> 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 <at> entry=0,
arg_vector=arg_vector <at> entry=0x7fff3c208068)
at /usr/src/debug/emacs-24.3/src/eval.c:3010
#50 0x0000000000552e9b in Ffuncall (nargs=nargs <at> entry=1,
args=args <at> 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 <at> 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 <at> entry=1,
arg_vector=arg_vector <at> entry=0x7fff3c208578)
at /usr/src/debug/emacs-24.3/src/eval.c:3010
#58 0x0000000000552e9b in Ffuncall (nargs=nargs <at> entry=2,
args=args <at> entry=0x7fff3c208570)
at /usr/src/debug/emacs-24.3/src/eval.c:2839
#59 0x00000000005531ea in call1 (fn=<optimized out>, arg1=arg1 <at> 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 <at> entry=true)
at /usr/src/debug/emacs-24.3/src/keyboard.c:10273
#65 0x0000000000592a19 in wait_reading_process_output (
time_limit=time_limit <at> entry=525, nsecs=nsecs <at> entry=0,
read_kbd=read_kbd <at> entry=-1, do_display=do_display <at> entry=true,
wait_for_cell=12140690, wait_proc=wait_proc <at> entry=0x0,
just_wait_proc=just_wait_proc <at> 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 <at> entry=2,
maps=maps <at> entry=0x7fff3c208d30, prev_event=12140690,
used_mouse_menu=used_mouse_menu <at> entry=0x7fff3c208e47,
end_time=end_time <at> entry=0x0)
at /usr/src/debug/emacs-24.3/src/keyboard.c:2669
#68 0x00000000004ebba8 in read_key_sequence (
keybuf=keybuf <at> entry=0x7fff3c208f20, prompt=12140690,
dont_downcase_last=dont_downcase_last <at> entry=false,
can_return_switch_frame=can_return_switch_frame <at> entry=true,
fix_current_buffer=fix_current_buffer <at> 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 <at> entry=0x4edd70 <command_loop_1>, handlers=12192370,
hfun=hfun <at> entry=0x4e4220 <cmd_error>)
at /usr/src/debug/emacs-24.3/src/eval.c:1289
#71 0x00000000004df55e in command_loop_2 (ignore=ignore <at> entry=12140690)
at /usr/src/debug/emacs-24.3/src/keyboard.c:1168
#72 0x0000000000551341 in internal_catch (tag=<optimized out>,
func=func <at> 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)
[signature.asc (application/pgp-signature, attachment)]
bug-gnu-emacs <at> gnu.org:bug#16995; Package emacs.
(Wed, 12 Mar 2014 08:15:01 GMT) Full text and rfc822 format available.Message #8 received at 16995 <at> debbugs.gnu.org (full text, mbox):
From: Michael Heerdegen <michael_heerdegen <at> web.de> To: Andrew Beekhof <andrew <at> beekhof.net> Cc: 16995 <at> debbugs.gnu.org Subject: Re: bug#16995: 24.3; CPU usage spikes to 100% for minutes at a time Date: Wed, 12 Mar 2014 09:13:57 +0100
Andrew Beekhof <andrew <at> 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.
bug-gnu-emacs <at> gnu.org:bug#16995; Package emacs.
(Wed, 12 Mar 2014 16:18:02 GMT) Full text and rfc822 format available.Message #11 received at 16995 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Andrew Beekhof <andrew <at> beekhof.net> Cc: 16995 <at> debbugs.gnu.org Subject: Re: bug#16995: 24.3; CPU usage spikes to 100% for minutes at a time Date: Wed, 12 Mar 2014 18:17:04 +0200
> From: Andrew Beekhof <andrew <at> 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?
bug-gnu-emacs <at> gnu.org:bug#16995; Package emacs.
(Thu, 13 Mar 2014 00:31:01 GMT) Full text and rfc822 format available.Message #14 received at 16995 <at> debbugs.gnu.org (full text, mbox):
From: Andrew Beekhof <andrew <at> beekhof.net> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 16995 <at> debbugs.gnu.org Subject: Re: bug#16995: 24.3; CPU usage spikes to 100% for minutes at a time Date: Thu, 13 Mar 2014 11:30:15 +1100
[Message part 1 (text/plain, inline)]
On 13 Mar 2014, at 3:17 am, Eli Zaretskii <eliz <at> gnu.org> wrote: >> From: Andrew Beekhof <andrew <at> 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.
[signature.asc (application/pgp-signature, attachment)]
bug-gnu-emacs <at> gnu.org:bug#16995; Package emacs.
(Thu, 13 Mar 2014 03:50:03 GMT) Full text and rfc822 format available.Message #17 received at 16995 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Andrew Beekhof <andrew <at> beekhof.net> Cc: 16995 <at> debbugs.gnu.org Subject: Re: bug#16995: 24.3; CPU usage spikes to 100% for minutes at a time Date: Thu, 13 Mar 2014 05:49:14 +0200
> From: Andrew Beekhof <andrew <at> beekhof.net> > Date: Thu, 13 Mar 2014 11:30:15 +1100 > Cc: 16995 <at> 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.
bug-gnu-emacs <at> gnu.org:bug#16995; Package emacs.
(Thu, 13 Mar 2014 13:41:02 GMT) Full text and rfc822 format available.Message #20 received at 16995 <at> debbugs.gnu.org (full text, mbox):
From: Stefan Monnier <monnier <at> iro.umontreal.ca> To: Eli Zaretskii <eliz <at> gnu.org> Cc: Andrew Beekhof <andrew <at> beekhof.net>, 16995 <at> debbugs.gnu.org Subject: Re: bug#16995: 24.3; CPU usage spikes to 100% for minutes at a time Date: Thu, 13 Mar 2014 09:40:34 -0400
> 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
bug-gnu-emacs <at> gnu.org:bug#16995; Package emacs.
(Thu, 13 Mar 2014 15:57:02 GMT) Full text and rfc822 format available.Message #23 received at 16995 <at> debbugs.gnu.org (full text, mbox):
From: Glenn Morris <rgm <at> gnu.org> To: Stefan Monnier <monnier <at> iro.umontreal.ca> Cc: Andrew Beekhof <andrew <at> beekhof.net>, Eli Zaretskii <eliz <at> gnu.org>, 16995 <at> debbugs.gnu.org Subject: Re: bug#16995: 24.3; CPU usage spikes to 100% for minutes at a time Date: Thu, 13 Mar 2014 11:56:02 -0400
I think it makes more sense to first try the Emacs trunk and see if the issue is already fixed.
bug-gnu-emacs <at> gnu.org:bug#16995; Package emacs.
(Mon, 17 Mar 2014 05:13:03 GMT) Full text and rfc822 format available.Message #26 received at 16995 <at> debbugs.gnu.org (full text, mbox):
From: Andrew Beekhof <andrew <at> beekhof.net> To: Stefan Monnier <monnier <at> iro.umontreal.ca> Cc: Eli Zaretskii <eliz <at> gnu.org>, 16995 <at> debbugs.gnu.org Subject: Re: bug#16995: 24.3; CPU usage spikes to 100% for minutes at a time Date: Mon, 17 Mar 2014 16:12:33 +1100
[Message part 1 (text/plain, inline)]
On 14 Mar 2014, at 12:40 am, Stefan Monnier <monnier <at> 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%
[signature.asc (application/pgp-signature, attachment)]
bug-gnu-emacs <at> gnu.org:bug#16995; Package emacs.
(Mon, 17 Mar 2014 05:16:02 GMT) Full text and rfc822 format available.Message #29 received at 16995 <at> debbugs.gnu.org (full text, mbox):
From: Daniel Colascione <dancol <at> dancol.org> To: Andrew Beekhof <andrew <at> beekhof.net>, Stefan Monnier <monnier <at> iro.umontreal.ca> Cc: 16995 <at> debbugs.gnu.org Subject: Re: bug#16995: 24.3; CPU usage spikes to 100% for minutes at a time Date: Sun, 16 Mar 2014 22:15:44 -0700
[Message part 1 (text/plain, inline)]
On 03/16/2014 10:12 PM, Andrew Beekhof wrote: > > On 14 Mar 2014, at 12:40 am, Stefan Monnier <monnier <at> 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.
[signature.asc (application/pgp-signature, attachment)]
bug-gnu-emacs <at> gnu.org:bug#16995; Package emacs.
(Mon, 17 Mar 2014 15:05:01 GMT) Full text and rfc822 format available.Message #32 received at 16995 <at> debbugs.gnu.org (full text, mbox):
From: Stefan <monnier <at> iro.umontreal.ca> To: Andrew Beekhof <andrew <at> beekhof.net> Cc: Eli Zaretskii <eliz <at> gnu.org>, 16995 <at> debbugs.gnu.org Subject: Re: bug#16995: 24.3; CPU usage spikes to 100% for minutes at a time Date: Mon, 17 Mar 2014 11:04:32 -0400
> + 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
bug-gnu-emacs <at> gnu.org:bug#16995; Package emacs.
(Mon, 17 Mar 2014 17:20:02 GMT) Full text and rfc822 format available.Message #35 received at 16995 <at> debbugs.gnu.org (full text, mbox):
From: Glenn Morris <rgm <at> gnu.org> To: Daniel Colascione <dancol <at> dancol.org> Cc: Andrew Beekhof <andrew <at> beekhof.net>, 16995 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca> Subject: Re: bug#16995: 24.3; CPU usage spikes to 100% for minutes at a time Date: Mon, 17 Mar 2014 13:19:29 -0400
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.
bug-gnu-emacs <at> gnu.org:bug#16995; Package emacs.
(Mon, 17 Mar 2014 20:45:02 GMT) Full text and rfc822 format available.Message #38 received at 16995 <at> debbugs.gnu.org (full text, mbox):
From: Andrew Beekhof <andrew <at> beekhof.net> To: Stefan <monnier <at> iro.umontreal.ca> Cc: Eli Zaretskii <eliz <at> gnu.org>, 16995 <at> debbugs.gnu.org Subject: Re: bug#16995: 24.3; CPU usage spikes to 100% for minutes at a time Date: Tue, 18 Mar 2014 07:44:10 +1100
[Message part 1 (text/plain, inline)]
On 18 Mar 2014, at 2:04 am, Stefan <monnier <at> 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%
[signature.asc (application/pgp-signature, attachment)]
bug-gnu-emacs <at> gnu.org:bug#16995; Package emacs.
(Mon, 17 Mar 2014 22:29:02 GMT) Full text and rfc822 format available.Message #41 received at 16995 <at> debbugs.gnu.org (full text, mbox):
From: Andrew Beekhof <andrew <at> beekhof.net> To: Glenn Morris <rgm <at> gnu.org> Cc: 16995 <at> debbugs.gnu.org, Daniel Colascione <dancol <at> dancol.org>, Stefan Monnier <monnier <at> iro.umontreal.ca> Subject: Re: bug#16995: 24.3; CPU usage spikes to 100% for minutes at a time Date: Tue, 18 Mar 2014 09:28:45 +1100
[Message part 1 (text/plain, inline)]
On 18 Mar 2014, at 4:19 am, Glenn Morris <rgm <at> 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.
[signature.asc (application/pgp-signature, attachment)]
Lars Ingebrigtsen <larsi <at> gnus.org>
to control <at> debbugs.gnu.org.
(Sat, 26 Dec 2015 14:01:02 GMT) Full text and rfc822 format available.Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org.
(Sun, 24 Jan 2016 12:24:13 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.