* bug#25119: Hard freeze when switching to indirect buffer
@ 2016-12-05 16:46 Ryan Johnson
[not found] ` <handler.25119.B.148095640113649.ack@debbugs.gnu.org>
0 siblings, 1 reply; 7+ messages in thread
From: Ryan Johnson @ 2016-12-05 16:46 UTC (permalink / raw)
To: 25119
[-- Attachment #1: Type: text/plain, Size: 27332 bytes --]
Hi,
I use `emacs -nw` intensively for code development, often with 50+ files
open for weeks at a time, many of them with indirect buffers created by
`clone-indirect-buffer. Every once in a while, emacs will hard-freeze
(ignoring both ^Z and ^G^G^G) when I switch to one of these indirect
buffers. I'm forced to kill it from another terminal. I attached a
snippet of a screenshot showing the terminal state at the time of the
freeze.
The end of this email contains the relevant output of report-emacs-bug,
invoked from a fresh session (since I can't do it for the hung session):
Attaching to the hung process with gdb, I see:
Thread 1 "emacs" received signal SIGTTOU, Stopped (tty output).
0x00007f60bf9a8960 in __GI_tcsetattr (fd=..., optional_actions=...,
termios_p=...) at ../sysdeps/unix/sysv/linux/tcsetattr.c:83
83 ../sysdeps/unix/sysv/linux/tcsetattr.c: No such file or directory.
(gdb) xbacktrace
"suspend-emacs" (0xc652c910)
"suspend-frame" (0xc652cac0)
"call-interactively" (0xc652cc80)
"command-execute" (0xc652cdd8)
The hung process consumes no CPU according to `top`, but if I attempt to
continue execution, SIGTTOU is raised repeatedly; telling gdb to
silently pass the signal through to emacs leaves gdb working 100% CPU
and emacs working 40% CPU, so I suspect SIGTTOU is being raised
continuously.
Sending SIGUSR2 from the command-line has no visible effect, other than
to make gdb hang when attempting to continue execution after attaching
to the process; killing gdb with SIGTREM leaves the error message:
Detaching from program: /usr/bin/emacs24-x, process 122941
Exception ignored in: <gdb.GdbOutputFile object at 0x7f30a0375588>
Traceback (most recent call last):
File "/usr/share/gdb/python/gdb/__init__.py", line 43, in flush
def flush(self):
KeyboardInterrupt
Sending SIGTERM to emacs has no effect.
I suspect the call to `suspend-emacs` is due to my unsuccessful ^Z
attempt, so the real problem is likely above that point in the stack
trace. Next time this happens I will use the techniques mentioned in
/usr/share/emacs/24.5/etc/DEBUG to hopefully obtain more information,
without the added confound of attempting ^Z or ^G^G^G first.
The full backtrace is given at the end of this message.
Thanks,
Ryan
Output of report-emacs-bug:
In GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
of 2016-04-17 on lgw01-04, modified by Debian
System Description: Ubuntu 16.04.1 LTS
Configured using:
`configure --build x86_64-linux-gnu --prefix=/usr
--sharedstatedir=/var/lib --libexecdir=/usr/lib
--localstatedir=/var/lib --infodir=/usr/share/info
--mandir=/usr/share/man --with-pop=yes
--enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-lisp:/usr/share/emacs/site-lisp
--build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
--libexecdir=/usr/lib --localstatedir=/var/lib
--infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes
--enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-lisp:/usr/share/emacs/site-lisp
--with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars
'CFLAGS=-g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
-D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro''
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: C++/l
Minor modes in effect:
sticky-control-mode: t
delete-selection-mode: t
terminal-mouse-mode: t
column-enforce-mode: t
tooltip-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
abbrev-mode: t
Load-path shadows:
/usr/share/emacs/24.5/site-lisp/debian-startup hides
/usr/share/emacs/site-lisp/debian-startup
~ryan/.el/mouse hides /usr/share/emacs/24.5/lisp/mouse
~ryan/.el/ruby-mode hides /usr/share/emacs/24.5/lisp/progmodes/ruby-mode
Features:
(vc-dispatcher vc-hg cc-langs cc-mode cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs ebuff-menu help-mode pp
shadow sort gnus-util mail-extr emacsbug message 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 xterm byte-opt bytecomp byte-compile cl-extra cconv
sticky-control delsel cus-start cus-load terminal-mouse minibuf-isearch
advice help-fns xcscope org org-macro org-footnote org-pcomplete
pcomplete org-list org-faces org-entities time-date noutline outline
org-version ob-emacs-lisp ob ob-tangle ob-ref ob-lob ob-table ob-exp
org-src ob-keys ob-comint ob-core ob-eval org-compat org-macs
org-loaddefs format-spec find-func cal-menu easymenu calendar
cal-loaddefs two-mode-mode lua-mode edmacro kmacro comint ansi-color
ring column-enforce-mode easy-mmode cl-macs cl gv cl-loaddefs cl-lib
xterm-extras tooltip electric uniquify 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 prog-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 nadvice
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
gfilenotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty emacs)
(gdb) bt full
#0 0x00007f60bf9a8960 in __GI_tcsetattr (fd=fd@entry=5,
optional_actions=optional_actions@entry=1,
termios_p=termios_p@entry=0x7ffec652c780) at
../sysdeps/unix/sysv/linux/tcsetattr.c:83
resultvar = 18446744073709551104
k_termios = {c_iflag = 10241, c_oflag = 1, c_cflag = 191,
c_lflag = 2609, c_line = 0 '\000', c_cc =
"\a\a\177\025\004\000\001\000\000\000\000\377\000\000\000\000\377\000"}
k_termios_old = {c_iflag = 11264, c_oflag = 5, c_cflag = 191,
c_lflag = 35377, c_line = 0 '\000', c_cc =
"\003\034\177\025\004\000\001\000\021\023\032\377\022\017\027\000\377\000"}
retval = <optimized out>
#1 0x0000000000502755 in emacs_set_tty (fd=5,
settings=settings@entry=0x7ffec652c780, flushp=false) at sysdep.c:777
i = 0
#2 0x0000000000503a01 in init_sys_modes (tty_out=0x13e0960) at
sysdep.c:1006
tty = {main = {c_iflag = 10241, c_oflag = 1, c_cflag = 191,
c_lflag = 2609, c_line = 0 '\000',
c_cc =
"\a\a\177\025\004\000\001\000\000\000\000\377\000\000\000\000\377",
'\000' <repeats 14 times>, c_ispeed = 15, c_ospeed = 15}}
tty_out = 0x13e0960
#3 0x0000000000503cf8 in init_all_sys_modes () at sysdep.c:834
tty = 0x13e0960
#4 0x000000000055c4a2 in unbind_to (count=count@entry=9,
value=12392562) at eval.c:3310
quitf = 12392562
#5 0x00000000004f93ca in Fsuspend_emacs (stuffstring=12392562) at
keyboard.c:10179
old_height = 70
old_width = 201
width = 0
height = 0
hook = 15877554
#6 0x000000000055d937 in Ffuncall (nargs=<optimized out>,
args=args@entry=0x7ffec652c908) at eval.c:2811
fun = 8669533
original_fun = 12439794
numargs = <optimized out>
val = <optimized out>
internal_args = 0x7ffec652c880
i = <optimized out>
count = 8
#7 0x0000000000592b23 in exec_byte_code (bytestr=<optimized out>,
vector=9879957, maxdepth=<optimized out>, args_template=<optimized out>,
nargs=nargs@entry=0, args=<optimized out>, args@entry=0x0)
at bytecode.c:916
targets = {0x592c90 <exec_byte_code+1040>, 0x593c28
<exec_byte_code+5032>, 0x593c30 <exec_byte_code+5040>, 0x593c38
<exec_byte_code+5048>, 0x592a78 <exec_byte_code+504>,
0x592a80 <exec_byte_code+512>, 0x594320
<exec_byte_code+6816>, 0x5942c0 <exec_byte_code+6720>, 0x594410
<exec_byte_code+7056>, 0x5943e8 <exec_byte_code+7016>,
0x594520 <exec_byte_code+7328>, 0x594408
<exec_byte_code+7048>, 0x592bb0 <exec_byte_code+816>, 0x592bb0
<exec_byte_code+816>, 0x593fa0 <exec_byte_code+5920>, 0x5943c0
<exec_byte_code+6976>,
0x5941e0 <exec_byte_code+6496>, 0x5941e8
<exec_byte_code+6504>, 0x593bb0 <exec_byte_code+4912>, 0x594230
<exec_byte_code+6576>, 0x592c18 <exec_byte_code+920>, 0x592c20
<exec_byte_code+928>,
0x592ce0 <exec_byte_code+1120>, 0x5941f0
<exec_byte_code+6512>, 0x594260 <exec_byte_code+6624>, 0x594268
<exec_byte_code+6632>, 0x5942a8 <exec_byte_code+6696>,
0x594270 <exec_byte_code+6640>, 0x592ab8
<exec_byte_code+568>, 0x592ac0 <exec_byte_code+576>, 0x594218
<exec_byte_code+6552>, 0x594238 <exec_byte_code+6584>, 0x5942a0
<exec_byte_code+6688>,
0x5942b0 <exec_byte_code+6704>, 0x5942b8
<exec_byte_code+6712>, 0x592e10 <exec_byte_code+1424>, 0x592b00
<exec_byte_code+640>, 0x592b00 <exec_byte_code+640>, 0x5943f0
<exec_byte_code+7024>,
0x594278 <exec_byte_code+6648>, 0x593c70
<exec_byte_code+5104>, 0x593c68 <exec_byte_code+5096>, 0x593c78
<exec_byte_code+5112>, 0x592e30 <exec_byte_code+1456>,
0x592b40 <exec_byte_code+704>, 0x592b40 <exec_byte_code+704>,
0x592e18 <exec_byte_code+1432>, 0x593c40 <exec_byte_code+5056>, 0x593e90
<exec_byte_code+5648>, 0x593e40 <exec_byte_code+5568>,
0x593ce0 <exec_byte_code+5216>, 0x592c90
<exec_byte_code+1040>, 0x592c90 <exec_byte_code+1040>, 0x592c90
<exec_byte_code+1040>, 0x592c90 <exec_byte_code+1040>,
0x592c90 <exec_byte_code+1040>, 0x593360
<exec_byte_code+2784>, 0x5933f0 <exec_byte_code+2928>, 0x593438
<exec_byte_code+3000>, 0x593480 <exec_byte_code+3072>,
0x5934c8 <exec_byte_code+3144>, 0x594100
<exec_byte_code+6272>, 0x594040 <exec_byte_code+6080>, 0x593510
<exec_byte_code+3216>, 0x5940c0 <exec_byte_code+6208>,
0x594080 <exec_byte_code+6144>, 0x593548
<exec_byte_code+3272>, 0x593580 <exec_byte_code+3328>, 0x5935b0
<exec_byte_code+3376>, 0x5935f0 <exec_byte_code+3440>,
0x593628 <exec_byte_code+3496>, 0x5936b0
<exec_byte_code+3632>, 0x5936e0 <exec_byte_code+3680>, 0x593720
<exec_byte_code+3744>, 0x593760 <exec_byte_code+3808>,
0x593790 <exec_byte_code+3856>, 0x5937c0
<exec_byte_code+3904>, 0x593800 <exec_byte_code+3968>, 0x593840
<exec_byte_code+4032>, 0x593880 <exec_byte_code+4096>,
0x5938c0 <exec_byte_code+4160>, 0x5938f8
<exec_byte_code+4216>, 0x593930 <exec_byte_code+4272>, 0x5939b8
<exec_byte_code+4408>, 0x5939f8 <exec_byte_code+4472>,
0x593a38 <exec_byte_code+4536>, 0x593af0
<exec_byte_code+4720>, 0x593b30 <exec_byte_code+4784>, 0x593b70
<exec_byte_code+4848>, 0x594528 <exec_byte_code+7336>,
0x594568 <exec_byte_code+7400>, 0x5945a0
<exec_byte_code+7456>, 0x5945d8 <exec_byte_code+7512>, 0x594610
<exec_byte_code+7568>, 0x594648 <exec_byte_code+7624>,
0x594680 <exec_byte_code+7680>, 0x594730
<exec_byte_code+7856>, 0x592b80 <exec_byte_code+768>, 0x594770
<exec_byte_code+7920>, 0x5947a0 <exec_byte_code+7968>,
0x594820 <exec_byte_code+8096>, 0x594860
<exec_byte_code+8160>, 0x5948a0 <exec_byte_code+8224>, 0x5948d0
<exec_byte_code+8272>, 0x594900 <exec_byte_code+8320>,
0x594930 <exec_byte_code+8368>, 0x594960
<exec_byte_code+8416>, 0x592c90 <exec_byte_code+1040>, 0x594990
<exec_byte_code+8464>, 0x5949c0 <exec_byte_code+8512>,
0x5949f0 <exec_byte_code+8560>, 0x594a20
<exec_byte_code+8608>, 0x594a50 <exec_byte_code+8656>, 0x594a80
<exec_byte_code+8704>, 0x592b80 <exec_byte_code+768>,
0x592c90 <exec_byte_code+1040>, 0x594ab0
<exec_byte_code+8752>, 0x594af0 <exec_byte_code+8816>, 0x594b20
<exec_byte_code+8864>, 0x594b50 <exec_byte_code+8912>,
0x594b90 <exec_byte_code+8976>, 0x594bd0
<exec_byte_code+9040>, 0x594c00 <exec_byte_code+9088>, 0x594cd0
<exec_byte_code+9296>, 0x594d10 <exec_byte_code+9360>,
0x594d50 <exec_byte_code+9424>, 0x594d90
<exec_byte_code+9488>, 0x594dc0 <exec_byte_code+9536>, 0x592c90
<exec_byte_code+1040>, 0x5944d0 <exec_byte_code+7248>,
0x592e68 <exec_byte_code+1512>, 0x593fb8
<exec_byte_code+5944>, 0x592f08 <exec_byte_code+1672>, 0x592fc0
<exec_byte_code+1856>, 0x593040 <exec_byte_code+1984>,
0x593c80 <exec_byte_code+5120>, 0x5944b0
<exec_byte_code+7216>, 0x592cf8 <exec_byte_code+1144>, 0x594418
<exec_byte_code+7064>, 0x594448 <exec_byte_code+7112>,
0x593e10 <exec_byte_code+5520>, 0x593e50
<exec_byte_code+5584>, 0x593ec0 <exec_byte_code+5696>, 0x593f10
<exec_byte_code+5776>, 0x593f50 <exec_byte_code+5840>,
0x593300 <exec_byte_code+2688>, 0x592e38
<exec_byte_code+1464>, 0x594df0 <exec_byte_code+9584>, 0x594e30
<exec_byte_code+9648>, 0x595048 <exec_byte_code+10184>,
0x595070 <exec_byte_code+10224>, 0x5950a0
<exec_byte_code+10272>, 0x5950d0 <exec_byte_code+10320>, 0x595110
<exec_byte_code+10384>, 0x595150 <exec_byte_code+10448>,
0x595190 <exec_byte_code+10512>, 0x5951d0
<exec_byte_code+10576>, 0x594e60 <exec_byte_code+9696>, 0x594ea0
<exec_byte_code+9760>, 0x594ee0 <exec_byte_code+9824>,
0x594f10 <exec_byte_code+9872>, 0x594f50
<exec_byte_code+9936>, 0x594f90 <exec_byte_code+10000>, 0x594fd0
<exec_byte_code+10064>, 0x595010 <exec_byte_code+10128>,
0x5946b8 <exec_byte_code+7736>, 0x5946f0
<exec_byte_code+7792>, 0x593bb8 <exec_byte_code+4920>, 0x593bf0
<exec_byte_code+4976>, 0x592c90 <exec_byte_code+1040>,
0x5930f0 <exec_byte_code+2160>, 0x593178
<exec_byte_code+2296>, 0x5931e8 <exec_byte_code+2408>, 0x593288
<exec_byte_code+2568>, 0x594148 <exec_byte_code+6344>,
0x593660 <exec_byte_code+3552>, 0x593968
<exec_byte_code+4328>, 0x5947d0 <exec_byte_code+8016>, 0x594370
<exec_byte_code+6896>, 0x592d28 <exec_byte_code+1192>,
0x592c90 <exec_byte_code+1040>, 0x592c90
<exec_byte_code+1040>, 0x592dc0 <exec_byte_code+1344>, 0x592c90
<exec_byte_code+1040>, 0x592c90 <exec_byte_code+1040>,
0x592c90 <exec_byte_code+1040>, 0x592c90
<exec_byte_code+1040>, 0x592c90 <exec_byte_code+1040>, 0x592c90
<exec_byte_code+1040>, 0x592c90 <exec_byte_code+1040>,
0x592c90 <exec_byte_code+1040>, 0x592c90
<exec_byte_code+1040>, 0x592d88 <exec_byte_code+1288> <repeats 64 times>}
count = <optimized out>
op = <optimized out>
vectorp = 0x96c198 <pure+1181624>
stack = {pc = 0xa96f4a <pure+2405738> "\202'", byte_string =
9879921, byte_string_start = 0xa96f2d <pure+2405709> "\301\302
!\211\030\303>\203\020", next = 0x7ffec652cd00}
top = 0x7ffec652c908
result = <optimized out>
type = <optimized out>
#8 0x000000000055d3af in funcall_lambda (fun=9879869,
nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x7ffec652cac0) at
eval.c:3044
val = <optimized out>
syms_left = 12392562
lexenv = 12392562
i = <optimized out>
optional = <optimized out>
rest = <optimized out>
#9 0x000000000055d74b in Ffuncall (nargs=nargs@entry=1,
args=args@entry=0x7ffec652cab8) at eval.c:2872
fun = <optimized out>
original_fun = 16024210
numargs = 0
val = <optimized out>
internal_args = <optimized out>
i = <optimized out>
count = 6
#10 0x000000000055eef7 in apply1 (fn=fn@entry=16024210,
arg=arg@entry=12392562) at eval.c:2577
gcpro1 = <optimized out>
#11 0x00000000005595b1 in Fcall_interactively (function=16024210,
record_flag=12392562, keys=12427517) at callint.c:378
input = <optimized out>
funval = <optimized out>
events = <optimized out>
args = <optimized out>
visargs = <optimized out>
specs = 12392562
filter_specs = <optimized out>
teml = <optimized out>
up_event = <optimized out>
enable = <optimized out>
next_event = <optimized out>
prefix_arg = 12392562
string = 0x0
tem = <optimized out>
varies = <optimized out>
i = <optimized out>
nargs = <optimized out>
mark = <optimized out>
arg_from_tty = false
gcpro3 = <optimized out>
gcpro4 = <optimized out>
key_count = <optimized out>
record_then_fail = false
save_this_command = 16024210
save_last_command = 16518402
save_this_original_command = 16024210
save_real_this_command = 16024210
#12 0x000000000055d91d in Ffuncall (nargs=<optimized out>,
args=args@entry=0x7ffec652cc78) at eval.c:2818
fun = 11573845
original_fun = 12529666
numargs = <optimized out>
val = <optimized out>
internal_args = 0x7ffec652cc80
i = <optimized out>
count = 4
#13 0x0000000000592b23 in exec_byte_code (bytestr=<optimized out>,
vector=9616213, maxdepth=<optimized out>, args_template=<optimized out>,
nargs=nargs@entry=1, args=<optimized out>,
args@entry=0x92bb31 <pure+917841>) at bytecode.c:916
targets = {0x592c90 <exec_byte_code+1040>, 0x593c28
<exec_byte_code+5032>, 0x593c30 <exec_byte_code+5040>, 0x593c38
<exec_byte_code+5048>, 0x592a78 <exec_byte_code+504>,
0x592a80 <exec_byte_code+512>, 0x594320
<exec_byte_code+6816>, 0x5942c0 <exec_byte_code+6720>, 0x594410
<exec_byte_code+7056>, 0x5943e8 <exec_byte_code+7016>,
0x594520 <exec_byte_code+7328>, 0x594408
<exec_byte_code+7048>, 0x592bb0 <exec_byte_code+816>, 0x592bb0
<exec_byte_code+816>, 0x593fa0 <exec_byte_code+5920>, 0x5943c0
<exec_byte_code+6976>,
0x5941e0 <exec_byte_code+6496>, 0x5941e8
<exec_byte_code+6504>, 0x593bb0 <exec_byte_code+4912>, 0x594230
<exec_byte_code+6576>, 0x592c18 <exec_byte_code+920>, 0x592c20
<exec_byte_code+928>,
0x592ce0 <exec_byte_code+1120>, 0x5941f0
<exec_byte_code+6512>, 0x594260 <exec_byte_code+6624>, 0x594268
<exec_byte_code+6632>, 0x5942a8 <exec_byte_code+6696>,
0x594270 <exec_byte_code+6640>, 0x592ab8
<exec_byte_code+568>, 0x592ac0 <exec_byte_code+576>, 0x594218
<exec_byte_code+6552>, 0x594238 <exec_byte_code+6584>, 0x5942a0
<exec_byte_code+6688>,
0x5942b0 <exec_byte_code+6704>, 0x5942b8
<exec_byte_code+6712>, 0x592e10 <exec_byte_code+1424>, 0x592b00
<exec_byte_code+640>, 0x592b00 <exec_byte_code+640>, 0x5943f0
<exec_byte_code+7024>,
0x594278 <exec_byte_code+6648>, 0x593c70
<exec_byte_code+5104>, 0x593c68 <exec_byte_code+5096>, 0x593c78
<exec_byte_code+5112>, 0x592e30 <exec_byte_code+1456>,
0x592b40 <exec_byte_code+704>, 0x592b40 <exec_byte_code+704>,
0x592e18 <exec_byte_code+1432>, 0x593c40 <exec_byte_code+5056>, 0x593e90
<exec_byte_code+5648>, 0x593e40 <exec_byte_code+5568>,
0x593ce0 <exec_byte_code+5216>, 0x592c90
<exec_byte_code+1040>, 0x592c90 <exec_byte_code+1040>, 0x592c90
<exec_byte_code+1040>, 0x592c90 <exec_byte_code+1040>,
0x592c90 <exec_byte_code+1040>, 0x593360
<exec_byte_code+2784>, 0x5933f0 <exec_byte_code+2928>, 0x593438
<exec_byte_code+3000>, 0x593480 <exec_byte_code+3072>,
0x5934c8 <exec_byte_code+3144>, 0x594100
<exec_byte_code+6272>, 0x594040 <exec_byte_code+6080>, 0x593510
<exec_byte_code+3216>, 0x5940c0 <exec_byte_code+6208>,
0x594080 <exec_byte_code+6144>, 0x593548
<exec_byte_code+3272>, 0x593580 <exec_byte_code+3328>, 0x5935b0
<exec_byte_code+3376>, 0x5935f0 <exec_byte_code+3440>,
0x593628 <exec_byte_code+3496>, 0x5936b0
<exec_byte_code+3632>, 0x5936e0 <exec_byte_code+3680>, 0x593720
<exec_byte_code+3744>, 0x593760 <exec_byte_code+3808>,
0x593790 <exec_byte_code+3856>, 0x5937c0
<exec_byte_code+3904>, 0x593800 <exec_byte_code+3968>, 0x593840
<exec_byte_code+4032>, 0x593880 <exec_byte_code+4096>,
0x5938c0 <exec_byte_code+4160>, 0x5938f8
<exec_byte_code+4216>, 0x593930 <exec_byte_code+4272>, 0x5939b8
<exec_byte_code+4408>, 0x5939f8 <exec_byte_code+4472>,
0x593a38 <exec_byte_code+4536>, 0x593af0
<exec_byte_code+4720>, 0x593b30 <exec_byte_code+4784>, 0x593b70
<exec_byte_code+4848>, 0x594528 <exec_byte_code+7336>,
0x594568 <exec_byte_code+7400>, 0x5945a0
<exec_byte_code+7456>, 0x5945d8 <exec_byte_code+7512>, 0x594610
<exec_byte_code+7568>, 0x594648 <exec_byte_code+7624>,
0x594680 <exec_byte_code+7680>, 0x594730
<exec_byte_code+7856>, 0x592b80 <exec_byte_code+768>, 0x594770
<exec_byte_code+7920>, 0x5947a0 <exec_byte_code+7968>,
0x594820 <exec_byte_code+8096>, 0x594860
<exec_byte_code+8160>, 0x5948a0 <exec_byte_code+8224>, 0x5948d0
<exec_byte_code+8272>, 0x594900 <exec_byte_code+8320>,
0x594930 <exec_byte_code+8368>, 0x594960
<exec_byte_code+8416>, 0x592c90 <exec_byte_code+1040>, 0x594990
<exec_byte_code+8464>, 0x5949c0 <exec_byte_code+8512>,
0x5949f0 <exec_byte_code+8560>, 0x594a20
<exec_byte_code+8608>, 0x594a50 <exec_byte_code+8656>, 0x594a80
<exec_byte_code+8704>, 0x592b80 <exec_byte_code+768>,
0x592c90 <exec_byte_code+1040>, 0x594ab0
<exec_byte_code+8752>, 0x594af0 <exec_byte_code+8816>, 0x594b20
<exec_byte_code+8864>, 0x594b50 <exec_byte_code+8912>,
0x594b90 <exec_byte_code+8976>, 0x594bd0
<exec_byte_code+9040>, 0x594c00 <exec_byte_code+9088>, 0x594cd0
<exec_byte_code+9296>, 0x594d10 <exec_byte_code+9360>,
0x594d50 <exec_byte_code+9424>, 0x594d90
<exec_byte_code+9488>, 0x594dc0 <exec_byte_code+9536>, 0x592c90
<exec_byte_code+1040>, 0x5944d0 <exec_byte_code+7248>,
0x592e68 <exec_byte_code+1512>, 0x593fb8
<exec_byte_code+5944>, 0x592f08 <exec_byte_code+1672>, 0x592fc0
<exec_byte_code+1856>, 0x593040 <exec_byte_code+1984>,
0x593c80 <exec_byte_code+5120>, 0x5944b0
<exec_byte_code+7216>, 0x592cf8 <exec_byte_code+1144>, 0x594418
<exec_byte_code+7064>, 0x594448 <exec_byte_code+7112>,
0x593e10 <exec_byte_code+5520>, 0x593e50
<exec_byte_code+5584>, 0x593ec0 <exec_byte_code+5696>, 0x593f10
<exec_byte_code+5776>, 0x593f50 <exec_byte_code+5840>,
0x593300 <exec_byte_code+2688>, 0x592e38
<exec_byte_code+1464>, 0x594df0 <exec_byte_code+9584>, 0x594e30
<exec_byte_code+9648>, 0x595048 <exec_byte_code+10184>,
0x595070 <exec_byte_code+10224>, 0x5950a0
<exec_byte_code+10272>, 0x5950d0 <exec_byte_code+10320>, 0x595110
<exec_byte_code+10384>, 0x595150 <exec_byte_code+10448>,
0x595190 <exec_byte_code+10512>, 0x5951d0
<exec_byte_code+10576>, 0x594e60 <exec_byte_code+9696>, 0x594ea0
<exec_byte_code+9760>, 0x594ee0 <exec_byte_code+9824>,
0x594f10 <exec_byte_code+9872>, 0x594f50
<exec_byte_code+9936>, 0x594f90 <exec_byte_code+10000>, 0x594fd0
<exec_byte_code+10064>, 0x595010 <exec_byte_code+10128>,
0x5946b8 <exec_byte_code+7736>, 0x5946f0
<exec_byte_code+7792>, 0x593bb8 <exec_byte_code+4920>, 0x593bf0
<exec_byte_code+4976>, 0x592c90 <exec_byte_code+1040>,
0x5930f0 <exec_byte_code+2160>, 0x593178
<exec_byte_code+2296>, 0x5931e8 <exec_byte_code+2408>, 0x593288
<exec_byte_code+2568>, 0x594148 <exec_byte_code+6344>,
0x593660 <exec_byte_code+3552>, 0x593968
<exec_byte_code+4328>, 0x5947d0 <exec_byte_code+8016>, 0x594370
<exec_byte_code+6896>, 0x592d28 <exec_byte_code+1192>,
0x592c90 <exec_byte_code+1040>, 0x592c90
<exec_byte_code+1040>, 0x592dc0 <exec_byte_code+1344>, 0x592c90
<exec_byte_code+1040>, 0x592c90 <exec_byte_code+1040>,
0x592c90 <exec_byte_code+1040>, 0x592c90
<exec_byte_code+1040>, 0x592c90 <exec_byte_code+1040>, 0x592c90
<exec_byte_code+1040>, 0x592c90 <exec_byte_code+1040>,
0x592c90 <exec_byte_code+1040>, 0x592c90
<exec_byte_code+1040>, 0x592d88 <exec_byte_code+1288> <repeats 64 times>}
count = <optimized out>
op = <optimized out>
vectorp = 0x92bb58 <pure+917880>
stack = {pc = 0xab7a57 <pure+2539639> "\006\006\071\203\233",
byte_string = 9616177, byte_string_start = 0xab79e3 <pure+2539523>
"\306\020\211?\205\f", next = 0x0}
top = 0x7ffec652cc78
result = <optimized out>
type = <optimized out>
#14 0x000000000055d447 in funcall_lambda (fun=0, nargs=nargs@entry=1,
arg_vector=0x92bb31 <pure+917841>, arg_vector@entry=0x7ffec652cdd8) at
eval.c:2978
val = <optimized out>
syms_left = <optimized out>
lexenv = <optimized out>
i = <optimized out>
optional = <optimized out>
rest = <optimized out>
#15 0x000000000055d74b in Ffuncall (nargs=nargs@entry=2,
args=args@entry=0x7ffec652cdd0) at eval.c:2872
fun = <optimized out>
original_fun = 12436386
numargs = 1
val = <optimized out>
internal_args = <optimized out>
i = <optimized out>
count = 3
#16 0x000000000055da6a in call1 (fn=<optimized out>, arg1=<optimized
out>) at eval.c:2610
ret_ungc_val = <optimized out>
gcpro1 = {next = <optimized out>, var = <optimized out>, nvars = 2}
args = {12436386, 16024210}
#17 0x00000000004f82ed in command_loop_1 () at keyboard.c:1560
cmd = <optimized out>
keybuf = {104, 76, 268, 236, 212, 268, 9263360,
140732225736448, 12392562, 27847414, 1, 140732225737104, 27847414,
5633300, 12439986, 27847414, 8698369, 12392562, 0, -8156672133596453632,
27847414, 5172221, 140732225736448, 12392562, 12392562,
5172540, 12640768, 5550502, 12516322, 64}
i = <optimized out>
prev_modiff = 392
prev_buffer = 0x1a08010
#18 0x000000000055bba7 in internal_condition_case
(bfun=bfun@entry=0x4f7f50 <command_loop_1>, handlers=<optimized out>,
hfun=hfun@entry=0x4eec30 <cmd_error>) at eval.c:1348
val = <optimized out>
c = <optimized out>
#19 0x00000000004ea13e in command_loop_2 (ignore=ignore@entry=12392562)
at keyboard.c:1178
val = -512
#20 0x000000000055ba8b in internal_catch (tag=12440034,
func=func@entry=0x4ea120 <command_loop_2>, arg=12392562) at eval.c:1112
val = <optimized out>
c = <optimized out>
#21 0x00000000004ee817 in command_loop () at keyboard.c:1157
No locals.
#22 recursive_edit_1 () at keyboard.c:778
val = 20613024
#23 0x00000000004eeb58 in Frecursive_edit () at keyboard.c:849
buffer = <optimized out>
#24 0x0000000000418619 in main (argc=<optimized out>,
argv=0x7ffec652d198) at emacs.c:1642
dummy = 0
stack_bottom_variable = 0 '\000'
do_initial_setlocale = <optimized out>
dumping = <optimized out>
skip_args = 1
rlim = {rlim_cur = 8720000, rlim_max = 18446744073709551615}
no_loadup = false
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x0
original_pwd = <optimized out>
[-- Attachment #2: emacs-freeze.png --]
[-- Type: image/png, Size: 11668 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#25119: Acknowledgement (Hard freeze when switching to indirect buffer)
[not found] ` <handler.25119.B.148095640113649.ack@debbugs.gnu.org>
@ 2016-12-05 17:37 ` Ryan Johnson
2016-12-05 18:44 ` Eli Zaretskii
0 siblings, 1 reply; 7+ messages in thread
From: Ryan Johnson @ 2016-12-05 17:37 UTC (permalink / raw)
To: 25119
[-- Attachment #1: Type: text/plain, Size: 2613 bytes --]
Apologies, it looks like I was debugging the wrong emacs instance in my
initial report.
The correct output of gdb `bt full` is attached.
(gdb) xbacktrace
"read-key-sequence-vector" (0x57f89050)
0x4872440 PVEC_COMPILED
"funcall" (0x57f89190)
"read-key" (0x57f89498)
"read-char-choice" (0x57f89600)
"ask-user-about-supersession-threat" (0x57f897b8)
"put-text-property" (0x57f8bae8)
"jit-lock-fontify-now" (0x57f8bc78)
"jit-lock-function" (0x57f8be38)
"redisplay_internal (C function)" (0xb856a8)
This time, sending SIGUSR2 worked (sort of), and produced:
> Debugger entered--beginning evaluation of function call form:
> * (funcall #[0 "\302\301!\210\303\300!\207" [(keymap #^[nil nil keymap
> #^^[3 0 set-mark-command move-beginning-of-line backward-char
> mode-specific-command-prefix delete-c$
> #^^[3 0 set-mark-command move-beginning-of-line backward-char
> mode-specific-command-prefix delete-c$
> read-key(#("AlphaTree.cpp changed on disk; really edit the buffer?
> (y, n, r or C-h) " 0 72 (face $
> read-char-choice("AlphaTree.cpp changed on disk; really edit the
> buffer? (y, n, r or C-h) " (121 $
> ask-user-about-supersession-threat("/home/ryan/projects/lb-alpha-tree/BloxData/blox/alg/alpha/Alp$
> put-text-property(2077 2599 fontified t)
> jit-lock-fontify-now(2080 2580)
> jit-lock-function(2080)
> redisplay_internal\ \(C\ function\)()
Unfortunately, the lisp debugger window seems to have line truncation
enabled. Emacs is not responsive after that, reporting a timer error and
complaining afterward that it doesn't recognize any keystrokes:
> Error running timer: (no-catch read-key [24])
> a is undefined
> C-c is undefined
> M-x is undefined
Hitting `q` does trigger the response "Back to top level." ... but then
emacs hangs again, until I re-send SIGUSR2.
The hang usually occurs when I switch to an indirect buffer I've not
used in a while (overnight, in this case), and on a shared machine where
people often run memory-intensive workloads. The backtrace above
suggests that the file has been modified outside emacs in the meantime,
which is probably true, since I frequently use patch queues.
I start to suspect that there's some sort of race here, where switching
to the buffer is slow (perhaps due to page faults) and a different
thread tries to process subsequent keystrokes, which triggers the "$FILE
changed on disk; really edit the buffer?" message while the mini-buffer
is still tied up with the "switching to..." message. I will admit I
never tried typing "y" or "n" in response to the hang... I'll be sure to
try that next time.
Regards,
Ryan
[-- Attachment #2: emacs-backtrace.txt.gz --]
[-- Type: application/x-gzip, Size: 22980 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#25119: Acknowledgement (Hard freeze when switching to indirect buffer)
2016-12-05 17:37 ` bug#25119: Acknowledgement (Hard freeze when switching to indirect buffer) Ryan Johnson
@ 2016-12-05 18:44 ` Eli Zaretskii
2016-12-05 20:14 ` Ryan Johnson
0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2016-12-05 18:44 UTC (permalink / raw)
To: Ryan Johnson; +Cc: 25119
> From: Ryan Johnson <scovich@gmail.com>
> Date: Mon, 5 Dec 2016 10:37:02 -0700
>
> (gdb) xbacktrace
> "read-key-sequence-vector" (0x57f89050)
> 0x4872440 PVEC_COMPILED
> "funcall" (0x57f89190)
> "read-key" (0x57f89498)
> "read-char-choice" (0x57f89600)
> "ask-user-about-supersession-threat" (0x57f897b8)
> "put-text-property" (0x57f8bae8)
> "jit-lock-fontify-now" (0x57f8bc78)
> "jit-lock-function" (0x57f8be38)
> "redisplay_internal (C function)" (0xb856a8)
This looks like Emacs asking you whether to steal the lock from
another Emacs session that is editing the same file.
> The hang usually occurs when I switch to an indirect buffer I've not
> used in a while (overnight, in this case), and on a shared machine where
> people often run memory-intensive workloads. The backtrace above
> suggests that the file has been modified outside emacs in the meantime,
> which is probably true, since I frequently use patch queues.
>
> I start to suspect that there's some sort of race here, where switching
> to the buffer is slow (perhaps due to page faults) and a different
> thread tries to process subsequent keystrokes, which triggers the "$FILE
> changed on disk; really edit the buffer?" message while the mini-buffer
> is still tied up with the "switching to..." message.
What other thread did you have in mind? Emacs does all this in a
single thread.
> I will admit I never tried typing "y" or "n" in response to the
> hang... I'll be sure to try that next time.
Yes, a good idea.
Also, perhaps you could try a newer version of Emacs (25.1), maybe
this problem is already fixed there.
Thanks.
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#25119: Acknowledgement (Hard freeze when switching to indirect buffer)
2016-12-05 18:44 ` Eli Zaretskii
@ 2016-12-05 20:14 ` Ryan Johnson
2016-12-05 20:25 ` Eli Zaretskii
2016-12-08 2:00 ` Ryan Johnson
0 siblings, 2 replies; 7+ messages in thread
From: Ryan Johnson @ 2016-12-05 20:14 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 25119
On 12/5/2016 11:44 AM, Eli Zaretskii wrote:
>> (gdb) xbacktrace
>> "read-key-sequence-vector" (0x57f89050)
>> 0x4872440 PVEC_COMPILED
>> "funcall" (0x57f89190)
>> "read-key" (0x57f89498)
>> "read-char-choice" (0x57f89600)
>> "ask-user-about-supersession-threat" (0x57f897b8)
>> "put-text-property" (0x57f8bae8)
>> "jit-lock-fontify-now" (0x57f8bc78)
>> "jit-lock-function" (0x57f8be38)
>> "redisplay_internal (C function)" (0xb856a8)
> This looks like Emacs asking you whether to steal the lock from
> another Emacs session that is editing the same file.
The message from the lisp backtrace was:
> AlphaTree.cpp changed on disk; really edit the buffer? (y, n, r or C-h)
I'm pretty sure the lock-stealing message is rather different from that,
mentioning the PID of the other emacs... but I don't remember off the
top of my head because I very rarely point two emacsen at the same file.
>> I start to suspect that there's some sort of race here, where switching
>> to the buffer is slow (perhaps due to page faults) and a different
>> thread tries to process subsequent keystrokes, which triggers the "$FILE
>> changed on disk; really edit the buffer?" message while the mini-buffer
>> is still tied up with the "switching to..." message.
> What other thread did you have in mind? Emacs does all this in a
> single thread.
Just a wild speculation, based on the fact that it was apparently stuck
waiting for input while still trying to redraw the screen. Even in a
single thread, signals might allow a self-deadlock of some kind. Or it
could be something else entirely.
> Also, perhaps you could try a newer version of Emacs (25.1), maybe
> this problem is already fixed there.
Will build it and switch over; I don't think it's available for Ubuntu
16 LTS.
Ryan
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#25119: Acknowledgement (Hard freeze when switching to indirect buffer)
2016-12-05 20:14 ` Ryan Johnson
@ 2016-12-05 20:25 ` Eli Zaretskii
2016-12-08 2:00 ` Ryan Johnson
1 sibling, 0 replies; 7+ messages in thread
From: Eli Zaretskii @ 2016-12-05 20:25 UTC (permalink / raw)
To: Ryan Johnson; +Cc: 25119
> Cc: 25119@debbugs.gnu.org
> From: Ryan Johnson <scovich@gmail.com>
> Date: Mon, 5 Dec 2016 13:14:59 -0700
>
> > This looks like Emacs asking you whether to steal the lock from
> > another Emacs session that is editing the same file.
> The message from the lisp backtrace was:
> > AlphaTree.cpp changed on disk; really edit the buffer? (y, n, r or C-h)
>
> I'm pretty sure the lock-stealing message is rather different from that,
> mentioning the PID of the other emacs... but I don't remember off the
> top of my head because I very rarely point two emacsen at the same file.
No, I think you are right, it's the message saying that the file on
disk changed by some other program. It could be that we somehow goof
with indirect buffers in that case.
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#25119: Acknowledgement (Hard freeze when switching to indirect buffer)
2016-12-05 20:14 ` Ryan Johnson
2016-12-05 20:25 ` Eli Zaretskii
@ 2016-12-08 2:00 ` Ryan Johnson
2018-05-09 23:12 ` bug#25119: Hard freeze when switching to indirect buffer Noam Postavsky
1 sibling, 1 reply; 7+ messages in thread
From: Ryan Johnson @ 2016-12-08 2:00 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 25119
On 12/5/2016 1:14 PM, Ryan Johnson wrote:
> On 12/5/2016 11:44 AM, Eli Zaretskii wrote:
>> Also, perhaps you could try a newer version of Emacs (25.1), maybe
>> this problem is already fixed there.
> Will build it and switch over; I don't think it's available for Ubuntu
> 16 LTS.
No problems so far, but it's usually a week or two between incidents.
Ryan
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#25119: Hard freeze when switching to indirect buffer
2016-12-08 2:00 ` Ryan Johnson
@ 2018-05-09 23:12 ` Noam Postavsky
0 siblings, 0 replies; 7+ messages in thread
From: Noam Postavsky @ 2018-05-09 23:12 UTC (permalink / raw)
To: Ryan Johnson; +Cc: 25119
found 25119 24.5
close 25119 25.1
quit
Ryan Johnson <scovich@gmail.com> writes:
> On 12/5/2016 1:14 PM, Ryan Johnson wrote:
>> On 12/5/2016 11:44 AM, Eli Zaretskii wrote:
>>> Also, perhaps you could try a newer version of Emacs (25.1), maybe
>>> this problem is already fixed there.
>> Will build it and switch over; I don't think it's available for
>> Ubuntu 16 LTS.
> No problems so far, but it's usually a week or two between incidents.
Presumably over a year without incident is long enough.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2018-05-09 23:12 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-12-05 16:46 bug#25119: Hard freeze when switching to indirect buffer Ryan Johnson
[not found] ` <handler.25119.B.148095640113649.ack@debbugs.gnu.org>
2016-12-05 17:37 ` bug#25119: Acknowledgement (Hard freeze when switching to indirect buffer) Ryan Johnson
2016-12-05 18:44 ` Eli Zaretskii
2016-12-05 20:14 ` Ryan Johnson
2016-12-05 20:25 ` Eli Zaretskii
2016-12-08 2:00 ` Ryan Johnson
2018-05-09 23:12 ` bug#25119: Hard freeze when switching to indirect buffer Noam Postavsky
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).