Package: emacs;
Reported by: Alex Bennée <alex.bennee <at> linaro.org>
Date: Mon, 10 May 2021 19:32:01 UTC
Severity: normal
Done: Alan Mackenzie <acm <at> muc.de>
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 48337 in the body.
You can then email your comments to 48337 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#48337; Package emacs.
(Mon, 10 May 2021 19:32:01 GMT) Full text and rfc822 format available.Alex Bennée <alex.bennee <at> linaro.org>:bug-gnu-emacs <at> gnu.org.
(Mon, 10 May 2021 19:32:01 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Alex Bennée <alex.bennee <at> linaro.org> To: bug-gnu-emacs <at> gnu.org Cc: Alan Mackenzie <acm <at> muc.de> Subject: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Mon, 10 May 2021 20:30:58 +0100
[Message part 1 (text/plain, inline)]
It seems my mail client left this in the sent folder but never actually
sent it:
I haven't been able to find a reproduction as the bug hits fairly
randomly hence I'm running in my normal init.el heavy environment.
That said there shouldn't be anything in lisp that could cause a
segfault in the core C code.
This only started happening this week after a recent update from
master (I update every Monday). The only change I could see that might
be related was f608b4b93 (Prevent the selected window being a dead
mini-window when switching frames).
Unfortunately no symbols. However both core dumps so far have seen the
same null XCAR being called from nth_minibuffer:
#0 0x00007f4384f585cb in raise (sig=sig <at> entry=11) at
../sysdeps/unix/sysv/linux/raise.c:50
set = {__val = {18446744067266837247, 0 <repeats 15 times>}}
pid = <optimized out>
tid = <optimized out>
#1 0x000055b6738bf530 in terminate_due_to_signal (sig=sig <at> entry=11,
backtrace_limit=backtrace_limit <at> entry=40) at emacs.c:437
#2 0x000055b6738bf97d in handle_fatal_signal (sig=sig <at> entry=11) at
sysdep.c:1762
#3 0x000055b6739b8ca8 in deliver_thread_signal (sig=sig <at> entry=11,
handler=0x55b6738bf972 <handle_fatal_signal>) at sysdep.c:1754
#4 0x000055b6739b8d29 in deliver_fatal_thread_signal (sig=11) at
sysdep.c:1867
fatal = <optimized out>
#5 0x000055b6739b8d29 in handle_sigsegv (sig=11, siginfo=<optimized
out>, arg=<optimized out>) at sysdep.c:1867
fatal = <optimized out>
#6 0x00007f4384f58730 in <signal handler called> () at
/lib/x86_64-linux-gnu/libpthread.so.0
#7 0x000055b6739ce0ef in XCAR (c=0x0) at lisp.h:1420
tail = 0x0
frames = <optimized out>
frame = <optimized out>
f = <optimized out>
innermost_MB = <optimized out>
#8 0x000055b6739ce0ef in nth_minibuffer (depth=<optimized out>) at
minibuf.c:972
tail = 0x0
frames = <optimized out>
frame = <optimized out>
f = <optimized out>
innermost_MB = <optimized out>
#9 0x000055b6739ce0ef in Factive_minibuffer_window () at minibuf.c:230
frames = <optimized out>
frame = <optimized out>
f = <optimized out>
innermost_MB = <optimized out>
#10 0x000055b673a1b2ab in Ffuncall (nargs=1, args=args <at> entry=0x7ffc3938eaf8)
at lisp.h:2093
fun = <optimized out>
original_fun = 0x298d0aeb5d60
funcar = <optimized out>
numargs = 0
val = <optimized out>
count = 84
#11 0x000055b673a55830 in exec_byte_code (bytestr=<optimized out>,
vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized
out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:632
op = <optimized out>
type = <optimized out>
targets = {0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a579d8
<exec_byte_code+9480>, 0x55b673a579dd <exec_byte_code+9485>, 0x55b673a579e2
<exec_byte_code+9490>, 0x55b673a55717 <exec_byte_code+583>, 0x55b673a55717
<exec_byte_code+583>, 0x55b673a579e7 <exec_byte_code+9495>, 0x55b673a57a26
<exec_byte_code+9558>, 0x55b673a56a0a <exec_byte_code+5434>, 0x55b673a56a0f
<exec_byte_code+5439>, 0x55b673a56a14 <exec_byte_code+5444>, 0x55b673a56a19
<exec_byte_code+5449>, 0x55b673a55752 <exec_byte_code+642>, 0x55b673a55758
<exec_byte_code+648>, 0x55b673a56a1e <exec_byte_code+5454>, 0x55b673a569f3
<exec_byte_code+5411>, 0x55b673a56b75 <exec_byte_code+5797>, 0x55b673a56b7a
<exec_byte_code+5802>, 0x55b673a56b7f <exec_byte_code+5807>, 0x55b673a56b84
<exec_byte_code+5812>, 0x55b673a556a4 <exec_byte_code+468>, 0x55b673a556a8
<exec_byte_code+472>, 0x55b673a56ba0 <exec_byte_code+5840>, 0x55b673a56b89
<exec_byte_code+5817>, 0x55b673a56c06 <exec_byte_code+5942>, 0x55b673a56c0b
<exec_byte_code+5947>, 0x55b673a56c10 <exec_byte_code+5952>, 0x55b673a56c15
<exec_byte_code+5957>, 0x55b673a55856 <exec_byte_code+902>, 0x55b673a55860
<exec_byte_code+912>, 0x55b673a56be2 <exec_byte_code+5906>, 0x55b673a56bef
<exec_byte_code+5919>, 0x55b673a56c3e <exec_byte_code+5998>, 0x55b673a56c43
<exec_byte_code+6003>, 0x55b673a56c48 <exec_byte_code+6008>, 0x55b673a56c4d
<exec_byte_code+6013>, 0x55b673a5580f <exec_byte_code+831>, 0x55b673a55810
<exec_byte_code+832>, 0x55b673a56c1a <exec_byte_code+5962>, 0x55b673a56c27
<exec_byte_code+5975>, 0x55b673a56c76 <exec_byte_code+6054>, 0x55b673a56c7b
<exec_byte_code+6059>, 0x55b673a56c80 <exec_byte_code+6064>, 0x55b673a56c85
<exec_byte_code+6069>, 0x55b673a557b5 <exec_byte_code+741>, 0x55b673a557b8
<exec_byte_code+744>, 0x55b673a56c52 <exec_byte_code+6018>, 0x55b673a56c5f
<exec_byte_code+6031>, 0x55b673a57355 <exec_byte_code+7813>, 0x55b673a570a0
<exec_byte_code+7120>, 0x55b673a57024 <exec_byte_code+6996>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57ebb <exec_byte_code+10731>,
0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57ebb <exec_byte_code+10731>,
0x55b673a55aae <exec_byte_code+1502>, 0x55b673a55b08 <exec_byte_code+1592>,
0x55b673a55b4e <exec_byte_code+1662>, 0x55b673a55b97 <exec_byte_code+1735>,
0x55b673a55be0 <exec_byte_code+1808>, 0x55b673a56aac <exec_byte_code+5596>,
0x55b673a56af7 <exec_byte_code+5671>, 0x55b673a55c28 <exec_byte_code+1880>,
0x55b673a56a70 <exec_byte_code+5536>, 0x55b673a56b39 <exec_byte_code+5737>,
0x55b673a55c5c <exec_byte_code+1932>, 0x55b673a55c9e <exec_byte_code+1998>,
0x55b673a55cd0 <exec_byte_code+2048>, 0x55b673a55d12 <exec_byte_code+2114>,
0x55b673a55d51 <exec_byte_code+2177>, 0x55b673a55ddf <exec_byte_code+2319>,
0x55b673a55e11 <exec_byte_code+2369>, 0x55b673a55e53 <exec_byte_code+2435>,
0x55b673a55e99 <exec_byte_code+2505>, 0x55b673a55ecb <exec_byte_code+2555>,
0x55b673a55efd <exec_byte_code+2605>, 0x55b673a55f3f <exec_byte_code+2671>,
0x55b673a55f81 <exec_byte_code+2737>, 0x55b673a55fc3 <exec_byte_code+2803>,
0x55b673a56009 <exec_byte_code+2873>, 0x55b673a56045 <exec_byte_code+2933>,
0x55b673a56081 <exec_byte_code+2993>, 0x55b673a56108 <exec_byte_code+3128>,
0x55b673a56166 <exec_byte_code+3222>, 0x55b673a561c4 <exec_byte_code+3316>,
0x55b673a563b4 <exec_byte_code+3812>, 0x55b673a56326 <exec_byte_code+3670>,
0x55b673a5636d <exec_byte_code+3741>, 0x55b673a56208 <exec_byte_code+3384>,
0x55b673a5624f <exec_byte_code+3455>, 0x55b673a5628b <exec_byte_code+3515>,
0x55b673a562ea <exec_byte_code+3610>, 0x55b673a563fb <exec_byte_code+3883>,
0x55b673a56437 <exec_byte_code+3943>, 0x55b673a56473 <exec_byte_code+4003>,
0x55b673a5652d <exec_byte_code+4189>, 0x55b673a558db <exec_byte_code+1035>,
0x55b673a56579 <exec_byte_code+4265>, 0x55b673a565ab <exec_byte_code+4315>,
0x55b673a5662d <exec_byte_code+4445>, 0x55b673a56679 <exec_byte_code+4521>,
0x55b673a566c5 <exec_byte_code+4597>, 0x55b673a566f7 <exec_byte_code+4647>,
0x55b673a5672b <exec_byte_code+4699>, 0x55b673a5675f <exec_byte_code+4751>,
0x55b673a5679b <exec_byte_code+4811>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a567cf <exec_byte_code+4863>,
0x55b673a56803 <exec_byte_code+4915>, 0x55b673a56837 <exec_byte_code+4967>,
0x55b673a5686b <exec_byte_code+5019>, 0x55b673a5689f <exec_byte_code+5071>,
0x55b673a568d3 <exec_byte_code+5123>, 0x55b673a558db <exec_byte_code+1035>,
0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a56905
<exec_byte_code+5173>, 0x55b673a5694d <exec_byte_code+5245>, 0x55b673a5697f
<exec_byte_code+5295>, 0x55b673a569b1 <exec_byte_code+5345>, 0x55b673a57160
<exec_byte_code+7312>, 0x55b673a571a2 <exec_byte_code+7378>, 0x55b673a571d4
<exec_byte_code+7428>, 0x55b673a5728f <exec_byte_code+7615>, 0x55b673a572d1
<exec_byte_code+7681>, 0x55b673a57313 <exec_byte_code+7747>, 0x55b673a57462
<exec_byte_code+8082>, 0x55b673a57496 <exec_byte_code+8134>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a56fb8 <exec_byte_code+6888>,
0x55b673a56cb7 <exec_byte_code+6119>, 0x55b673a56a2b <exec_byte_code+5467>,
0x55b673a56ce0 <exec_byte_code+6160>, 0x55b673a56d25 <exec_byte_code+6229>,
0x55b673a56d67 <exec_byte_code+6295>, 0x55b673a56f0a <exec_byte_code+6714>,
0x55b673a56f90 <exec_byte_code+6848>, 0x55b673a56bad <exec_byte_code+5853>,
0x55b673a56ffc <exec_byte_code+6956>, 0x55b673a570ae <exec_byte_code+7134>,
0x55b673a573e2 <exec_byte_code+7954>, 0x55b673a57419 <exec_byte_code+8009>,
0x55b673a5738b <exec_byte_code+7867>, 0x55b673a5599d <exec_byte_code+1229>,
0x55b673a559e3 <exec_byte_code+1299>, 0x55b673a55a2f <exec_byte_code+1375>,
0x55b673a56c8a <exec_byte_code+6074>, 0x55b673a574c8 <exec_byte_code+8184>,
0x55b673a5750e <exec_byte_code+8254>, 0x55b673a57540 <exec_byte_code+8304>,
0x55b673a57572 <exec_byte_code+8354>, 0x55b673a575a4 <exec_byte_code+8404>,
0x55b673a575d6 <exec_byte_code+8454>, 0x55b673a57618 <exec_byte_code+8520>,
0x55b673a5765a <exec_byte_code+8586>, 0x55b673a5769c <exec_byte_code+8652>,
0x55b673a576de <exec_byte_code+8718>, 0x55b673a5773f <exec_byte_code+8815>,
0x55b673a57781 <exec_byte_code+8881>, 0x55b673a577c3 <exec_byte_code+8947>,
0x55b673a577f5 <exec_byte_code+8997>, 0x55b673a57837 <exec_byte_code+9063>,
0x55b673a57879 <exec_byte_code+9129>, 0x55b673a578b8 <exec_byte_code+9192>,
0x55b673a578f7 <exec_byte_code+9255>, 0x55b673a564af <exec_byte_code+4063>,
0x55b673a564eb <exec_byte_code+4123>, 0x55b673a57933 <exec_byte_code+9315>,
0x55b673a5798c <exec_byte_code+9404>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a56da9 <exec_byte_code+6361>,
0x55b673a56e10 <exec_byte_code+6464>, 0x55b673a56e50 <exec_byte_code+6528>,
0x55b673a56e90 <exec_byte_code+6592>, 0x55b673a56ecd <exec_byte_code+6653>,
0x55b673a55d94 <exec_byte_code+2244>, 0x55b673a560bd <exec_byte_code+3053>,
0x55b673a565e2 <exec_byte_code+4370>, 0x55b673a57a6f <exec_byte_code+9631>,
0x55b673a57ab9 <exec_byte_code+9705>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57ebb <exec_byte_code+10731>,
0x55b673a57b0f <exec_byte_code+9791>, 0x55b673a57b5a <exec_byte_code+9866>,
0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57ebb <exec_byte_code+10731>,
0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57ebb <exec_byte_code+10731>,
0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57129 <exec_byte_code+7257> <repeats 64
times>}
const_length = <optimized out>
bytestr_length = <optimized out>
vectorp = 0x7f437edacc70
quitcounter = 1 '\001'
stack_items = <optimized out>
sa_avail = <optimized out>
sa_count = <optimized out>
alloc = <optimized out>
stack_base = <optimized out>
top = 0x7ffc3938eaf8
stack_lim = <optimized out>
bytestr_data = 0x7ffc3938eb00 "\300\001!\205\n"
pc = <optimized out>
count = 84
result = <optimized out>
#12 0x000055b673a1b159 in Ffuncall (nargs=2, args=0x7ffc3938ec70) at
eval.c:3052
fun = <optimized out>
original_fun = 0x298d0aeb5ce8
funcar = <optimized out>
numargs = 1
val = <optimized out>
count = 83
#13 0x00007f436e01cfa2 in
F646f6f6d2d6d6f64656c696e652d7365742d73656c65637465642d77696e646f77_doom_modeline_set_selected_window_0
() at
/home/alex/.emacs.d/eln-cache/28.0.50-d7cb8ced/doom-modeline-core-316342f3-a0ab9fa5.eln
#14 0x000055b673a1b2ab in Ffuncall (nargs=1, args=0x7ffc3938ed68) at
lisp.h:2093
fun = <optimized out>
original_fun = 0x4039eb0
funcar = <optimized out>
numargs = 0
val = <optimized out>
count = 82
#15 0x000055b673a1b2d9 in funcall_nil (nargs=<optimized out>,
args=<optimized out>) at eval.c:2677
#16 0x000055b673a1a9bd in run_hook_with_args (nargs=1,
args=0x7ffc3938ed68, funcall=0x55b673a1b2d0 <funcall_nil>) at eval.c:2854
global_vals = <optimized out>
sym = 0x37b0
val = 0x55b67634beb3
ret = <optimized out>
#17 0x000055b673a1ab24 in Frun_hook_with_args (args=0x7ffc3938ed68,
nargs=1) at eval.c:2867
i = <optimized out>
#18 0x000055b673a1ab24 in run_hook (hook=<optimized out>) at eval.c:2867
i = <optimized out>
#19 0x000055b673a1ab24 in Frun_hooks (nargs=<optimized out>,
args=<optimized out>) at eval.c:2701
i = <optimized out>
#20 0x000055b673a1b2ab in Ffuncall (nargs=2, args=args <at> entry=0x7ffc3938ee30)
at lisp.h:2093
fun = <optimized out>
original_fun = 0x298d0aec0c78
funcar = <optimized out>
numargs = 1
val = <optimized out>
count = 81
#21 0x000055b673a55830 in exec_byte_code (bytestr=<optimized out>,
vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized
out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:632
op = <optimized out>
type = <optimized out>
targets = {0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a579d8
<exec_byte_code+9480>, 0x55b673a579dd <exec_byte_code+9485>, 0x55b673a579e2
<exec_byte_code+9490>, 0x55b673a55717 <exec_byte_code+583>, 0x55b673a55717
<exec_byte_code+583>, 0x55b673a579e7 <exec_byte_code+9495>, 0x55b673a57a26
<exec_byte_code+9558>, 0x55b673a56a0a <exec_byte_code+5434>, 0x55b673a56a0f
<exec_byte_code+5439>, 0x55b673a56a14 <exec_byte_code+5444>, 0x55b673a56a19
<exec_byte_code+5449>, 0x55b673a55752 <exec_byte_code+642>, 0x55b673a55758
<exec_byte_code+648>, 0x55b673a56a1e <exec_byte_code+5454>, 0x55b673a569f3
<exec_byte_code+5411>, 0x55b673a56b75 <exec_byte_code+5797>, 0x55b673a56b7a
<exec_byte_code+5802>, 0x55b673a56b7f <exec_byte_code+5807>, 0x55b673a56b84
<exec_byte_code+5812>, 0x55b673a556a4 <exec_byte_code+468>, 0x55b673a556a8
<exec_byte_code+472>, 0x55b673a56ba0 <exec_byte_code+5840>, 0x55b673a56b89
<exec_byte_code+5817>, 0x55b673a56c06 <exec_byte_code+5942>, 0x55b673a56c0b
<exec_byte_code+5947>, 0x55b673a56c10 <exec_byte_code+5952>, 0x55b673a56c15
<exec_byte_code+5957>, 0x55b673a55856 <exec_byte_code+902>, 0x55b673a55860
<exec_byte_code+912>, 0x55b673a56be2 <exec_byte_code+5906>, 0x55b673a56bef
<exec_byte_code+5919>, 0x55b673a56c3e <exec_byte_code+5998>, 0x55b673a56c43
<exec_byte_code+6003>, 0x55b673a56c48 <exec_byte_code+6008>, 0x55b673a56c4d
<exec_byte_code+6013>, 0x55b673a5580f <exec_byte_code+831>, 0x55b673a55810
<exec_byte_code+832>, 0x55b673a56c1a <exec_byte_code+5962>, 0x55b673a56c27
<exec_byte_code+5975>, 0x55b673a56c76 <exec_byte_code+6054>, 0x55b673a56c7b
<exec_byte_code+6059>, 0x55b673a56c80 <exec_byte_code+6064>, 0x55b673a56c85
<exec_byte_code+6069>, 0x55b673a557b5 <exec_byte_code+741>, 0x55b673a557b8
<exec_byte_code+744>, 0x55b673a56c52 <exec_byte_code+6018>, 0x55b673a56c5f
<exec_byte_code+6031>, 0x55b673a57355 <exec_byte_code+7813>, 0x55b673a570a0
<exec_byte_code+7120>, 0x55b673a57024 <exec_byte_code+6996>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57ebb <exec_byte_code+10731>,
0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57ebb <exec_byte_code+10731>,
0x55b673a55aae <exec_byte_code+1502>, 0x55b673a55b08 <exec_byte_code+1592>,
0x55b673a55b4e <exec_byte_code+1662>, 0x55b673a55b97 <exec_byte_code+1735>,
0x55b673a55be0 <exec_byte_code+1808>, 0x55b673a56aac <exec_byte_code+5596>,
0x55b673a56af7 <exec_byte_code+5671>, 0x55b673a55c28 <exec_byte_code+1880>,
0x55b673a56a70 <exec_byte_code+5536>, 0x55b673a56b39 <exec_byte_code+5737>,
0x55b673a55c5c <exec_byte_code+1932>, 0x55b673a55c9e <exec_byte_code+1998>,
0x55b673a55cd0 <exec_byte_code+2048>, 0x55b673a55d12 <exec_byte_code+2114>,
0x55b673a55d51 <exec_byte_code+2177>, 0x55b673a55ddf <exec_byte_code+2319>,
0x55b673a55e11 <exec_byte_code+2369>, 0x55b673a55e53 <exec_byte_code+2435>,
0x55b673a55e99 <exec_byte_code+2505>, 0x55b673a55ecb <exec_byte_code+2555>,
0x55b673a55efd <exec_byte_code+2605>, 0x55b673a55f3f <exec_byte_code+2671>,
0x55b673a55f81 <exec_byte_code+2737>, 0x55b673a55fc3 <exec_byte_code+2803>,
0x55b673a56009 <exec_byte_code+2873>, 0x55b673a56045 <exec_byte_code+2933>,
0x55b673a56081 <exec_byte_code+2993>, 0x55b673a56108 <exec_byte_code+3128>,
0x55b673a56166 <exec_byte_code+3222>, 0x55b673a561c4 <exec_byte_code+3316>,
0x55b673a563b4 <exec_byte_code+3812>, 0x55b673a56326 <exec_byte_code+3670>,
0x55b673a5636d <exec_byte_code+3741>, 0x55b673a56208 <exec_byte_code+3384>,
0x55b673a5624f <exec_byte_code+3455>, 0x55b673a5628b <exec_byte_code+3515>,
0x55b673a562ea <exec_byte_code+3610>, 0x55b673a563fb <exec_byte_code+3883>,
0x55b673a56437 <exec_byte_code+3943>, 0x55b673a56473 <exec_byte_code+4003>,
0x55b673a5652d <exec_byte_code+4189>, 0x55b673a558db <exec_byte_code+1035>,
0x55b673a56579 <exec_byte_code+4265>, 0x55b673a565ab <exec_byte_code+4315>,
0x55b673a5662d <exec_byte_code+4445>, 0x55b673a56679 <exec_byte_code+4521>,
0x55b673a566c5 <exec_byte_code+4597>, 0x55b673a566f7 <exec_byte_code+4647>,
0x55b673a5672b <exec_byte_code+4699>, 0x55b673a5675f <exec_byte_code+4751>,
0x55b673a5679b <exec_byte_code+4811>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a567cf <exec_byte_code+4863>,
0x55b673a56803 <exec_byte_code+4915>, 0x55b673a56837 <exec_byte_code+4967>,
0x55b673a5686b <exec_byte_code+5019>, 0x55b673a5689f <exec_byte_code+5071>,
0x55b673a568d3 <exec_byte_code+5123>, 0x55b673a558db <exec_byte_code+1035>,
0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a56905
<exec_byte_code+5173>, 0x55b673a5694d <exec_byte_code+5245>, 0x55b673a5697f
<exec_byte_code+5295>, 0x55b673a569b1 <exec_byte_code+5345>, 0x55b673a57160
<exec_byte_code+7312>, 0x55b673a571a2 <exec_byte_code+7378>, 0x55b673a571d4
<exec_byte_code+7428>, 0x55b673a5728f <exec_byte_code+7615>, 0x55b673a572d1
<exec_byte_code+7681>, 0x55b673a57313 <exec_byte_code+7747>, 0x55b673a57462
<exec_byte_code+8082>, 0x55b673a57496 <exec_byte_code+8134>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a56fb8 <exec_byte_code+6888>,
0x55b673a56cb7 <exec_byte_code+6119>, 0x55b673a56a2b <exec_byte_code+5467>,
0x55b673a56ce0 <exec_byte_code+6160>, 0x55b673a56d25 <exec_byte_code+6229>,
0x55b673a56d67 <exec_byte_code+6295>, 0x55b673a56f0a <exec_byte_code+6714>,
0x55b673a56f90 <exec_byte_code+6848>, 0x55b673a56bad <exec_byte_code+5853>,
0x55b673a56ffc <exec_byte_code+6956>, 0x55b673a570ae <exec_byte_code+7134>,
0x55b673a573e2 <exec_byte_code+7954>, 0x55b673a57419 <exec_byte_code+8009>,
0x55b673a5738b <exec_byte_code+7867>, 0x55b673a5599d <exec_byte_code+1229>,
0x55b673a559e3 <exec_byte_code+1299>, 0x55b673a55a2f <exec_byte_code+1375>,
0x55b673a56c8a <exec_byte_code+6074>, 0x55b673a574c8 <exec_byte_code+8184>,
0x55b673a5750e <exec_byte_code+8254>, 0x55b673a57540 <exec_byte_code+8304>,
0x55b673a57572 <exec_byte_code+8354>, 0x55b673a575a4 <exec_byte_code+8404>,
0x55b673a575d6 <exec_byte_code+8454>, 0x55b673a57618 <exec_byte_code+8520>,
0x55b673a5765a <exec_byte_code+8586>, 0x55b673a5769c <exec_byte_code+8652>,
0x55b673a576de <exec_byte_code+8718>, 0x55b673a5773f <exec_byte_code+8815>,
0x55b673a57781 <exec_byte_code+8881>, 0x55b673a577c3 <exec_byte_code+8947>,
0x55b673a577f5 <exec_byte_code+8997>, 0x55b673a57837 <exec_byte_code+9063>,
0x55b673a57879 <exec_byte_code+9129>, 0x55b673a578b8 <exec_byte_code+9192>,
0x55b673a578f7 <exec_byte_code+9255>, 0x55b673a564af <exec_byte_code+4063>,
0x55b673a564eb <exec_byte_code+4123>, 0x55b673a57933 <exec_byte_code+9315>,
0x55b673a5798c <exec_byte_code+9404>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a56da9 <exec_byte_code+6361>,
0x55b673a56e10 <exec_byte_code+6464>, 0x55b673a56e50 <exec_byte_code+6528>,
0x55b673a56e90 <exec_byte_code+6592>, 0x55b673a56ecd <exec_byte_code+6653>,
0x55b673a55d94 <exec_byte_code+2244>, 0x55b673a560bd <exec_byte_code+3053>,
0x55b673a565e2 <exec_byte_code+4370>, 0x55b673a57a6f <exec_byte_code+9631>,
0x55b673a57ab9 <exec_byte_code+9705>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57ebb <exec_byte_code+10731>,
0x55b673a57b0f <exec_byte_code+9791>, 0x55b673a57b5a <exec_byte_code+9866>,
0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57ebb <exec_byte_code+10731>,
0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57ebb <exec_byte_code+10731>,
0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57129 <exec_byte_code+7257> <repeats 64
times>}
const_length = <optimized out>
bytestr_length = <optimized out>
vectorp = 0x7f437f4782f8
quitcounter = 1 '\001'
stack_items = <optimized out>
sa_avail = <optimized out>
sa_count = <optimized out>
alloc = <optimized out>
stack_base = <optimized out>
top = 0x7ffc3938ee30
stack_lim = <optimized out>
bytestr_data = 0x7ffc3938ee68
"\301\002\302\"\303\001!\211\304\003!\236\305\003\306\"\210\307\002!\310H\311=\203%"
pc = <optimized out>
count = 81
result = <optimized out>
#22 0x000055b673a1b159 in Ffuncall (nargs=3, args=0x7ffc3938f020) at
eval.c:3052
fun = <optimized out>
original_fun = 0xc3f0
funcar = <optimized out>
numargs = 2
val = <optimized out>
count = 80
#23 0x000055b673a1b38f in call2 (fn=fn <at> entry=0xc3f0, arg1=<optimized
out>, arg2=arg2 <at> entry=0x30) at eval.c:2903
#24 0x000055b6739cf206 in read_minibuf (inherit_input_method=false,
allow_props=false, defalt=0x0, histpos=0x2, histvar=0x2a6f540,
expflag=false, prompt=0x55b67fabc734, initial=<optimized out>,
map=0x55b67971d943) at lisp.h:1008
pos = 0
histstring = <optimized out>
histval = <optimized out>
empty_minibuf = <optimized out>
count = 76
enable_multibyte = 0x0
val = 0x0
mini_frame = 0x55b674ffcfe5
minibuffer = <optimized out>
input_method = 0x0
calling_frame = 0x55b674ffcfe5
calling_window = 0x55b674e52b05
histvar = <optimized out>
histpos = 0x2
val = <optimized out>
#25 0x000055b6739cf206 in Fread_from_minibuffer (prompt=0x55b67fabc734,
initial_contents=<optimized out>, keymap=0x55b67971d943, read=0x0,
hist=<optimized out>, default_value=0x0, inherit_input_method=0x0) at
minibuf.c:1342
histvar = <optimized out>
histpos = 0x2
val = <optimized out>
#26 0x000055b673a1d63b in eval_sub (form=<optimized out>) at lisp.h:2093
i = <optimized out>
maxargs = 7
args_left = 0x0
numargs = 5
original_fun = <optimized out>
original_args = 0x55b676a82c43
count = 75
fun = <optimized out>
val = <optimized out>
funcar = <optimized out>
argvals = {0x55b67fabc734, 0x55b67fabc6d4, 0x55b67971d943, 0x0,
0x2a6f540, 0x0, 0x0, 0x7ffc3938f0e0}
#27 0x000055b673a1eea9 in internal_lisp_condition_case (var=0x11caf70,
bodyform=0x55b676a82c33, handlers=<optimized out>) at eval.c:1429
oldhandlerlist = 0x55b674810000
clausenb = 1
success_handler = 0x0
clauses = 0x7ffc3938f1e0
result = <optimized out>
#28 0x000055b673a1d5b4 in eval_sub (form=<optimized out>) at lisp.h:2093
args_left = 0x55b676a82dd3
numargs = 3
original_fun = 0x4860
original_args = 0x55b676a82dd3
count = 74
fun = <optimized out>
val = <optimized out>
funcar = <optimized out>
argvals = {0x7ffc3938f310, 0x0, 0x7ffc3938f310, 0xb18, 0xb40,
0x55b673a1d061 <apply_lambda+225>, 0x12dded0, 0x55b673a1cfb6
<apply_lambda+54>}
#29 0x000055b673a1dd8d in Fprogn (body=0x0) at eval.c:471
form = <optimized out>
form = <optimized out>
val = 0x0
cond = <optimized out>
#30 0x000055b673a1dd8d in Fif (args=<optimized out>) at eval.c:427
cond = <optimized out>
#31 0x000055b673a1dd8d in Fif (args=<optimized out>) at eval.c:413
cond = <optimized out>
#32 0x000055b673a1d5b4 in eval_sub (form=<optimized out>) at lisp.h:2093
args_left = 0x55b676a83423
numargs = 3
original_fun = 0x8250
original_args = 0x55b676a83423
count = 73
fun = <optimized out>
val = <optimized out>
funcar = <optimized out>
argvals = {0x7f437edb1f08, 0x7ffc3938f190, 0x7ffc3938f3b8, 0x0,
0xa78, 0x55b673a0a739 <set_internal+281>, 0x7ffc3938f3b0, 0x55b673a0a11e
<find_symbol_value+94>}
#33 0x000055b673a1eb8d in Fprogn (body=0x55b676a82ed3) at eval.c:471
form = <optimized out>
form = <optimized out>
val = 0x0
var = <optimized out>
val = <optimized out>
elt = <optimized out>
lexenv = <optimized out>
count = 68
varlist = <optimized out>
#34 0x000055b673a1eb8d in FletX (args=0x55b676a82ee3) at eval.c:989
var = <optimized out>
val = <optimized out>
elt = <optimized out>
lexenv = <optimized out>
count = 68
varlist = <optimized out>
#35 0x000055b673a1d5b4 in eval_sub (form=<optimized out>) at lisp.h:2093
args_left = 0x55b676a82ee3
numargs = 3
original_fun = 0x95a0
original_args = 0x55b676a82ee3
count = 67
fun = <optimized out>
val = <optimized out>
funcar = <optimized out>
argvals = {0x7ffc3938f510, 0x2, 0xffff, 0x55b673a1d5b4
<eval_sub+1140>, 0x0, 0x0, 0x55b673e80e45 <SletX+5>, 0x41}
#36 0x000055b673a1d8fd in Fprogn (body=0x0) at eval.c:471
form = <optimized out>
val = 0x0
#37 0x000055b673a1d5b4 in eval_sub (form=<optimized out>) at lisp.h:2093
args_left = 0x55b676a82f13
numargs = 2
original_fun = 0xbf10
original_args = 0x55b676a82f13
count = 66
fun = <optimized out>
val = <optimized out>
funcar = <optimized out>
argvals = {0x55b673e81145 <Sfunction+5>, 0x41, 0xbf10,
0x55b676e75a73, 0x2, 0x55b6778f5973, 0x55b673e812c5 <Sprogn+5>, 0x40}
#38 0x000055b673a1ec2f in Funwind_protect (args=0x55b676a82f43) at
lisp.h:1420
val = <optimized out>
count = 65
#39 0x000055b673a1d5b4 in eval_sub (form=<optimized out>) at lisp.h:2093
args_left = 0x55b676a82f43
numargs = 2
original_fun = 0x298d0aecaed0
original_args = 0x55b676a82f43
count = 64
fun = <optimized out>
val = <optimized out>
funcar = <optimized out>
argvals = {0x9a57d80, 0x55b67971e0d3, 0x0, 0x95a0,
0x7ffc3938f6d0, 0x55b673a21615 <Fmemq+85>, 0x7ffc3938f6d0, 0x55b67733c373}
#40 0x000055b673a1e9bd in Fprogn (body=0x0) at eval.c:471
form = <optimized out>
form = <optimized out>
val = 0x0
temps = 0x7ffc3938f660
tem = <optimized out>
lexenv = 0x55b67971e133
elt = <optimized out>
count = 63
argnum = <optimized out>
sa_avail = <optimized out>
sa_count = 63
varlist = <optimized out>
varlist_len = <optimized out>
nvars = <optimized out>
#41 0x000055b673a1e9bd in Flet (args=0x55b676e750f3) at eval.c:1057
temps = 0x7ffc3938f660
tem = <optimized out>
lexenv = 0x55b67971e133
elt = <optimized out>
count = 63
argnum = <optimized out>
sa_avail = <optimized out>
sa_count = 63
varlist = <optimized out>
varlist_len = <optimized out>
nvars = <optimized out>
#42 0x000055b673a1d5b4 in eval_sub (form=<optimized out>) at lisp.h:2093
args_left = 0x55b676e750f3
numargs = 3
original_fun = 0x9570
original_args = 0x55b676e750f3
count = 62
fun = <optimized out>
val = <optimized out>
funcar = <optimized out>
argvals = {0x7ffc3938f7a0, 0x0, 0x7ffc3938f7a0, 0x960, 0x988,
0x55b673a1d061 <apply_lambda+225>, 0x55b674c5d805, 0x55b673a1cfb6
<apply_lambda+54>}
#43 0x000055b673a1ec2f in Funwind_protect (args=0x55b676e75123) at
lisp.h:1420
val = <optimized out>
count = 61
#44 0x000055b673a1d5b4 in eval_sub (form=<optimized out>) at lisp.h:2093
args_left = 0x55b676e75123
numargs = 3
original_fun = 0x298d0aecaed0
original_args = 0x55b676e75123
count = 60
fun = <optimized out>
val = <optimized out>
funcar = <optimized out>
argvals = {0x55b673e81445 <Sor+5>, 0x3a, 0x55b673e83125
<Sequal+5>, 0x55b676e49153, 0x0, 0x55b676e49093, 0x0, 0x55b676e490a3}
#45 0x000055b673a1eb8d in Fprogn (body=0x55b676e4be73) at eval.c:471
form = <optimized out>
form = <optimized out>
val = 0x0
var = <optimized out>
val = <optimized out>
elt = <optimized out>
lexenv = <optimized out>
count = 58
varlist = <optimized out>
#46 0x000055b673a1eb8d in FletX (args=0x55b676e74de3) at eval.c:989
var = <optimized out>
val = <optimized out>
elt = <optimized out>
lexenv = <optimized out>
count = 58
varlist = <optimized out>
#47 0x000055b673a1d5b4 in eval_sub (form=<optimized out>) at lisp.h:2093
args_left = 0x55b676e74de3
numargs = 7
original_fun = 0x95a0
original_args = 0x55b676e74de3
count = 57
fun = <optimized out>
val = <optimized out>
funcar = <optimized out>
argvals = {0x7ffc3938f960, 0x1, 0x7ffc3938f900, 0x55b673a1e9d1
<Flet+561>, 0x55b67733e9d3, 0x55b673a1e7e9 <Flet+73>, 0x39, 0x55b67733e9d3}
#48 0x000055b673a1d8fd in Fprogn (body=0x0) at eval.c:471
form = <optimized out>
val = 0x0
#49 0x000055b673a1d5b4 in eval_sub (form=<optimized out>) at lisp.h:2093
args_left = 0x55b676a81123
numargs = 4
original_fun = 0xbf10
original_args = 0x55b676a81123
count = 56
fun = <optimized out>
val = <optimized out>
funcar = <optimized out>
argvals = {0x36, 0x55b676e71ec3, 0x55b67733ebb3, 0x1,
0x7ffc3938fa40, 0x298d0af54a40, 0x0, 0x4000000010000000}
#50 0x000055b673a1d8fd in Fprogn (body=0x0) at eval.c:471
form = <optimized out>
val = 0x0
#51 0x000055b673a1d5b4 in eval_sub (form=<optimized out>) at lisp.h:2093
args_left = 0x55b676e74e43
numargs = 2
original_fun = 0xbf10
original_args = 0x55b676e74e43
count = 55
fun = <optimized out>
val = <optimized out>
funcar = <optimized out>
argvals = {0x55b67733ecd3, 0x6, 0x2, 0x55b673a26bdf
<concat+2335>, 0x6, 0x55b673a21615 <Fmemq+85>, 0x7ffc3938fb60,
0x55b67733cb03}
#52 0x000055b673a1eb8d in Fprogn (body=0x0) at eval.c:471
form = <optimized out>
form = <optimized out>
val = 0x0
var = <optimized out>
val = <optimized out>
elt = <optimized out>
lexenv = <optimized out>
count = 54
varlist = <optimized out>
#53 0x000055b673a1eb8d in FletX (args=0x55b676e74e73) at eval.c:989
var = <optimized out>
val = <optimized out>
elt = <optimized out>
lexenv = <optimized out>
count = 54
varlist = <optimized out>
#54 0x000055b673a1d5b4 in eval_sub (form=<optimized out>) at lisp.h:2093
args_left = 0x55b676e74e73
numargs = 2
original_fun = 0x95a0
original_args = 0x55b676e74e73
count = 53
fun = <optimized out>
val = <optimized out>
funcar = <optimized out>
argvals = {0x7ffc3938fc30, 0x0, 0x4000000010000000,
0x55b676fe3973, 0x55b673ef6f20 <lispsym>, 0x55b673a1d5b4 <eval_sub+1140>,
0x7ffc3938fc30, 0x0}
#55 0x000055b673a1da95 in Fprogn (body=0x0) at eval.c:471
form = <optimized out>
form = <optimized out>
val = 0x0
val = <optimized out>
syms_left = <optimized out>
next = <optimized out>
lexenv = 0x55b67733e973
count = 52
i = <optimized out>
optional = <optimized out>
rest = <optimized out>
#56 0x000055b673a1da95 in funcall_lambda (fun=0x55b676e74f23, nargs=12,
arg_vector=0x7ffc3938fc40) at eval.c:3313
val = <optimized out>
syms_left = <optimized out>
next = <optimized out>
lexenv = 0x55b67733e973
count = 52
i = <optimized out>
optional = <optimized out>
rest = <optimized out>
#57 0x000055b673a1d061 in apply_lambda (fun=0x55b676e74f33,
args=<optimized out>, count=count <at> entry=51) at eval.c:3185
arg_vector = 0x7ffc3938fc40
tem = <optimized out>
sa_avail = <optimized out>
sa_count = 52
numargs = 12
args_left = 0x0
#58 0x000055b673a1d2c0 in eval_sub (form=<optimized out>) at eval.c:2588
original_fun = 0x19a6eb0
original_args = 0x55b676fe1f63
count = 51
fun = <optimized out>
val = <optimized out>
funcar = <optimized out>
argvals = {0x55b676b08fb3, 0x6, 0x2, 0x55b673a216c1 <Fassq+97>,
0x55b6828a2314, 0xa6, 0x2bb7b30, 0xa6}
#59 0x000055b673a1dd8d in Fprogn (body=0x0) at eval.c:471
form = <optimized out>
form = <optimized out>
val = 0x0
cond = <optimized out>
#60 0x000055b673a1dd8d in Fif (args=<optimized out>) at eval.c:427
cond = <optimized out>
#61 0x000055b673a1dd8d in Fif (args=<optimized out>) at eval.c:413
cond = <optimized out>
#62 0x000055b673a1d5b4 in eval_sub (form=<optimized out>) at lisp.h:2093
args_left = 0x55b676fe2683
numargs = 7
original_fun = 0x8250
original_args = 0x55b676fe2683
count = 50
fun = <optimized out>
val = <optimized out>
funcar = <optimized out>
argvals = {0xa6, 0xbe, 0xbf10, 0x55b673a1d5b4 <eval_sub+1140>,
0x55b673e813e5 <Sand+5>, 0x55b673a21615 <Fmemq+85>, 0x55b673e812c5
<Sprogn+5>, 0x55b676b089d3}
#63 0x000055b673a1eb8d in Fprogn (body=0x0) at eval.c:471
form = <optimized out>
form = <optimized out>
val = 0x0
var = <optimized out>
val = <optimized out>
elt = <optimized out>
lexenv = <optimized out>
count = 49
varlist = <optimized out>
#64 0x000055b673a1eb8d in FletX (args=0x55b676fe1893) at eval.c:989
var = <optimized out>
val = <optimized out>
elt = <optimized out>
lexenv = <optimized out>
count = 49
varlist = <optimized out>
#65 0x000055b673a1d5b4 in eval_sub (form=<optimized out>) at lisp.h:2093
args_left = 0x55b676fe1893
numargs = 5
original_fun = 0x95a0
original_args = 0x55b676fe1893
count = 48
fun = <optimized out>
val = <optimized out>
funcar = <optimized out>
argvals = {0x55b676b08f93, 0x55b673a1d061 <apply_lambda+225>,
0x55b67fda1474, 0x2f6b670, 0x0, 0x1a, 0x55b676de2603, 0x55b673a1cfb6
<apply_lambda+54>}
#66 0x000055b673a1de0d in Fprogn (body=0x55b676fe39d3) at eval.c:471
form = <optimized out>
form = <optimized out>
val = 0x0
clause = 0x55b676fe3793
val = <optimized out>
#67 0x000055b673a1de0d in Fcond (args=<optimized out>) at eval.c:451
clause = 0x55b676fe3793
val = <optimized out>
#68 0x000055b673a1d5b4 in eval_sub (form=<optimized out>) at lisp.h:2093
args_left = 0x55b676fe18d3
numargs = 3
original_fun = 0x298d0af21168
original_args = 0x55b676fe18d3
count = 47
fun = <optimized out>
val = <optimized out>
funcar = <optimized out>
argvals = {0xa6, 0xbe, 0x55b67c404bf0, 0x4770, 0x55b673ef6f20
<lispsym>, 0x55b673a21615 <Fmemq+85>, 0x30, 0x55b676b08c73}
#69 0x000055b673a1eb8d in Fprogn (body=0x0) at eval.c:471
form = <optimized out>
form = <optimized out>
val = 0x0
var = <optimized out>
val = <optimized out>
elt = <optimized out>
lexenv = <optimized out>
count = 42
varlist = <optimized out>
#70 0x000055b673a1eb8d in FletX (args=0x55b676fe1923) at eval.c:989
var = <optimized out>
val = <optimized out>
elt = <optimized out>
lexenv = <optimized out>
count = 42
varlist = <optimized out>
#71 0x000055b673a1d5b4 in eval_sub (form=<optimized out>) at lisp.h:2093
args_left = 0x55b676fe1923
numargs = 2
original_fun = 0x95a0
original_args = 0x55b676fe1923
count = 41
fun = <optimized out>
val = <optimized out>
funcar = <optimized out>
argvals = {0x2e, 0x0, 0x0, 0x0, 0x55b679051e1e, 0x1000000000011,
0x2e, 0x7ffc3938f390}
#72 0x000055b673a1da95 in Fprogn (body=0x0) at eval.c:471
form = <optimized out>
form = <optimized out>
val = 0x0
val = <optimized out>
syms_left = <optimized out>
next = <optimized out>
lexenv = 0x55b676de26b3
count = 40
i = <optimized out>
optional = <optimized out>
rest = <optimized out>
#73 0x000055b673a1da95 in funcall_lambda (fun=0x55b676fe19d3, nargs=4,
arg_vector=0x7ffc39390250) at eval.c:3313
val = <optimized out>
syms_left = <optimized out>
next = <optimized out>
lexenv = 0x55b676de26b3
count = 40
i = <optimized out>
optional = <optimized out>
rest = <optimized out>
#74 0x000055b673a1b159 in Ffuncall (nargs=5, args=args <at> entry=0x7ffc39390248)
at eval.c:3052
fun = <optimized out>
original_fun = 0x12dded0
funcar = <optimized out>
numargs = 4
val = <optimized out>
count = 39
#75 0x000055b673a55830 in exec_byte_code (bytestr=<optimized out>,
vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized
out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:632
op = <optimized out>
type = <optimized out>
targets = {0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a579d8
<exec_byte_code+9480>, 0x55b673a579dd <exec_byte_code+9485>, 0x55b673a579e2
<exec_byte_code+9490>, 0x55b673a55717 <exec_byte_code+583>, 0x55b673a55717
<exec_byte_code+583>, 0x55b673a579e7 <exec_byte_code+9495>, 0x55b673a57a26
<exec_byte_code+9558>, 0x55b673a56a0a <exec_byte_code+5434>, 0x55b673a56a0f
<exec_byte_code+5439>, 0x55b673a56a14 <exec_byte_code+5444>, 0x55b673a56a19
<exec_byte_code+5449>, 0x55b673a55752 <exec_byte_code+642>, 0x55b673a55758
<exec_byte_code+648>, 0x55b673a56a1e <exec_byte_code+5454>, 0x55b673a569f3
<exec_byte_code+5411>, 0x55b673a56b75 <exec_byte_code+5797>, 0x55b673a56b7a
<exec_byte_code+5802>, 0x55b673a56b7f <exec_byte_code+5807>, 0x55b673a56b84
<exec_byte_code+5812>, 0x55b673a556a4 <exec_byte_code+468>, 0x55b673a556a8
<exec_byte_code+472>, 0x55b673a56ba0 <exec_byte_code+5840>, 0x55b673a56b89
<exec_byte_code+5817>, 0x55b673a56c06 <exec_byte_code+5942>, 0x55b673a56c0b
<exec_byte_code+5947>, 0x55b673a56c10 <exec_byte_code+5952>, 0x55b673a56c15
<exec_byte_code+5957>, 0x55b673a55856 <exec_byte_code+902>, 0x55b673a55860
<exec_byte_code+912>, 0x55b673a56be2 <exec_byte_code+5906>, 0x55b673a56bef
<exec_byte_code+5919>, 0x55b673a56c3e <exec_byte_code+5998>, 0x55b673a56c43
<exec_byte_code+6003>, 0x55b673a56c48 <exec_byte_code+6008>, 0x55b673a56c4d
<exec_byte_code+6013>, 0x55b673a5580f <exec_byte_code+831>, 0x55b673a55810
<exec_byte_code+832>, 0x55b673a56c1a <exec_byte_code+5962>, 0x55b673a56c27
<exec_byte_code+5975>, 0x55b673a56c76 <exec_byte_code+6054>, 0x55b673a56c7b
<exec_byte_code+6059>, 0x55b673a56c80 <exec_byte_code+6064>, 0x55b673a56c85
<exec_byte_code+6069>, 0x55b673a557b5 <exec_byte_code+741>, 0x55b673a557b8
<exec_byte_code+744>, 0x55b673a56c52 <exec_byte_code+6018>, 0x55b673a56c5f
<exec_byte_code+6031>, 0x55b673a57355 <exec_byte_code+7813>, 0x55b673a570a0
<exec_byte_code+7120>, 0x55b673a57024 <exec_byte_code+6996>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57ebb <exec_byte_code+10731>,
0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57ebb <exec_byte_code+10731>,
0x55b673a55aae <exec_byte_code+1502>, 0x55b673a55b08 <exec_byte_code+1592>,
0x55b673a55b4e <exec_byte_code+1662>, 0x55b673a55b97 <exec_byte_code+1735>,
0x55b673a55be0 <exec_byte_code+1808>, 0x55b673a56aac <exec_byte_code+5596>,
0x55b673a56af7 <exec_byte_code+5671>, 0x55b673a55c28 <exec_byte_code+1880>,
0x55b673a56a70 <exec_byte_code+5536>, 0x55b673a56b39 <exec_byte_code+5737>,
0x55b673a55c5c <exec_byte_code+1932>, 0x55b673a55c9e <exec_byte_code+1998>,
0x55b673a55cd0 <exec_byte_code+2048>, 0x55b673a55d12 <exec_byte_code+2114>,
0x55b673a55d51 <exec_byte_code+2177>, 0x55b673a55ddf <exec_byte_code+2319>,
0x55b673a55e11 <exec_byte_code+2369>, 0x55b673a55e53 <exec_byte_code+2435>,
0x55b673a55e99 <exec_byte_code+2505>, 0x55b673a55ecb <exec_byte_code+2555>,
0x55b673a55efd <exec_byte_code+2605>, 0x55b673a55f3f <exec_byte_code+2671>,
0x55b673a55f81 <exec_byte_code+2737>, 0x55b673a55fc3 <exec_byte_code+2803>,
0x55b673a56009 <exec_byte_code+2873>, 0x55b673a56045 <exec_byte_code+2933>,
0x55b673a56081 <exec_byte_code+2993>, 0x55b673a56108 <exec_byte_code+3128>,
0x55b673a56166 <exec_byte_code+3222>, 0x55b673a561c4 <exec_byte_code+3316>,
0x55b673a563b4 <exec_byte_code+3812>, 0x55b673a56326 <exec_byte_code+3670>,
0x55b673a5636d <exec_byte_code+3741>, 0x55b673a56208 <exec_byte_code+3384>,
0x55b673a5624f <exec_byte_code+3455>, 0x55b673a5628b <exec_byte_code+3515>,
0x55b673a562ea <exec_byte_code+3610>, 0x55b673a563fb <exec_byte_code+3883>,
0x55b673a56437 <exec_byte_code+3943>, 0x55b673a56473 <exec_byte_code+4003>,
0x55b673a5652d <exec_byte_code+4189>, 0x55b673a558db <exec_byte_code+1035>,
0x55b673a56579 <exec_byte_code+4265>, 0x55b673a565ab <exec_byte_code+4315>,
0x55b673a5662d <exec_byte_code+4445>, 0x55b673a56679 <exec_byte_code+4521>,
0x55b673a566c5 <exec_byte_code+4597>, 0x55b673a566f7 <exec_byte_code+4647>,
0x55b673a5672b <exec_byte_code+4699>, 0x55b673a5675f <exec_byte_code+4751>,
0x55b673a5679b <exec_byte_code+4811>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a567cf <exec_byte_code+4863>,
0x55b673a56803 <exec_byte_code+4915>, 0x55b673a56837 <exec_byte_code+4967>,
0x55b673a5686b <exec_byte_code+5019>, 0x55b673a5689f <exec_byte_code+5071>,
0x55b673a568d3 <exec_byte_code+5123>, 0x55b673a558db <exec_byte_code+1035>,
0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a56905
<exec_byte_code+5173>, 0x55b673a5694d <exec_byte_code+5245>, 0x55b673a5697f
<exec_byte_code+5295>, 0x55b673a569b1 <exec_byte_code+5345>, 0x55b673a57160
<exec_byte_code+7312>, 0x55b673a571a2 <exec_byte_code+7378>, 0x55b673a571d4
<exec_byte_code+7428>, 0x55b673a5728f <exec_byte_code+7615>, 0x55b673a572d1
<exec_byte_code+7681>, 0x55b673a57313 <exec_byte_code+7747>, 0x55b673a57462
<exec_byte_code+8082>, 0x55b673a57496 <exec_byte_code+8134>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a56fb8 <exec_byte_code+6888>,
0x55b673a56cb7 <exec_byte_code+6119>, 0x55b673a56a2b <exec_byte_code+5467>,
0x55b673a56ce0 <exec_byte_code+6160>, 0x55b673a56d25 <exec_byte_code+6229>,
0x55b673a56d67 <exec_byte_code+6295>, 0x55b673a56f0a <exec_byte_code+6714>,
0x55b673a56f90 <exec_byte_code+6848>, 0x55b673a56bad <exec_byte_code+5853>,
0x55b673a56ffc <exec_byte_code+6956>, 0x55b673a570ae <exec_byte_code+7134>,
0x55b673a573e2 <exec_byte_code+7954>, 0x55b673a57419 <exec_byte_code+8009>,
0x55b673a5738b <exec_byte_code+7867>, 0x55b673a5599d <exec_byte_code+1229>,
0x55b673a559e3 <exec_byte_code+1299>, 0x55b673a55a2f <exec_byte_code+1375>,
0x55b673a56c8a <exec_byte_code+6074>, 0x55b673a574c8 <exec_byte_code+8184>,
0x55b673a5750e <exec_byte_code+8254>, 0x55b673a57540 <exec_byte_code+8304>,
0x55b673a57572 <exec_byte_code+8354>, 0x55b673a575a4 <exec_byte_code+8404>,
0x55b673a575d6 <exec_byte_code+8454>, 0x55b673a57618 <exec_byte_code+8520>,
0x55b673a5765a <exec_byte_code+8586>, 0x55b673a5769c <exec_byte_code+8652>,
0x55b673a576de <exec_byte_code+8718>, 0x55b673a5773f <exec_byte_code+8815>,
0x55b673a57781 <exec_byte_code+8881>, 0x55b673a577c3 <exec_byte_code+8947>,
0x55b673a577f5 <exec_byte_code+8997>, 0x55b673a57837 <exec_byte_code+9063>,
0x55b673a57879 <exec_byte_code+9129>, 0x55b673a578b8 <exec_byte_code+9192>,
0x55b673a578f7 <exec_byte_code+9255>, 0x55b673a564af <exec_byte_code+4063>,
0x55b673a564eb <exec_byte_code+4123>, 0x55b673a57933 <exec_byte_code+9315>,
0x55b673a5798c <exec_byte_code+9404>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a56da9 <exec_byte_code+6361>,
0x55b673a56e10 <exec_byte_code+6464>, 0x55b673a56e50 <exec_byte_code+6528>,
0x55b673a56e90 <exec_byte_code+6592>, 0x55b673a56ecd <exec_byte_code+6653>,
0x55b673a55d94 <exec_byte_code+2244>, 0x55b673a560bd <exec_byte_code+3053>,
0x55b673a565e2 <exec_byte_code+4370>, 0x55b673a57a6f <exec_byte_code+9631>,
0x55b673a57ab9 <exec_byte_code+9705>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57ebb <exec_byte_code+10731>,
0x55b673a57b0f <exec_byte_code+9791>, 0x55b673a57b5a <exec_byte_code+9866>,
0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57ebb <exec_byte_code+10731>,
0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57ebb <exec_byte_code+10731>,
0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57129 <exec_byte_code+7257> <repeats 64
times>}
const_length = <optimized out>
bytestr_length = <optimized out>
vectorp = 0x7f437ee3a560
quitcounter = 1 '\001'
stack_items = <optimized out>
sa_avail = <optimized out>
sa_count = <optimized out>
alloc = <optimized out>
stack_base = <optimized out>
top = 0x7ffc39390248
stack_lim = <optimized out>
bytestr_data = 0x7ffc39390270 "\003`X\204\020"
pc = <optimized out>
count = 39
result = <optimized out>
#76 0x000055b673a1b159 in Ffuncall (nargs=5, args=0x7ffc393903e0) at
eval.c:3052
fun = <optimized out>
original_fun = 0x298d0af435d8
funcar = <optimized out>
numargs = 4
val = <optimized out>
count = 38
#77 0x00007f436ddd8b7c in F63726d2d636f6d706c657465_crm_complete_0 () at
/home/alex/.emacs.d/eln-cache/28.0.50-d7cb8ced/crm-f08665f2-16cdb47d.eln
#78 0x000055b673a1b2ab in Ffuncall (nargs=nargs <at> entry=1,
args=args <at> entry=0x7ffc39390658)
at lisp.h:2093
fun = <optimized out>
original_fun = 0x85317b0
funcar = <optimized out>
numargs = 0
val = <optimized out>
count = 37
#79 0x000055b673a17b80 in Ffuncall_interactively (nargs=1,
args=0x7ffc39390658) at callint.c:260
speccount = 36
#80 0x000055b673a1b2ab in Ffuncall (nargs=2, args=0x7ffc39390650) at
lisp.h:2093
fun = <optimized out>
original_fun = 0x7410
funcar = <optimized out>
numargs = 1
val = <optimized out>
count = 35
#81 0x000055b673a1b5d9 in Fapply (nargs=nargs <at> entry=3,
args=args <at> entry=0x7ffc39390650)
at eval.c:2619
i = <optimized out>
funcall_nargs = <optimized out>
funcall_args = 0x0
spread_arg = 0x0
fun = 0x7410
sa_avail = 16384
sa_count = 35
numargs = <optimized out>
retval = <optimized out>
#82 0x000055b673a191ce in Fcall_interactively (function=0x85317b0,
record_flag=0x0, keys=0x55b6764762f5) at lisp.h:1008
funval = <optimized out>
events = <optimized out>
input = <optimized out>
speccount = <optimized out>
arg_from_tty = false
key_count = 1
record_then_fail = false
save_this_command = 0x85317b0
save_this_original_command = 0x298d0af43548
save_real_this_command = 0x85317b0
save_last_command = 0x298d0af75cd8
prefix_arg = 0x0
enable = <optimized out>
up_event = 0x0
form = <optimized out>
specs = 0x0
sa_avail = <optimized out>
string_len = <optimized out>
string = <optimized out>
string_end = <optimized out>
next_event = <optimized out>
nargs = <optimized out>
args = <optimized out>
visargs = <optimized out>
varies = <optimized out>
tem = <optimized out>
val = <optimized out>
#83 0x000055b673a1b2ab in Ffuncall (nargs=4, args=args <at> entry=0x7ffc39390748)
at lisp.h:2093
fun = <optimized out>
original_fun = 0x298d0aec04a8
funcar = <optimized out>
numargs = 3
val = <optimized out>
count = 33
#84 0x000055b673a55830 in exec_byte_code (bytestr=<optimized out>,
vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized
out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:632
op = <optimized out>
type = <optimized out>
targets = {0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a579d8
<exec_byte_code+9480>, 0x55b673a579dd <exec_byte_code+9485>, 0x55b673a579e2
<exec_byte_code+9490>, 0x55b673a55717 <exec_byte_code+583>, 0x55b673a55717
<exec_byte_code+583>, 0x55b673a579e7 <exec_byte_code+9495>, 0x55b673a57a26
<exec_byte_code+9558>, 0x55b673a56a0a <exec_byte_code+5434>, 0x55b673a56a0f
<exec_byte_code+5439>, 0x55b673a56a14 <exec_byte_code+5444>, 0x55b673a56a19
<exec_byte_code+5449>, 0x55b673a55752 <exec_byte_code+642>, 0x55b673a55758
<exec_byte_code+648>, 0x55b673a56a1e <exec_byte_code+5454>, 0x55b673a569f3
<exec_byte_code+5411>, 0x55b673a56b75 <exec_byte_code+5797>, 0x55b673a56b7a
<exec_byte_code+5802>, 0x55b673a56b7f <exec_byte_code+5807>, 0x55b673a56b84
<exec_byte_code+5812>, 0x55b673a556a4 <exec_byte_code+468>, 0x55b673a556a8
<exec_byte_code+472>, 0x55b673a56ba0 <exec_byte_code+5840>, 0x55b673a56b89
<exec_byte_code+5817>, 0x55b673a56c06 <exec_byte_code+5942>, 0x55b673a56c0b
<exec_byte_code+5947>, 0x55b673a56c10 <exec_byte_code+5952>, 0x55b673a56c15
<exec_byte_code+5957>, 0x55b673a55856 <exec_byte_code+902>, 0x55b673a55860
<exec_byte_code+912>, 0x55b673a56be2 <exec_byte_code+5906>, 0x55b673a56bef
<exec_byte_code+5919>, 0x55b673a56c3e <exec_byte_code+5998>, 0x55b673a56c43
<exec_byte_code+6003>, 0x55b673a56c48 <exec_byte_code+6008>, 0x55b673a56c4d
<exec_byte_code+6013>, 0x55b673a5580f <exec_byte_code+831>, 0x55b673a55810
<exec_byte_code+832>, 0x55b673a56c1a <exec_byte_code+5962>, 0x55b673a56c27
<exec_byte_code+5975>, 0x55b673a56c76 <exec_byte_code+6054>, 0x55b673a56c7b
<exec_byte_code+6059>, 0x55b673a56c80 <exec_byte_code+6064>, 0x55b673a56c85
<exec_byte_code+6069>, 0x55b673a557b5 <exec_byte_code+741>, 0x55b673a557b8
<exec_byte_code+744>, 0x55b673a56c52 <exec_byte_code+6018>, 0x55b673a56c5f
<exec_byte_code+6031>, 0x55b673a57355 <exec_byte_code+7813>, 0x55b673a570a0
<exec_byte_code+7120>, 0x55b673a57024 <exec_byte_code+6996>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57ebb <exec_byte_code+10731>,
0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57ebb <exec_byte_code+10731>,
0x55b673a55aae <exec_byte_code+1502>, 0x55b673a55b08 <exec_byte_code+1592>,
0x55b673a55b4e <exec_byte_code+1662>, 0x55b673a55b97 <exec_byte_code+1735>,
0x55b673a55be0 <exec_byte_code+1808>, 0x55b673a56aac <exec_byte_code+5596>,
0x55b673a56af7 <exec_byte_code+5671>, 0x55b673a55c28 <exec_byte_code+1880>,
0x55b673a56a70 <exec_byte_code+5536>, 0x55b673a56b39 <exec_byte_code+5737>,
0x55b673a55c5c <exec_byte_code+1932>, 0x55b673a55c9e <exec_byte_code+1998>,
0x55b673a55cd0 <exec_byte_code+2048>, 0x55b673a55d12 <exec_byte_code+2114>,
0x55b673a55d51 <exec_byte_code+2177>, 0x55b673a55ddf <exec_byte_code+2319>,
0x55b673a55e11 <exec_byte_code+2369>, 0x55b673a55e53 <exec_byte_code+2435>,
0x55b673a55e99 <exec_byte_code+2505>, 0x55b673a55ecb <exec_byte_code+2555>,
0x55b673a55efd <exec_byte_code+2605>, 0x55b673a55f3f <exec_byte_code+2671>,
0x55b673a55f81 <exec_byte_code+2737>, 0x55b673a55fc3 <exec_byte_code+2803>,
0x55b673a56009 <exec_byte_code+2873>, 0x55b673a56045 <exec_byte_code+2933>,
0x55b673a56081 <exec_byte_code+2993>, 0x55b673a56108 <exec_byte_code+3128>,
0x55b673a56166 <exec_byte_code+3222>, 0x55b673a561c4 <exec_byte_code+3316>,
0x55b673a563b4 <exec_byte_code+3812>, 0x55b673a56326 <exec_byte_code+3670>,
0x55b673a5636d <exec_byte_code+3741>, 0x55b673a56208 <exec_byte_code+3384>,
0x55b673a5624f <exec_byte_code+3455>, 0x55b673a5628b <exec_byte_code+3515>,
0x55b673a562ea <exec_byte_code+3610>, 0x55b673a563fb <exec_byte_code+3883>,
0x55b673a56437 <exec_byte_code+3943>, 0x55b673a56473 <exec_byte_code+4003>,
0x55b673a5652d <exec_byte_code+4189>, 0x55b673a558db <exec_byte_code+1035>,
0x55b673a56579 <exec_byte_code+4265>, 0x55b673a565ab <exec_byte_code+4315>,
0x55b673a5662d <exec_byte_code+4445>, 0x55b673a56679 <exec_byte_code+4521>,
0x55b673a566c5 <exec_byte_code+4597>, 0x55b673a566f7 <exec_byte_code+4647>,
0x55b673a5672b <exec_byte_code+4699>, 0x55b673a5675f <exec_byte_code+4751>,
0x55b673a5679b <exec_byte_code+4811>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a567cf <exec_byte_code+4863>,
0x55b673a56803 <exec_byte_code+4915>, 0x55b673a56837 <exec_byte_code+4967>,
0x55b673a5686b <exec_byte_code+5019>, 0x55b673a5689f <exec_byte_code+5071>,
0x55b673a568d3 <exec_byte_code+5123>, 0x55b673a558db <exec_byte_code+1035>,
0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a56905
<exec_byte_code+5173>, 0x55b673a5694d <exec_byte_code+5245>, 0x55b673a5697f
<exec_byte_code+5295>, 0x55b673a569b1 <exec_byte_code+5345>, 0x55b673a57160
<exec_byte_code+7312>, 0x55b673a571a2 <exec_byte_code+7378>, 0x55b673a571d4
<exec_byte_code+7428>, 0x55b673a5728f <exec_byte_code+7615>, 0x55b673a572d1
<exec_byte_code+7681>, 0x55b673a57313 <exec_byte_code+7747>, 0x55b673a57462
<exec_byte_code+8082>, 0x55b673a57496 <exec_byte_code+8134>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a56fb8 <exec_byte_code+6888>,
0x55b673a56cb7 <exec_byte_code+6119>, 0x55b673a56a2b <exec_byte_code+5467>,
0x55b673a56ce0 <exec_byte_code+6160>, 0x55b673a56d25 <exec_byte_code+6229>,
0x55b673a56d67 <exec_byte_code+6295>, 0x55b673a56f0a <exec_byte_code+6714>,
0x55b673a56f90 <exec_byte_code+6848>, 0x55b673a56bad <exec_byte_code+5853>,
0x55b673a56ffc <exec_byte_code+6956>, 0x55b673a570ae <exec_byte_code+7134>,
0x55b673a573e2 <exec_byte_code+7954>, 0x55b673a57419 <exec_byte_code+8009>,
0x55b673a5738b <exec_byte_code+7867>, 0x55b673a5599d <exec_byte_code+1229>,
0x55b673a559e3 <exec_byte_code+1299>, 0x55b673a55a2f <exec_byte_code+1375>,
0x55b673a56c8a <exec_byte_code+6074>, 0x55b673a574c8 <exec_byte_code+8184>,
0x55b673a5750e <exec_byte_code+8254>, 0x55b673a57540 <exec_byte_code+8304>,
0x55b673a57572 <exec_byte_code+8354>, 0x55b673a575a4 <exec_byte_code+8404>,
0x55b673a575d6 <exec_byte_code+8454>, 0x55b673a57618 <exec_byte_code+8520>,
0x55b673a5765a <exec_byte_code+8586>, 0x55b673a5769c <exec_byte_code+8652>,
0x55b673a576de <exec_byte_code+8718>, 0x55b673a5773f <exec_byte_code+8815>,
0x55b673a57781 <exec_byte_code+8881>, 0x55b673a577c3 <exec_byte_code+8947>,
0x55b673a577f5 <exec_byte_code+8997>, 0x55b673a57837 <exec_byte_code+9063>,
0x55b673a57879 <exec_byte_code+9129>, 0x55b673a578b8 <exec_byte_code+9192>,
0x55b673a578f7 <exec_byte_code+9255>, 0x55b673a564af <exec_byte_code+4063>,
0x55b673a564eb <exec_byte_code+4123>, 0x55b673a57933 <exec_byte_code+9315>,
0x55b673a5798c <exec_byte_code+9404>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a56da9 <exec_byte_code+6361>,
0x55b673a56e10 <exec_byte_code+6464>, 0x55b673a56e50 <exec_byte_code+6528>,
0x55b673a56e90 <exec_byte_code+6592>, 0x55b673a56ecd <exec_byte_code+6653>,
0x55b673a55d94 <exec_byte_code+2244>, 0x55b673a560bd <exec_byte_code+3053>,
0x55b673a565e2 <exec_byte_code+4370>, 0x55b673a57a6f <exec_byte_code+9631>,
0x55b673a57ab9 <exec_byte_code+9705>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57ebb <exec_byte_code+10731>,
0x55b673a57b0f <exec_byte_code+9791>, 0x55b673a57b5a <exec_byte_code+9866>,
0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57ebb <exec_byte_code+10731>,
0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57ebb <exec_byte_code+10731>,
0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57129 <exec_byte_code+7257> <repeats 64
times>}
const_length = <optimized out>
bytestr_length = <optimized out>
vectorp = 0x7f437eea0f68
quitcounter = 1 '\001'
stack_items = <optimized out>
sa_avail = <optimized out>
sa_count = <optimized out>
alloc = <optimized out>
stack_base = <optimized out>
top = 0x7ffc39390748
stack_lim = <optimized out>
bytestr_data = 0x7ffc39390780 "\304\020\211?\205\023"
pc = <optimized out>
count = 33
result = <optimized out>
#85 0x000055b673a1b159 in Ffuncall (nargs=2, args=0x7ffc39390960) at
eval.c:3052
fun = <optimized out>
original_fun = 0x4560
funcar = <optimized out>
numargs = 1
val = <optimized out>
count = 32
#86 0x000055b673a1b36a in call1 (fn=fn <at> entry=0x4560, arg1=<optimized
out>) at eval.c:2896
#87 0x000055b6739b0106 in command_loop_1 () at lisp.h:1008
scount = 31
cmd = <optimized out>
keybuf = {0x26, 0x7f436e4e9f05
<F77696e6e65722d72656d656d626572_winner_remember_0+133>, 0x2, 0x6008760,
0x0, 0x4000000010000000, 0x400000003f000000, 0x60087f0, 0x60087f0,
0x55b673a1b2ab <Ffuncall+651>, 0x55b673eff8c0 <lispsym+35232>, 0x0, 0x1e,
0x10055b673a21615, 0x55b67b67bb18, 0x55b67b67bfc8, 0x0, 0x55b673b328e0
<targets>, 0x1e, 0x7ffc393909c8, 0x7f437f1c9390, 0x7ffc393909b8,
0x55b673ef6f20 <lispsym>, 0x0, 0x400000003f000000, 0xb2d2410,
0x298d0b2d2410, 0x55b673ef6f20 <lispsym>, 0x4000000010000000,
0x55b673a1b159 <Ffuncall+313>}
i = <optimized out>
prev_modiff = 5569
prev_buffer = 0x55b6752432d0
#88 0x000055b673a1a362 in internal_condition_case
(bfun=bfun <at> entry=0x55b6739afd30
<command_loop_1>, handlers=handlers <at> entry=0x90, hfun=hfun <at> entry=0x55b6739a6ca0
<cmd_error>) at eval.c:1475
val = <optimized out>
c = 0x55b674810000
#89 0x000055b6739a1634 in command_loop_2 (ignore=ignore <at> entry=0x0) at
lisp.h:1008
val = <optimized out>
#90 0x000055b673a1c7c3 in internal_catch (tag=tag <at> entry=0x6120,
func=func <at> entry=0x55b6739a1610 <command_loop_2>, arg=arg <at> entry=0x0) at
eval.c:1198
val = <optimized out>
c = 0x55b674800650
#91 0x000055b6739a1595 in command_loop () at lisp.h:1008
val = <optimized out>
#92 0x000055b6739a68a6 in recursive_edit_1 () at keyboard.c:720
count = 29
val = <optimized out>
#93 0x000055b6739cee69 in read_minibuf (inherit_input_method=<optimized
out>, allow_props=<optimized out>, defalt=<optimized out>,
histpos=<optimized out>, histvar=0x3479e80, expflag=<optimized out>,
prompt=<optimized out>, initial=<optimized out>, map=<optimized out>) at
minibuf.c:894
pos = <optimized out>
histstring = <optimized out>
histval = <optimized out>
empty_minibuf = <optimized out>
count = <optimized out>
enable_multibyte = <optimized out>
val = 0x0
mini_frame = <optimized out>
minibuffer = 0x55b6752432d5
input_method = <optimized out>
calling_frame = 0x55b674ffcfe5
calling_window = <optimized out>
histvar = <optimized out>
histpos = <optimized out>
val = <optimized out>
#94 0x000055b6739cee69 in Fread_from_minibuffer (prompt=<optimized out>,
initial_contents=<optimized out>, keymap=<optimized out>, read=<optimized
out>, hist=<optimized out>, default_value=<optimized out>,
inherit_input_method=<optimized out>) at minibuf.c:1342
histvar = <optimized out>
histpos = <optimized out>
val = <optimized out>
#95 0x00007f436dd93bcd in
F6d616769742d636f6d706c6574696e672d726561642d6d756c7469706c65_magit_completing_read_multiple_0
() at
/home/alex/.emacs.d/eln-cache/28.0.50-d7cb8ced/magit-utils-47ce2b44-76d60e21.eln
#96 0x000055b673a1b2ab in Ffuncall (nargs=7, args=0x7ffc39390de0) at
lisp.h:2093
fun = <optimized out>
original_fun = 0x1d89ef0
funcar = <optimized out>
numargs = 6
val = <optimized out>
count = 10
#97 0x00007f436da65bf4 in
F6d616769742d6c6f672d726561642d72657673_magit_log_read_revs_0 () at
/home/alex/.emacs.d/eln-cache/28.0.50-d7cb8ced/magit-log-f581e47c-1c94118d.eln
#98 0x000055b673a1b2ab in Ffuncall (nargs=1, args=args <at> entry=0x7ffc39390eb8)
at lisp.h:2093
fun = <optimized out>
original_fun = 0x44160e0
funcar = <optimized out>
numargs = 0
val = <optimized out>
count = 9
#99 0x000055b673a55830 in exec_byte_code (bytestr=<optimized out>,
vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized
out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:632
op = <optimized out>
type = <optimized out>
targets = {0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a579d8
<exec_byte_code+9480>, 0x55b673a579dd <exec_byte_code+9485>, 0x55b673a579e2
<exec_byte_code+9490>, 0x55b673a55717 <exec_byte_code+583>, 0x55b673a55717
<exec_byte_code+583>, 0x55b673a579e7 <exec_byte_code+9495>, 0x55b673a57a26
<exec_byte_code+9558>, 0x55b673a56a0a <exec_byte_code+5434>, 0x55b673a56a0f
<exec_byte_code+5439>, 0x55b673a56a14 <exec_byte_code+5444>, 0x55b673a56a19
<exec_byte_code+5449>, 0x55b673a55752 <exec_byte_code+642>, 0x55b673a55758
<exec_byte_code+648>, 0x55b673a56a1e <exec_byte_code+5454>, 0x55b673a569f3
<exec_byte_code+5411>, 0x55b673a56b75 <exec_byte_code+5797>, 0x55b673a56b7a
<exec_byte_code+5802>, 0x55b673a56b7f <exec_byte_code+5807>, 0x55b673a56b84
<exec_byte_code+5812>, 0x55b673a556a4 <exec_byte_code+468>, 0x55b673a556a8
<exec_byte_code+472>, 0x55b673a56ba0 <exec_byte_code+5840>, 0x55b673a56b89
<exec_byte_code+5817>, 0x55b673a56c06 <exec_byte_code+5942>, 0x55b673a56c0b
<exec_byte_code+5947>, 0x55b673a56c10 <exec_byte_code+5952>, 0x55b673a56c15
<exec_byte_code+5957>, 0x55b673a55856 <exec_byte_code+902>, 0x55b673a55860
<exec_byte_code+912>, 0x55b673a56be2 <exec_byte_code+5906>, 0x55b673a56bef
<exec_byte_code+5919>, 0x55b673a56c3e <exec_byte_code+5998>, 0x55b673a56c43
<exec_byte_code+6003>, 0x55b673a56c48 <exec_byte_code+6008>, 0x55b673a56c4d
<exec_byte_code+6013>, 0x55b673a5580f <exec_byte_code+831>, 0x55b673a55810
<exec_byte_code+832>, 0x55b673a56c1a <exec_byte_code+5962>, 0x55b673a56c27
<exec_byte_code+5975>, 0x55b673a56c76 <exec_byte_code+6054>, 0x55b673a56c7b
<exec_byte_code+6059>, 0x55b673a56c80 <exec_byte_code+6064>, 0x55b673a56c85
<exec_byte_code+6069>, 0x55b673a557b5 <exec_byte_code+741>, 0x55b673a557b8
<exec_byte_code+744>, 0x55b673a56c52 <exec_byte_code+6018>, 0x55b673a56c5f
<exec_byte_code+6031>, 0x55b673a57355 <exec_byte_code+7813>, 0x55b673a570a0
<exec_byte_code+7120>, 0x55b673a57024 <exec_byte_code+6996>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57ebb <exec_byte_code+10731>,
0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57ebb <exec_byte_code+10731>,
0x55b673a55aae <exec_byte_code+1502>, 0x55b673a55b08 <exec_byte_code+1592>,
0x55b673a55b4e <exec_byte_code+1662>, 0x55b673a55b97 <exec_byte_code+1735>,
0x55b673a55be0 <exec_byte_code+1808>, 0x55b673a56aac <exec_byte_code+5596>,
0x55b673a56af7 <exec_byte_code+5671>, 0x55b673a55c28 <exec_byte_code+1880>,
0x55b673a56a70 <exec_byte_code+5536>, 0x55b673a56b39 <exec_byte_code+5737>,
0x55b673a55c5c <exec_byte_code+1932>, 0x55b673a55c9e <exec_byte_code+1998>,
0x55b673a55cd0 <exec_byte_code+2048>, 0x55b673a55d12 <exec_byte_code+2114>,
0x55b673a55d51 <exec_byte_code+2177>, 0x55b673a55ddf <exec_byte_code+2319>,
0x55b673a55e11 <exec_byte_code+2369>, 0x55b673a55e53 <exec_byte_code+2435>,
0x55b673a55e99 <exec_byte_code+2505>, 0x55b673a55ecb <exec_byte_code+2555>,
0x55b673a55efd <exec_byte_code+2605>, 0x55b673a55f3f <exec_byte_code+2671>,
0x55b673a55f81 <exec_byte_code+2737>, 0x55b673a55fc3 <exec_byte_code+2803>,
0x55b673a56009 <exec_byte_code+2873>, 0x55b673a56045 <exec_byte_code+2933>,
0x55b673a56081 <exec_byte_code+2993>, 0x55b673a56108 <exec_byte_code+3128>,
0x55b673a56166 <exec_byte_code+3222>, 0x55b673a561c4 <exec_byte_code+3316>,
0x55b673a563b4 <exec_byte_code+3812>, 0x55b673a56326 <exec_byte_code+3670>,
0x55b673a5636d <exec_byte_code+3741>, 0x55b673a56208 <exec_byte_code+3384>,
0x55b673a5624f <exec_byte_code+3455>, 0x55b673a5628b <exec_byte_code+3515>,
0x55b673a562ea <exec_byte_code+3610>, 0x55b673a563fb <exec_byte_code+3883>,
0x55b673a56437 <exec_byte_code+3943>, 0x55b673a56473 <exec_byte_code+4003>,
0x55b673a5652d <exec_byte_code+4189>, 0x55b673a558db <exec_byte_code+1035>,
0x55b673a56579 <exec_byte_code+4265>, 0x55b673a565ab <exec_byte_code+4315>,
0x55b673a5662d <exec_byte_code+4445>, 0x55b673a56679 <exec_byte_code+4521>,
0x55b673a566c5 <exec_byte_code+4597>, 0x55b673a566f7 <exec_byte_code+4647>,
0x55b673a5672b <exec_byte_code+4699>, 0x55b673a5675f <exec_byte_code+4751>,
0x55b673a5679b <exec_byte_code+4811>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a567cf <exec_byte_code+4863>,
0x55b673a56803 <exec_byte_code+4915>, 0x55b673a56837 <exec_byte_code+4967>,
0x55b673a5686b <exec_byte_code+5019>, 0x55b673a5689f <exec_byte_code+5071>,
0x55b673a568d3 <exec_byte_code+5123>, 0x55b673a558db <exec_byte_code+1035>,
0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a56905
<exec_byte_code+5173>, 0x55b673a5694d <exec_byte_code+5245>, 0x55b673a5697f
<exec_byte_code+5295>, 0x55b673a569b1 <exec_byte_code+5345>, 0x55b673a57160
<exec_byte_code+7312>, 0x55b673a571a2 <exec_byte_code+7378>, 0x55b673a571d4
<exec_byte_code+7428>, 0x55b673a5728f <exec_byte_code+7615>, 0x55b673a572d1
<exec_byte_code+7681>, 0x55b673a57313 <exec_byte_code+7747>, 0x55b673a57462
<exec_byte_code+8082>, 0x55b673a57496 <exec_byte_code+8134>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a56fb8 <exec_byte_code+6888>,
0x55b673a56cb7 <exec_byte_code+6119>, 0x55b673a56a2b <exec_byte_code+5467>,
0x55b673a56ce0 <exec_byte_code+6160>, 0x55b673a56d25 <exec_byte_code+6229>,
0x55b673a56d67 <exec_byte_code+6295>, 0x55b673a56f0a <exec_byte_code+6714>,
0x55b673a56f90 <exec_byte_code+6848>, 0x55b673a56bad <exec_byte_code+5853>,
0x55b673a56ffc <exec_byte_code+6956>, 0x55b673a570ae <exec_byte_code+7134>,
0x55b673a573e2 <exec_byte_code+7954>, 0x55b673a57419 <exec_byte_code+8009>,
0x55b673a5738b <exec_byte_code+7867>, 0x55b673a5599d <exec_byte_code+1229>,
0x55b673a559e3 <exec_byte_code+1299>, 0x55b673a55a2f <exec_byte_code+1375>,
0x55b673a56c8a <exec_byte_code+6074>, 0x55b673a574c8 <exec_byte_code+8184>,
0x55b673a5750e <exec_byte_code+8254>, 0x55b673a57540 <exec_byte_code+8304>,
0x55b673a57572 <exec_byte_code+8354>, 0x55b673a575a4 <exec_byte_code+8404>,
0x55b673a575d6 <exec_byte_code+8454>, 0x55b673a57618 <exec_byte_code+8520>,
0x55b673a5765a <exec_byte_code+8586>, 0x55b673a5769c <exec_byte_code+8652>,
0x55b673a576de <exec_byte_code+8718>, 0x55b673a5773f <exec_byte_code+8815>,
0x55b673a57781 <exec_byte_code+8881>, 0x55b673a577c3 <exec_byte_code+8947>,
0x55b673a577f5 <exec_byte_code+8997>, 0x55b673a57837 <exec_byte_code+9063>,
0x55b673a57879 <exec_byte_code+9129>, 0x55b673a578b8 <exec_byte_code+9192>,
0x55b673a578f7 <exec_byte_code+9255>, 0x55b673a564af <exec_byte_code+4063>,
0x55b673a564eb <exec_byte_code+4123>, 0x55b673a57933 <exec_byte_code+9315>,
0x55b673a5798c <exec_byte_code+9404>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a56da9 <exec_byte_code+6361>,
0x55b673a56e10 <exec_byte_code+6464>, 0x55b673a56e50 <exec_byte_code+6528>,
0x55b673a56e90 <exec_byte_code+6592>, 0x55b673a56ecd <exec_byte_code+6653>,
0x55b673a55d94 <exec_byte_code+2244>, 0x55b673a560bd <exec_byte_code+3053>,
0x55b673a565e2 <exec_byte_code+4370>, 0x55b673a57a6f <exec_byte_code+9631>,
0x55b673a57ab9 <exec_byte_code+9705>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57ebb <exec_byte_code+10731>,
0x55b673a57b0f <exec_byte_code+9791>, 0x55b673a57b5a <exec_byte_code+9866>,
0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57ebb <exec_byte_code+10731>,
0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57ebb <exec_byte_code+10731>,
0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57129 <exec_byte_code+7257> <repeats 64
times>}
const_length = <optimized out>
bytestr_length = <optimized out>
vectorp = 0x55b6760ddfa8
quitcounter = 1 '\001'
stack_items = <optimized out>
sa_avail = <optimized out>
sa_count = <optimized out>
alloc = <optimized out>
stack_base = <optimized out>
top = 0x7ffc39390eb8
stack_lim = <optimized out>
bytestr_data = 0x7ffc39390ec8 "\300 \301 B\207"
pc = <optimized out>
count = 9
result = <optimized out>
#100 0x000055b673a1d6a1 in eval_sub (form=<optimized out>) at lisp.h:2093
i = <optimized out>
maxargs = 3
args_left = 0x0
numargs = 3
original_fun = <optimized out>
original_args = 0x55b67c4794b3
count = 8
fun = <optimized out>
val = <optimized out>
funcar = <optimized out>
argvals = {0x55b678894334, 0x55b6760ddfa5, 0xa,
0x4000000010000000, 0x400000003f000000, 0x55b673a23940 <Fget+64>,
0x21c4c300118420c2, 0x4416140}
#101 0x000055b673a1f098 in Feval (form=form <at> entry=0x55b67be32433,
lexical=<optimized out>) at eval.c:2340
count = 7
#102 0x000055b673a1907c in Fcall_interactively (function=0x4416140,
record_flag=0x0, keys=0x55b6764762f5) at lisp.h:1420
funval = <optimized out>
events = 12874
input = 0x55b67be32433
speccount = <optimized out>
arg_from_tty = false
key_count = 1
record_then_fail = false
save_this_command = 0x4416140
save_this_original_command = 0x4416140
save_real_this_command = 0x4416140
save_last_command = 0x32fe7e0
prefix_arg = 0x0
enable = 0x0
up_event = 0x0
form = <optimized out>
specs = 0x55b67be32433
sa_avail = <optimized out>
string_len = <optimized out>
string = <optimized out>
string_end = <optimized out>
next_event = <optimized out>
nargs = <optimized out>
args = <optimized out>
visargs = <optimized out>
varies = <optimized out>
tem = <optimized out>
val = <optimized out>
#103 0x000055b673a1b2ab in Ffuncall (nargs=4, args=args <at> entry=0x7ffc39391258)
at lisp.h:2093
fun = <optimized out>
original_fun = 0x298d0aec04a8
funcar = <optimized out>
numargs = 3
val = <optimized out>
count = 5
#104 0x000055b673a55830 in exec_byte_code (bytestr=<optimized out>,
vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized
out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:632
op = <optimized out>
type = <optimized out>
targets = {0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a579d8
<exec_byte_code+9480>, 0x55b673a579dd <exec_byte_code+9485>, 0x55b673a579e2
<exec_byte_code+9490>, 0x55b673a55717 <exec_byte_code+583>, 0x55b673a55717
<exec_byte_code+583>, 0x55b673a579e7 <exec_byte_code+9495>, 0x55b673a57a26
<exec_byte_code+9558>, 0x55b673a56a0a <exec_byte_code+5434>, 0x55b673a56a0f
<exec_byte_code+5439>, 0x55b673a56a14 <exec_byte_code+5444>, 0x55b673a56a19
<exec_byte_code+5449>, 0x55b673a55752 <exec_byte_code+642>, 0x55b673a55758
<exec_byte_code+648>, 0x55b673a56a1e <exec_byte_code+5454>, 0x55b673a569f3
<exec_byte_code+5411>, 0x55b673a56b75 <exec_byte_code+5797>, 0x55b673a56b7a
<exec_byte_code+5802>, 0x55b673a56b7f <exec_byte_code+5807>, 0x55b673a56b84
<exec_byte_code+5812>, 0x55b673a556a4 <exec_byte_code+468>, 0x55b673a556a8
<exec_byte_code+472>, 0x55b673a56ba0 <exec_byte_code+5840>, 0x55b673a56b89
<exec_byte_code+5817>, 0x55b673a56c06 <exec_byte_code+5942>, 0x55b673a56c0b
<exec_byte_code+5947>, 0x55b673a56c10 <exec_byte_code+5952>, 0x55b673a56c15
<exec_byte_code+5957>, 0x55b673a55856 <exec_byte_code+902>, 0x55b673a55860
<exec_byte_code+912>, 0x55b673a56be2 <exec_byte_code+5906>, 0x55b673a56bef
<exec_byte_code+5919>, 0x55b673a56c3e <exec_byte_code+5998>, 0x55b673a56c43
<exec_byte_code+6003>, 0x55b673a56c48 <exec_byte_code+6008>, 0x55b673a56c4d
<exec_byte_code+6013>, 0x55b673a5580f <exec_byte_code+831>, 0x55b673a55810
<exec_byte_code+832>, 0x55b673a56c1a <exec_byte_code+5962>, 0x55b673a56c27
<exec_byte_code+5975>, 0x55b673a56c76 <exec_byte_code+6054>, 0x55b673a56c7b
<exec_byte_code+6059>, 0x55b673a56c80 <exec_byte_code+6064>, 0x55b673a56c85
<exec_byte_code+6069>, 0x55b673a557b5 <exec_byte_code+741>, 0x55b673a557b8
<exec_byte_code+744>, 0x55b673a56c52 <exec_byte_code+6018>, 0x55b673a56c5f
<exec_byte_code+6031>, 0x55b673a57355 <exec_byte_code+7813>, 0x55b673a570a0
<exec_byte_code+7120>, 0x55b673a57024 <exec_byte_code+6996>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57ebb <exec_byte_code+10731>,
0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57ebb <exec_byte_code+10731>,
0x55b673a55aae <exec_byte_code+1502>, 0x55b673a55b08 <exec_byte_code+1592>,
0x55b673a55b4e <exec_byte_code+1662>, 0x55b673a55b97 <exec_byte_code+1735>,
0x55b673a55be0 <exec_byte_code+1808>, 0x55b673a56aac <exec_byte_code+5596>,
0x55b673a56af7 <exec_byte_code+5671>, 0x55b673a55c28 <exec_byte_code+1880>,
0x55b673a56a70 <exec_byte_code+5536>, 0x55b673a56b39 <exec_byte_code+5737>,
0x55b673a55c5c <exec_byte_code+1932>, 0x55b673a55c9e <exec_byte_code+1998>,
0x55b673a55cd0 <exec_byte_code+2048>, 0x55b673a55d12 <exec_byte_code+2114>,
0x55b673a55d51 <exec_byte_code+2177>, 0x55b673a55ddf <exec_byte_code+2319>,
0x55b673a55e11 <exec_byte_code+2369>, 0x55b673a55e53 <exec_byte_code+2435>,
0x55b673a55e99 <exec_byte_code+2505>, 0x55b673a55ecb <exec_byte_code+2555>,
0x55b673a55efd <exec_byte_code+2605>, 0x55b673a55f3f <exec_byte_code+2671>,
0x55b673a55f81 <exec_byte_code+2737>, 0x55b673a55fc3 <exec_byte_code+2803>,
0x55b673a56009 <exec_byte_code+2873>, 0x55b673a56045 <exec_byte_code+2933>,
0x55b673a56081 <exec_byte_code+2993>, 0x55b673a56108 <exec_byte_code+3128>,
0x55b673a56166 <exec_byte_code+3222>, 0x55b673a561c4 <exec_byte_code+3316>,
0x55b673a563b4 <exec_byte_code+3812>, 0x55b673a56326 <exec_byte_code+3670>,
0x55b673a5636d <exec_byte_code+3741>, 0x55b673a56208 <exec_byte_code+3384>,
0x55b673a5624f <exec_byte_code+3455>, 0x55b673a5628b <exec_byte_code+3515>,
0x55b673a562ea <exec_byte_code+3610>, 0x55b673a563fb <exec_byte_code+3883>,
0x55b673a56437 <exec_byte_code+3943>, 0x55b673a56473 <exec_byte_code+4003>,
0x55b673a5652d <exec_byte_code+4189>, 0x55b673a558db <exec_byte_code+1035>,
0x55b673a56579 <exec_byte_code+4265>, 0x55b673a565ab <exec_byte_code+4315>,
0x55b673a5662d <exec_byte_code+4445>, 0x55b673a56679 <exec_byte_code+4521>,
0x55b673a566c5 <exec_byte_code+4597>, 0x55b673a566f7 <exec_byte_code+4647>,
0x55b673a5672b <exec_byte_code+4699>, 0x55b673a5675f <exec_byte_code+4751>,
0x55b673a5679b <exec_byte_code+4811>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a567cf <exec_byte_code+4863>,
0x55b673a56803 <exec_byte_code+4915>, 0x55b673a56837 <exec_byte_code+4967>,
0x55b673a5686b <exec_byte_code+5019>, 0x55b673a5689f <exec_byte_code+5071>,
0x55b673a568d3 <exec_byte_code+5123>, 0x55b673a558db <exec_byte_code+1035>,
0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a56905
<exec_byte_code+5173>, 0x55b673a5694d <exec_byte_code+5245>, 0x55b673a5697f
<exec_byte_code+5295>, 0x55b673a569b1 <exec_byte_code+5345>, 0x55b673a57160
<exec_byte_code+7312>, 0x55b673a571a2 <exec_byte_code+7378>, 0x55b673a571d4
<exec_byte_code+7428>, 0x55b673a5728f <exec_byte_code+7615>, 0x55b673a572d1
<exec_byte_code+7681>, 0x55b673a57313 <exec_byte_code+7747>, 0x55b673a57462
<exec_byte_code+8082>, 0x55b673a57496 <exec_byte_code+8134>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a56fb8 <exec_byte_code+6888>,
0x55b673a56cb7 <exec_byte_code+6119>, 0x55b673a56a2b <exec_byte_code+5467>,
0x55b673a56ce0 <exec_byte_code+6160>, 0x55b673a56d25 <exec_byte_code+6229>,
0x55b673a56d67 <exec_byte_code+6295>, 0x55b673a56f0a <exec_byte_code+6714>,
0x55b673a56f90 <exec_byte_code+6848>, 0x55b673a56bad <exec_byte_code+5853>,
0x55b673a56ffc <exec_byte_code+6956>, 0x55b673a570ae <exec_byte_code+7134>,
0x55b673a573e2 <exec_byte_code+7954>, 0x55b673a57419 <exec_byte_code+8009>,
0x55b673a5738b <exec_byte_code+7867>, 0x55b673a5599d <exec_byte_code+1229>,
0x55b673a559e3 <exec_byte_code+1299>, 0x55b673a55a2f <exec_byte_code+1375>,
0x55b673a56c8a <exec_byte_code+6074>, 0x55b673a574c8 <exec_byte_code+8184>,
0x55b673a5750e <exec_byte_code+8254>, 0x55b673a57540 <exec_byte_code+8304>,
0x55b673a57572 <exec_byte_code+8354>, 0x55b673a575a4 <exec_byte_code+8404>,
0x55b673a575d6 <exec_byte_code+8454>, 0x55b673a57618 <exec_byte_code+8520>,
0x55b673a5765a <exec_byte_code+8586>, 0x55b673a5769c <exec_byte_code+8652>,
0x55b673a576de <exec_byte_code+8718>, 0x55b673a5773f <exec_byte_code+8815>,
0x55b673a57781 <exec_byte_code+8881>, 0x55b673a577c3 <exec_byte_code+8947>,
0x55b673a577f5 <exec_byte_code+8997>, 0x55b673a57837 <exec_byte_code+9063>,
0x55b673a57879 <exec_byte_code+9129>, 0x55b673a578b8 <exec_byte_code+9192>,
0x55b673a578f7 <exec_byte_code+9255>, 0x55b673a564af <exec_byte_code+4063>,
0x55b673a564eb <exec_byte_code+4123>, 0x55b673a57933 <exec_byte_code+9315>,
0x55b673a5798c <exec_byte_code+9404>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a56da9 <exec_byte_code+6361>,
0x55b673a56e10 <exec_byte_code+6464>, 0x55b673a56e50 <exec_byte_code+6528>,
0x55b673a56e90 <exec_byte_code+6592>, 0x55b673a56ecd <exec_byte_code+6653>,
0x55b673a55d94 <exec_byte_code+2244>, 0x55b673a560bd <exec_byte_code+3053>,
0x55b673a565e2 <exec_byte_code+4370>, 0x55b673a57a6f <exec_byte_code+9631>,
0x55b673a57ab9 <exec_byte_code+9705>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57ebb <exec_byte_code+10731>,
0x55b673a57b0f <exec_byte_code+9791>, 0x55b673a57b5a <exec_byte_code+9866>,
0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57ebb <exec_byte_code+10731>,
0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57ebb <exec_byte_code+10731>,
0x55b673a57ebb <exec_byte_code+10731>, 0x55b673a57ebb
<exec_byte_code+10731>, 0x55b673a57129 <exec_byte_code+7257> <repeats 64
times>}
const_length = <optimized out>
bytestr_length = <optimized out>
vectorp = 0x7f437eea0f68
quitcounter = 1 '\001'
stack_items = <optimized out>
sa_avail = <optimized out>
sa_count = <optimized out>
alloc = <optimized out>
stack_base = <optimized out>
top = 0x7ffc39391258
stack_lim = <optimized out>
bytestr_data = 0x7ffc39391290 "\304\020\211?\205\023"
pc = <optimized out>
count = 5
result = <optimized out>
#105 0x000055b673a1b159 in Ffuncall (nargs=2, args=0x7ffc39391470) at
eval.c:3052
fun = <optimized out>
original_fun = 0x4560
funcar = <optimized out>
numargs = 1
val = <optimized out>
count = 4
#106 0x000055b673a1b36a in call1 (fn=fn <at> entry=0x4560, arg1=<optimized
out>) at eval.c:2896
#107 0x000055b6739b0106 in command_loop_1 () at lisp.h:1008
scount = 3
cmd = <optimized out>
keybuf = {0x1be, 0xc6, 0x1e, 0x3, 0x3, 0x7ffc39391558, 0x0,
0x55b67fa6b213, 0x7ffc393915a0, 0x0, 0x55b67fa6b213, 0x7ffc39391708,
0xffffffffffffffff, 0x55b673a1e254 <call3+36>, 0x7f437f467845,
0x55b67fa6b213, 0x7f437edae524, 0x0, 0x7ffc393915a0, 0x55b6739a6c71
<cmd_error_internal+113>, 0x7ffc393915a0, 0x0, 0x0, 0x55b6739a6d9d
<cmd_error+253>, 0x7ffc39391700, 0x55b673a1adc4 <unbind_to+132>, 0xa,
0x89a0, 0x0, 0x7f437edaa70d}
i = <optimized out>
prev_modiff = 84
prev_buffer = 0x55b67b7dde30
#108 0x000055b673a1a362 in internal_condition_case
(bfun=bfun <at> entry=0x55b6739afd30
<command_loop_1>, handlers=handlers <at> entry=0x90, hfun=hfun <at> entry=0x55b6739a6ca0
<cmd_error>) at eval.c:1475
val = <optimized out>
c = 0x55b6748000b0
#109 0x000055b6739a1634 in command_loop_2 (ignore=ignore <at> entry=0x0) at
lisp.h:1008
val = <optimized out>
#110 0x000055b673a1c7c3 in internal_catch (tag=tag <at> entry=0xe4c0,
func=func <at> entry=0x55b6739a1610 <command_loop_2>, arg=arg <at> entry=0x0) at
eval.c:1198
val = <optimized out>
c = 0x55b6747e9400
#111 0x000055b6739a15db in command_loop () at lisp.h:1008
#112 0x000055b6739a68a6 in recursive_edit_1 () at keyboard.c:720
count = 1
val = <optimized out>
#113 0x000055b6739a6bc5 in Frecursive_edit () at keyboard.c:789
buffer = <optimized out>
#114 0x000055b6738c6414 in main (argc=2, argv=<optimized out>) at
emacs.c:2297
stack_bottom_variable = 0x0
no_loadup = false
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x0
original_pwd = <optimized out>
dump_mode = <optimized out>
skip_args = 1
temacs = 0x0
attempt_load_pdump = <optimized out>
rlim = {rlim_cur = 10022912, rlim_max = 18446744073709551615}
lc_all = <optimized out>
sockfd = -1
module_assertions = <optimized out>
In GNU Emacs 28.0.50 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo
version 1.16.0, Xaw3d scroll bars)
of 2021-05-10 built on zen
Repository revision: 02c80307f13f7ffe3dc024aee72e47060b4a1996
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
System Description: Debian GNU/Linux 10 (buster)
Configured using:
'configure --with-x-toolkit=lucid --prefix=/home/alex/src/emacs/install
--with-modules --with-imagemagick --with-native-compilation'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ
IMAGEMAGICK JPEG JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2
M17N_FLT MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP
SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XAW3D XDBE XIM XPM LUCID ZLIB
Important settings:
value of $LANG: en_GB.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: Summary
Minor modes in effect:
circe-lagmon-mode: t
which-key-mode: t
recentf-mode: t
golden-ratio-mode: t
doom-modeline-mode: t
global-atomic-chrome-edit-mode: t
global-edit-server-edit-mode: t
winner-mode: t
yas-global-mode: t
yas-minor-mode: t
global-company-mode: t
company-mode: t
pyvenv-mode: t
shell-dirtrack-mode: t
show-paren-mode: t
electric-pair-mode: t
editorconfig-mode: t
which-function-mode: t
display-time-mode: t
tracking-mode: t
midnight-mode: t
counsel-mode: t
ivy-mode: t
delete-selection-mode: t
global-auto-revert-mode: t
savehist-mode: t
async-bytecomp-package-mode: t
override-global-mode: t
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-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
buffer-read-only: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
/home/alex/src/emacs/swiper.git/counsel hides
/home/alex/.emacs.d/elpa/counsel-20210509.830/counsel
/home/alex/mysrc/edit-with-emacs.git/servers/edit-server hides
/home/alex/.emacs.d/elpa/edit-server-20181016.1125/edit-server
/home/alex/src/emacs/swiper.git/ivy-hydra hides
/home/alex/.emacs.d/elpa/ivy-hydra-20210311.1108/ivy-hydra
/home/alex/.emacs.d/elpa/magit-20210430.404/magit-section hides
/home/alex/.emacs.d/elpa/magit-section-20210224.1417/magit-section
/home/alex/src/emacs/swiper.git/swiper hides
/home/alex/.emacs.d/elpa/swiper-20210509.1535/swiper
/home/alex/src/emacs/swiper.git/elpa hides
/home/alex/.emacs.d/elpa/ivy-20210506.2157/elpa
/home/alex/src/emacs/swiper.git/ivy-overlay hides
/home/alex/.emacs.d/elpa/ivy-20210506.2157/ivy-overlay
/home/alex/src/emacs/swiper.git/ivy hides
/home/alex/.emacs.d/elpa/ivy-20210506.2157/ivy
/home/alex/src/emacs/swiper.git/ivy-faces hides
/home/alex/.emacs.d/elpa/ivy-20210506.2157/ivy-faces
/home/alex/src/emacs/swiper.git/colir hides
/home/alex/.emacs.d/elpa/ivy-20210506.2157/colir
/home/alex/.emacs.d/elpa/circe-20210508.1616/shorten hides
/home/alex/.emacs.d/elpa/tracking-20201101.1045/shorten
/home/alex/.emacs.d/elpa/circe-20210508.1616/tracking hides
/home/alex/.emacs.d/elpa/tracking-20201101.1045/tracking
/home/alex/.emacs.d/elpa/transient-20210426.2141/transient hides
/home/alex/src/emacs/install/share/emacs/28.0.50/lisp/transient
Features:
(mc-hide-unmatched-lines-mode mc-mark-more mc-cycle-cursors
multiple-cursors-core rect cl-print mailalias mailclient ffap
lusty-explorer ace-window avy sort gnus-cite gnus-async gnus-bcklg qp
gnus-ml disp-table nndraft nnmh nnfolder epa-file lui-logging
lui-autopaste cursor-sensor circe-lagmon circe-color-nicks circe-chanop
circe lui-irc-colors irc lcs lui-format circe-compat which-key
keychain-environment tramp-cache recentf tree-widget golden-ratio shadow
emacsbug mu4e mu4e-org mu4e-main mu4e-view face-remap add-log server
ws-butler company-oddmuse company-keywords company-etags company-gtags
company-template company-dabbrev-code company-dabbrev company-files
company-cmake doom-modeline doom-modeline-segments doom-modeline-env
doom-modeline-core shrink-path all-the-icons all-the-icons-faces
data-material data-weathericons data-octicons data-fileicons
data-faicons data-alltheicons atomic-chrome websocket bindat edit-server
init my-elfeed elfeed-show elfeed-search elfeed-csv elfeed elfeed-curl
elfeed-log elfeed-db elfeed-lib xml-query my-diff my-circe lui flyspell
tls my-eshell em-hist em-pred my-htmlize my-gpg auth-source-pass
my-spell ispell my-tramp my-yasnippet my-company mm-archive gnutls
network-stream url-cache my-local-pkgs json-mode json-reformat
json-snatcher js xml-rpc timezone url-http url-auth url-gw nsm
my-keyhelp my-dired dired-rsync dired-quick-sort dired-async dired-aux
my-buffer bufler pretty-hydra bufler-group-tree magit-section
dash-functional vc my-windows winner windmove my-toggles whitespace
my-org ess ess-utils ess-custom ob-sqlite ob-python ob-makefile ob-ditaa
ob-dot ob-C cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles
cc-align cc-engine cc-vars cc-defs ob-perl ob-gnuplot ob-shell ol-eww
eww url-queue mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect
gnus-search eieio-opt speedbar ezimage dframe ol-docview ol-bibtex
bibtex ol-bbdb ol-w3m editorconfig-core editorconfig-core-handle
editorconfig-fnmatch ob-restclient restclient ox-jira org-re-reveal
ox-odt rng-loc rng-uri rng-parse rng-match rng-dt rng-util rng-pttrn
nxml-parse nxml-ns nxml-enc xmltok nxml-util ox-latex ox-icalendar
ox-html table ox-ascii ox-publish ox org-clock org-mu4e ob-async
bookmark my-python yasnippet highlight-indentation flymake-proc flymake
company-capf company help-fns radix-tree elpy elpy-rpc pyvenv eshell
elpy-shell elpy-profile elpy-django elpy-refactor cus-edit pp python
tramp-sh tramp tramp-loaddefs trampver tramp-integration files-x
tramp-compat shell ls-lisp my-elisp my-flycheck flycheck-irony
irony-diagnostics irony irony-iotask flycheck-checkpatch
flycheck-package package-lint finder lisp-mnt rustic-flycheck let-alist
flycheck my-text my-devel paren elec-pair meson-mode smie yaml-mode
asm-mode fish-completion em-cmpl esh-mode esh-cmd esh-ext esh-opt
esh-proc esh-io esh-arg esh-module esh-groups esh-util fish-mode gxref
my-c-mode rustic-lsp rustic-playpen rustic-rustfix rustic-racer etags
fileloop f s rustic-babel rustic-rustfmt org-element avl-tree generator
rustic-popup rustic-cargo rustic-compile spinner xterm-color
markdown-mode rustic-interaction rustic editorconfig-custom-majormode
editorconfig my-gnus gnus-agent gnus-srvr gnus-score score-mode
nnvirtual gnus-msg nntp gnus-cache my-git git-timemachine vc-git
vc-dispatcher libgit libegit2 my-find wgrep-helm wgrep grep my-helm
helm-themes helm helm-global-bindings helm-easymenu helm-source
helm-multi-match helm-lib helm-config my-email mu4e-patch diff-mode
mu4e-view-gnus gnus-art mm-uu mml2015 mm-view mml-smime smime dig
gnus-sum gnus-group gnus-undo gnus-start gnus-dbus dbus gnus-cloud
nnimap nnmail mail-source utf7 netrc nnoo parse-time iso8601 gnus-spec
gnus-int gnus-range gnus-win gnus nnheader wid-edit mu4e-view-common
mu4e-headers mu4e-compose mu4e-context mu4e-draft mu4e-actions ido
rfc2368 smtpmail sendmail mu4e-mark mu4e-proc mule-util hl-line
mu4e-utils doc-view jka-compr image-mode exif mu4e-lists mu4e-message
shr kinsoku svg xml dom flow-fill mu4e-vars mu4e-meta org ob ob-tangle
ob-ref ob-lob ob-table ob-exp org-macro org-footnote org-src ob-comint
org-pcomplete pcomplete org-list org-faces org-entities org-version
ob-emacs-lisp ob-core ob-eval org-table ol org-keys org-compat org-macs
org-loaddefs find-func cal-menu calendar cal-loaddefs piem transient
format-spec piem-maildir message rmc puny rfc822 mml mml-sec epa epg
epg-config gnus-util rmail rmail-loaddefs time-date mm-decode mm-bodies
mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums
mail-prsvr mailabbrev mail-utils gmm-utils mailheader mail-extr
my-editing my-hydra my-compat my-edit-server jira-markup-mode noutline
outline my-atomic-chrome my-web my-modeline which-func imenu time
my-tracking tracking shorten my-display solarized-theme solarized
solarized-faces zenburn-theme gruvbox-theme gruvbox autothemer
unicode-fonts midnight cus-load my-basic-modes counsel xdg advice xref
project dired dired-loaddefs compile text-property-search comint
ansi-color swiper ivy-hydra hydra lv ivy derived flx delsel ring
ivy-faces ivy-overlay colir color autorevert filenotify savehist my-libs
diminish fn dash my-keybinds my-config my-package comp comp-cstr
warnings async-bytecomp async cl-extra help-mode use-package
use-package-ensure use-package-delight use-package-diminish
use-package-bind-key bind-key use-package-core finder-inf my-vars
my-utils edmacro kmacro thingatpt my-paths tab-line pcase easy-mmode rx
cl info package browse-url url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-domsuf url-util mailcap
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json subr-x map url-vars seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib iso-transl tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win
x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo x-toolkit
x multi-tty make-network-process native-compile emacs)
Memory information:
((conses 16 2264685 324553)
(symbols 48 76602 5)
(strings 32 567863 37846)
(string-bytes 1 17479332)
(vectors 16 115263)
(vector-slots 8 3305880 147141)
(floats 8 1390 1507)
(intervals 56 74173 10047)
(buffers 992 80))
--
Alex Bennée
--
Alex Bennée
KVM/QEMU Hacker for Linaro
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#48337; Package emacs.
(Mon, 10 May 2021 19:36:02 GMT) Full text and rfc822 format available.Message #8 received at 48337 <at> debbugs.gnu.org (full text, mbox):
From: Alex Bennée <alex.bennee <at> linaro.org> To: 48337 <at> debbugs.gnu.org Date: Mon, 10 May 2021 20:34:49 +0100
[Message part 1 (text/plain, inline)]
I now have an updated core dump from a debug build. I seem to be able to trigger the crash from magit doing - (l)og (o)ther and then selecting a remote branch in the mini-buffer. It seems doom-modeline may be triggering it somehow. -- Alex Bennée KVM/QEMU Hacker for Linaro
[Message part 2 (text/html, inline)]
[crash-with-debug.txt (text/plain, attachment)]
bug-gnu-emacs <at> gnu.org:bug#48337; Package emacs.
(Tue, 11 May 2021 02:25:02 GMT) Full text and rfc822 format available.Message #11 received at 48337 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Alex Bennée <alex.bennee <at> linaro.org> Cc: acm <at> muc.de, 48337 <at> debbugs.gnu.org Subject: Re: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Tue, 11 May 2021 05:24:28 +0300
> From: Alex Bennée <alex.bennee <at> linaro.org>
> Date: Mon, 10 May 2021 20:30:58 +0100
> Cc: Alan Mackenzie <acm <at> muc.de>
>
> It seems my mail client left this in the sent folder but never actually sent it:
>
> I haven't been able to find a reproduction as the bug hits fairly
> randomly hence I'm running in my normal init.el heavy environment.
> That said there shouldn't be anything in lisp that could cause a
> segfault in the core C code.
>
> This only started happening this week after a recent update from
> master (I update every Monday). The only change I could see that might
> be related was f608b4b93 (Prevent the selected window being a dead
> mini-window when switching frames).
>
> Unfortunately no symbols. However both core dumps so far have seen the
> same null XCAR being called from nth_minibuffer:
>
> #0 0x00007f4384f585cb in raise (sig=sig <at> entry=11) at ../sysdeps/unix/sysv/linux/raise.c:50
> set = {__val = {18446744067266837247, 0 <repeats 15 times>}}
> pid = <optimized out>
> tid = <optimized out>
> #1 0x000055b6738bf530 in terminate_due_to_signal (sig=sig <at> entry=11,
> backtrace_limit=backtrace_limit <at> entry=40) at emacs.c:437
> #2 0x000055b6738bf97d in handle_fatal_signal (sig=sig <at> entry=11) at sysdep.c:1762
> #3 0x000055b6739b8ca8 in deliver_thread_signal (sig=sig <at> entry=11, handler=0x55b6738bf972
> <handle_fatal_signal>) at sysdep.c:1754
> #4 0x000055b6739b8d29 in deliver_fatal_thread_signal (sig=11) at sysdep.c:1867
> fatal = <optimized out>
> #5 0x000055b6739b8d29 in handle_sigsegv (sig=11, siginfo=<optimized out>, arg=<optimized out>) at
> sysdep.c:1867
> fatal = <optimized out>
> #6 0x00007f4384f58730 in <signal handler called> () at /lib/x86_64-linux-gnu/libpthread.so.0
> #7 0x000055b6739ce0ef in XCAR (c=0x0) at lisp.h:1420
> tail = 0x0
> frames = <optimized out>
> frame = <optimized out>
> f = <optimized out>
> innermost_MB = <optimized out>
> #8 0x000055b6739ce0ef in nth_minibuffer (depth=<optimized out>) at minibuf.c:972
> tail = 0x0
> frames = <optimized out>
> frame = <optimized out>
> f = <optimized out>
> innermost_MB = <optimized out>
Please show the Lisp value of Vminibuffer_list.
bug-gnu-emacs <at> gnu.org:bug#48337; Package emacs.
(Tue, 11 May 2021 06:52:02 GMT) Full text and rfc822 format available.Message #14 received at 48337 <at> debbugs.gnu.org (full text, mbox):
From: Alex Bennée <alex.bennee <at> linaro.org> To: Eli Zaretskii <eliz <at> gnu.org> Cc: Alan Mackenzie <acm <at> muc.de>, 48337 <at> debbugs.gnu.org Subject: Re: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Tue, 11 May 2021 07:51:20 +0100
[Message part 1 (text/plain, inline)]
I can now recreate at will with a magit sequence (l o hackbox/ TAB) which
triggers a minibuffer re-size to accommodate the list of git branches:
(gdb) info frame 0
Stack frame at 0x7fffffffb2e0:
rip = 0x5555556a80ef in Factive_minibuffer_window (minibuf.c:230); saved
rip = 0x5555556f52ab
called by frame at 0x7fffffffb340
source language c.
Arglist at 0x7fffffffb2c8, args:
Locals at 0x7fffffffb2c8, Previous frame's sp is 0x7fffffffb2e0
Saved registers:
rip at 0x7fffffffb2d8
(gdb) x/5i $pc
=> 0x5555556a80ef <Factive_minibuffer_window+79>: mov
-0x3(%rax),%r10
0x5555556a80f3 <Factive_minibuffer_window+83>: lea
-0x3(%rdx),%eax
0x5555556a80f6 <Factive_minibuffer_window+86>: test $0x7,%al
0x5555556a80f8 <Factive_minibuffer_window+88>: jne
0x5555556a8153 <Factive_minibuffer_window+179>
0x5555556a80fa <Factive_minibuffer_window+90>: nopw
0x0(%rax,%rax,1)
(gdb) p/x $rax
$4 = 0x0
(gdb) p/x $r10
$5 = 0x7fffeece9c6d
(gdb) l
225 Lisp_Object innermost_MB;
226
227 if (!minibuf_level)
228 return Qnil;
229
230 innermost_MB = nth_minibuffer (minibuf_level);
231 FOR_EACH_FRAME (frames, frame)
232 {
233 f = XFRAME (frame);
234 if (FRAME_LIVE_P (f)
(gdb) p minibuf_level
$6 = 2
(gdb) p Vminibuffer_list
$7 = (Lisp_Object) 0x555555c9aca3
(gdb) p $*
A syntax error in expression, near `'.
(gdb) p *$
$8 = <incomplete type>
(gdb)
Let me know if you want something else.
On Tue, 11 May 2021 at 03:24, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Alex Bennée <alex.bennee <at> linaro.org>
> > Date: Mon, 10 May 2021 20:30:58 +0100
> > Cc: Alan Mackenzie <acm <at> muc.de>
> >
> > It seems my mail client left this in the sent folder but never actually
> sent it:
> >
> > I haven't been able to find a reproduction as the bug hits fairly
> > randomly hence I'm running in my normal init.el heavy environment.
> > That said there shouldn't be anything in lisp that could cause a
> > segfault in the core C code.
> >
> > This only started happening this week after a recent update from
> > master (I update every Monday). The only change I could see that might
> > be related was f608b4b93 (Prevent the selected window being a dead
> > mini-window when switching frames).
> >
> > Unfortunately no symbols. However both core dumps so far have seen the
> > same null XCAR being called from nth_minibuffer:
> >
> > #0 0x00007f4384f585cb in raise (sig=sig <at> entry=11) at
> ../sysdeps/unix/sysv/linux/raise.c:50
> > set = {__val = {18446744067266837247, 0 <repeats 15 times>}}
> > pid = <optimized out>
> > tid = <optimized out>
> > #1 0x000055b6738bf530 in terminate_due_to_signal (sig=sig <at> entry=11,
> > backtrace_limit=backtrace_limit <at> entry=40) at emacs.c:437
> > #2 0x000055b6738bf97d in handle_fatal_signal (sig=sig <at> entry=11) at
> sysdep.c:1762
> > #3 0x000055b6739b8ca8 in deliver_thread_signal (sig=sig <at> entry=11,
> handler=0x55b6738bf972
> > <handle_fatal_signal>) at sysdep.c:1754
> > #4 0x000055b6739b8d29 in deliver_fatal_thread_signal (sig=11) at
> sysdep.c:1867
> > fatal = <optimized out>
> > #5 0x000055b6739b8d29 in handle_sigsegv (sig=11, siginfo=<optimized
> out>, arg=<optimized out>) at
> > sysdep.c:1867
> > fatal = <optimized out>
> > #6 0x00007f4384f58730 in <signal handler called> () at
> /lib/x86_64-linux-gnu/libpthread.so.0
> > #7 0x000055b6739ce0ef in XCAR (c=0x0) at lisp.h:1420
> > tail = 0x0
> > frames = <optimized out>
> > frame = <optimized out>
> > f = <optimized out>
> > innermost_MB = <optimized out>
> > #8 0x000055b6739ce0ef in nth_minibuffer (depth=<optimized out>) at
> minibuf.c:972
> > tail = 0x0
> > frames = <optimized out>
> > frame = <optimized out>
> > f = <optimized out>
> > innermost_MB = <optimized out>
>
> Please show the Lisp value of Vminibuffer_list.
>
--
Alex Bennée
KVM/QEMU Hacker for Linaro
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#48337; Package emacs.
(Tue, 11 May 2021 08:24:02 GMT) Full text and rfc822 format available.Message #17 received at 48337 <at> debbugs.gnu.org (full text, mbox):
From: Alex Bennée <alex.bennee <at> linaro.org> To: Eli Zaretskii <eliz <at> gnu.org> Cc: Alan Mackenzie <acm <at> muc.de>, 48337 <at> debbugs.gnu.org Subject: Re: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Tue, 11 May 2021 09:23:24 +0100
[Message part 1 (text/plain, inline)]
I tried noodling around in rr to get some more details but I'm a bit lost
with how the C code iterates through the objects. It certainly looks like
Fnthcdr just ends up with an empty value.
Log attached:
On Tue, 11 May 2021 at 07:51, Alex Bennée <alex.bennee <at> linaro.org> wrote:
> I can now recreate at will with a magit sequence (l o hackbox/ TAB) which
> triggers a minibuffer re-size to accommodate the list of git branches:
>
> (gdb) info frame 0
> Stack frame at 0x7fffffffb2e0:
> rip = 0x5555556a80ef in Factive_minibuffer_window (minibuf.c:230); saved
> rip = 0x5555556f52ab
> called by frame at 0x7fffffffb340
> source language c.
> Arglist at 0x7fffffffb2c8, args:
> Locals at 0x7fffffffb2c8, Previous frame's sp is 0x7fffffffb2e0
> Saved registers:
> rip at 0x7fffffffb2d8
> (gdb) x/5i $pc
> => 0x5555556a80ef <Factive_minibuffer_window+79>: mov
> -0x3(%rax),%r10
> 0x5555556a80f3 <Factive_minibuffer_window+83>: lea
> -0x3(%rdx),%eax
> 0x5555556a80f6 <Factive_minibuffer_window+86>: test $0x7,%al
> 0x5555556a80f8 <Factive_minibuffer_window+88>: jne
> 0x5555556a8153 <Factive_minibuffer_window+179>
> 0x5555556a80fa <Factive_minibuffer_window+90>: nopw
> 0x0(%rax,%rax,1)
> (gdb) p/x $rax
> $4 = 0x0
> (gdb) p/x $r10
> $5 = 0x7fffeece9c6d
> (gdb) l
> 225 Lisp_Object innermost_MB;
> 226
> 227 if (!minibuf_level)
> 228 return Qnil;
> 229
> 230 innermost_MB = nth_minibuffer (minibuf_level);
> 231 FOR_EACH_FRAME (frames, frame)
> 232 {
> 233 f = XFRAME (frame);
> 234 if (FRAME_LIVE_P (f)
> (gdb) p minibuf_level
> $6 = 2
> (gdb) p Vminibuffer_list
> $7 = (Lisp_Object) 0x555555c9aca3
> (gdb) p $*
> A syntax error in expression, near `'.
> (gdb) p *$
> $8 = <incomplete type>
> (gdb)
>
> Let me know if you want something else.
>
> On Tue, 11 May 2021 at 03:24, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>> > From: Alex Bennée <alex.bennee <at> linaro.org>
>> > Date: Mon, 10 May 2021 20:30:58 +0100
>> > Cc: Alan Mackenzie <acm <at> muc.de>
>> >
>> > It seems my mail client left this in the sent folder but never actually
>> sent it:
>> >
>> > I haven't been able to find a reproduction as the bug hits fairly
>> > randomly hence I'm running in my normal init.el heavy environment.
>> > That said there shouldn't be anything in lisp that could cause a
>> > segfault in the core C code.
>> >
>> > This only started happening this week after a recent update from
>> > master (I update every Monday). The only change I could see that might
>> > be related was f608b4b93 (Prevent the selected window being a dead
>> > mini-window when switching frames).
>> >
>> > Unfortunately no symbols. However both core dumps so far have seen the
>> > same null XCAR being called from nth_minibuffer:
>> >
>> > #0 0x00007f4384f585cb in raise (sig=sig <at> entry=11) at
>> ../sysdeps/unix/sysv/linux/raise.c:50
>> > set = {__val = {18446744067266837247, 0 <repeats 15 times>}}
>> > pid = <optimized out>
>> > tid = <optimized out>
>> > #1 0x000055b6738bf530 in terminate_due_to_signal (sig=sig <at> entry=11,
>> > backtrace_limit=backtrace_limit <at> entry=40) at emacs.c:437
>> > #2 0x000055b6738bf97d in handle_fatal_signal (sig=sig <at> entry=11) at
>> sysdep.c:1762
>> > #3 0x000055b6739b8ca8 in deliver_thread_signal (sig=sig <at> entry=11,
>> handler=0x55b6738bf972
>> > <handle_fatal_signal>) at sysdep.c:1754
>> > #4 0x000055b6739b8d29 in deliver_fatal_thread_signal (sig=11) at
>> sysdep.c:1867
>> > fatal = <optimized out>
>> > #5 0x000055b6739b8d29 in handle_sigsegv (sig=11, siginfo=<optimized
>> out>, arg=<optimized out>) at
>> > sysdep.c:1867
>> > fatal = <optimized out>
>> > #6 0x00007f4384f58730 in <signal handler called> () at
>> /lib/x86_64-linux-gnu/libpthread.so.0
>> > #7 0x000055b6739ce0ef in XCAR (c=0x0) at lisp.h:1420
>> > tail = 0x0
>> > frames = <optimized out>
>> > frame = <optimized out>
>> > f = <optimized out>
>> > innermost_MB = <optimized out>
>> > #8 0x000055b6739ce0ef in nth_minibuffer (depth=<optimized out>) at
>> minibuf.c:972
>> > tail = 0x0
>> > frames = <optimized out>
>> > frame = <optimized out>
>> > f = <optimized out>
>> > innermost_MB = <optimized out>
>>
>> Please show the Lisp value of Vminibuffer_list.
>>
>
>
> --
> Alex Bennée
> KVM/QEMU Hacker for Linaro
>
--
Alex Bennée
KVM/QEMU Hacker for Linaro
[Message part 2 (text/html, inline)]
[rr.txt (text/plain, attachment)]
bug-gnu-emacs <at> gnu.org:bug#48337; Package emacs.
(Tue, 11 May 2021 08:55:01 GMT) Full text and rfc822 format available.Message #20 received at 48337 <at> debbugs.gnu.org (full text, mbox):
From: Alex Bennée <alex.bennee <at> linaro.org> To: Eli Zaretskii <eliz <at> gnu.org> Cc: Alan Mackenzie <acm <at> muc.de>, 48337 <at> debbugs.gnu.org Subject: Re: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Tue, 11 May 2021 09:54:32 +0100
[Message part 1 (text/plain, inline)]
Sorry for the spamming of the logs, this time collected with debugging
information and the trace of gdb commands so you can see what's going on.
Basically the for (; 0 < num; num--, tail = XCDR (tail)) ends with a NULL
value.
On Tue, 11 May 2021 at 09:23, Alex Bennée <alex.bennee <at> linaro.org> wrote:
> I tried noodling around in rr to get some more details but I'm a bit lost
> with how the C code iterates through the objects. It certainly looks like
> Fnthcdr just ends up with an empty value.
>
> Log attached:
>
>
>
> On Tue, 11 May 2021 at 07:51, Alex Bennée <alex.bennee <at> linaro.org> wrote:
>
>> I can now recreate at will with a magit sequence (l o hackbox/ TAB) which
>> triggers a minibuffer re-size to accommodate the list of git branches:
>>
>> (gdb) info frame 0
>> Stack frame at 0x7fffffffb2e0:
>> rip = 0x5555556a80ef in Factive_minibuffer_window (minibuf.c:230); saved
>> rip = 0x5555556f52ab
>> called by frame at 0x7fffffffb340
>> source language c.
>> Arglist at 0x7fffffffb2c8, args:
>> Locals at 0x7fffffffb2c8, Previous frame's sp is 0x7fffffffb2e0
>> Saved registers:
>> rip at 0x7fffffffb2d8
>> (gdb) x/5i $pc
>> => 0x5555556a80ef <Factive_minibuffer_window+79>: mov
>> -0x3(%rax),%r10
>> 0x5555556a80f3 <Factive_minibuffer_window+83>: lea
>> -0x3(%rdx),%eax
>> 0x5555556a80f6 <Factive_minibuffer_window+86>: test $0x7,%al
>> 0x5555556a80f8 <Factive_minibuffer_window+88>: jne
>> 0x5555556a8153 <Factive_minibuffer_window+179>
>> 0x5555556a80fa <Factive_minibuffer_window+90>: nopw
>> 0x0(%rax,%rax,1)
>> (gdb) p/x $rax
>> $4 = 0x0
>> (gdb) p/x $r10
>> $5 = 0x7fffeece9c6d
>> (gdb) l
>> 225 Lisp_Object innermost_MB;
>> 226
>> 227 if (!minibuf_level)
>> 228 return Qnil;
>> 229
>> 230 innermost_MB = nth_minibuffer (minibuf_level);
>> 231 FOR_EACH_FRAME (frames, frame)
>> 232 {
>> 233 f = XFRAME (frame);
>> 234 if (FRAME_LIVE_P (f)
>> (gdb) p minibuf_level
>> $6 = 2
>> (gdb) p Vminibuffer_list
>> $7 = (Lisp_Object) 0x555555c9aca3
>> (gdb) p $*
>> A syntax error in expression, near `'.
>> (gdb) p *$
>> $8 = <incomplete type>
>> (gdb)
>>
>> Let me know if you want something else.
>>
>> On Tue, 11 May 2021 at 03:24, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>
>>> > From: Alex Bennée <alex.bennee <at> linaro.org>
>>> > Date: Mon, 10 May 2021 20:30:58 +0100
>>> > Cc: Alan Mackenzie <acm <at> muc.de>
>>> >
>>> > It seems my mail client left this in the sent folder but never
>>> actually sent it:
>>> >
>>> > I haven't been able to find a reproduction as the bug hits fairly
>>> > randomly hence I'm running in my normal init.el heavy environment.
>>> > That said there shouldn't be anything in lisp that could cause a
>>> > segfault in the core C code.
>>> >
>>> > This only started happening this week after a recent update from
>>> > master (I update every Monday). The only change I could see that
>>> might
>>> > be related was f608b4b93 (Prevent the selected window being a dead
>>> > mini-window when switching frames).
>>> >
>>> > Unfortunately no symbols. However both core dumps so far have seen
>>> the
>>> > same null XCAR being called from nth_minibuffer:
>>> >
>>> > #0 0x00007f4384f585cb in raise (sig=sig <at> entry=11) at
>>> ../sysdeps/unix/sysv/linux/raise.c:50
>>> > set = {__val = {18446744067266837247, 0 <repeats 15 times>}}
>>> > pid = <optimized out>
>>> > tid = <optimized out>
>>> > #1 0x000055b6738bf530 in terminate_due_to_signal (sig=sig <at> entry=11,
>>> > backtrace_limit=backtrace_limit <at> entry=40) at emacs.c:437
>>> > #2 0x000055b6738bf97d in handle_fatal_signal (sig=sig <at> entry=11) at
>>> sysdep.c:1762
>>> > #3 0x000055b6739b8ca8 in deliver_thread_signal (sig=sig <at> entry=11,
>>> handler=0x55b6738bf972
>>> > <handle_fatal_signal>) at sysdep.c:1754
>>> > #4 0x000055b6739b8d29 in deliver_fatal_thread_signal (sig=11) at
>>> sysdep.c:1867
>>> > fatal = <optimized out>
>>> > #5 0x000055b6739b8d29 in handle_sigsegv (sig=11, siginfo=<optimized
>>> out>, arg=<optimized out>) at
>>> > sysdep.c:1867
>>> > fatal = <optimized out>
>>> > #6 0x00007f4384f58730 in <signal handler called> () at
>>> /lib/x86_64-linux-gnu/libpthread.so.0
>>> > #7 0x000055b6739ce0ef in XCAR (c=0x0) at lisp.h:1420
>>> > tail = 0x0
>>> > frames = <optimized out>
>>> > frame = <optimized out>
>>> > f = <optimized out>
>>> > innermost_MB = <optimized out>
>>> > #8 0x000055b6739ce0ef in nth_minibuffer (depth=<optimized out>) at
>>> minibuf.c:972
>>> > tail = 0x0
>>> > frames = <optimized out>
>>> > frame = <optimized out>
>>> > f = <optimized out>
>>> > innermost_MB = <optimized out>
>>>
>>> Please show the Lisp value of Vminibuffer_list.
>>>
>>
>>
>> --
>> Alex Bennée
>> KVM/QEMU Hacker for Linaro
>>
>
>
> --
> Alex Bennée
> KVM/QEMU Hacker for Linaro
>
--
Alex Bennée
KVM/QEMU Hacker for Linaro
[Message part 2 (text/html, inline)]
[rr2.txt (text/plain, attachment)]
bug-gnu-emacs <at> gnu.org:bug#48337; Package emacs.
(Tue, 11 May 2021 12:22:02 GMT) Full text and rfc822 format available.Message #23 received at 48337 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Alex Bennée <alex.bennee <at> linaro.org> Cc: acm <at> muc.de, 48337 <at> debbugs.gnu.org Subject: Re: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Tue, 11 May 2021 15:21:50 +0300
> From: Alex Bennée <alex.bennee <at> linaro.org>
> Date: Tue, 11 May 2021 07:51:20 +0100
> Cc: 48337 <at> debbugs.gnu.org, Alan Mackenzie <acm <at> muc.de>
>
> I can now recreate at will with a magit sequence (l o hackbox/ TAB) which triggers a minibuffer re-size to
> accommodate the list of git branches:
>
> (gdb) info frame 0
> Stack frame at 0x7fffffffb2e0:
> rip = 0x5555556a80ef in Factive_minibuffer_window (minibuf.c:230); saved rip = 0x5555556f52ab
> called by frame at 0x7fffffffb340
> source language c.
> Arglist at 0x7fffffffb2c8, args:
> Locals at 0x7fffffffb2c8, Previous frame's sp is 0x7fffffffb2e0
> Saved registers:
> rip at 0x7fffffffb2d8
> (gdb) x/5i $pc
> => 0x5555556a80ef <Factive_minibuffer_window+79>: mov -0x3(%rax),%r10
> 0x5555556a80f3 <Factive_minibuffer_window+83>: lea -0x3(%rdx),%eax
> 0x5555556a80f6 <Factive_minibuffer_window+86>: test $0x7,%al
> 0x5555556a80f8 <Factive_minibuffer_window+88>: jne 0x5555556a8153
> <Factive_minibuffer_window+179>
> 0x5555556a80fa <Factive_minibuffer_window+90>: nopw 0x0(%rax,%rax,1)
> (gdb) p/x $rax
> $4 = 0x0
> (gdb) p/x $r10
> $5 = 0x7fffeece9c6d
> (gdb) l
> 225 Lisp_Object innermost_MB;
> 226
> 227 if (!minibuf_level)
> 228 return Qnil;
> 229
> 230 innermost_MB = nth_minibuffer (minibuf_level);
> 231 FOR_EACH_FRAME (frames, frame)
> 232 {
> 233 f = XFRAME (frame);
> 234 if (FRAME_LIVE_P (f)
> (gdb) p minibuf_level
> $6 = 2
> (gdb) p Vminibuffer_list
> $7 = (Lisp_Object) 0x555555c9aca3
> (gdb) p $*
> A syntax error in expression, near `'.
> (gdb) p *$
> $8 = <incomplete type>
> (gdb)
>
> Let me know if you want something else.
I want this:
(gdb) pp Vminibuffer_list
If GDB says it doesn't know "pp", you need to source the .gdbinit file
in the Emacs's src directory.
Thanks.
bug-gnu-emacs <at> gnu.org:bug#48337; Package emacs.
(Tue, 11 May 2021 12:55:02 GMT) Full text and rfc822 format available.Message #26 received at 48337 <at> debbugs.gnu.org (full text, mbox):
From: Alex Bennée <alex.bennee <at> linaro.org> To: Eli Zaretskii <eliz <at> gnu.org> Cc: Alan Mackenzie <acm <at> muc.de>, 48337 <at> debbugs.gnu.org Subject: Re: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Tue, 11 May 2021 13:54:02 +0100
[Message part 1 (text/plain, inline)]
(gdb) pp Vminibuffer_list
(#<buffer *Minibuf-0*> #<buffer *Minibuf-1*>)
On Tue, 11 May 2021 at 13:21, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Alex Bennée <alex.bennee <at> linaro.org>
> > Date: Tue, 11 May 2021 07:51:20 +0100
> > Cc: 48337 <at> debbugs.gnu.org, Alan Mackenzie <acm <at> muc.de>
> >
> > I can now recreate at will with a magit sequence (l o hackbox/ TAB)
> which triggers a minibuffer re-size to
> > accommodate the list of git branches:
> >
> > (gdb) info frame 0
> > Stack frame at 0x7fffffffb2e0:
> > rip = 0x5555556a80ef in Factive_minibuffer_window (minibuf.c:230);
> saved rip = 0x5555556f52ab
> > called by frame at 0x7fffffffb340
> > source language c.
> > Arglist at 0x7fffffffb2c8, args:
> > Locals at 0x7fffffffb2c8, Previous frame's sp is 0x7fffffffb2e0
> > Saved registers:
> > rip at 0x7fffffffb2d8
> > (gdb) x/5i $pc
> > => 0x5555556a80ef <Factive_minibuffer_window+79>: mov
> -0x3(%rax),%r10
> > 0x5555556a80f3 <Factive_minibuffer_window+83>: lea
> -0x3(%rdx),%eax
> > 0x5555556a80f6 <Factive_minibuffer_window+86>: test $0x7,%al
> > 0x5555556a80f8 <Factive_minibuffer_window+88>: jne
> 0x5555556a8153
> > <Factive_minibuffer_window+179>
> > 0x5555556a80fa <Factive_minibuffer_window+90>: nopw
> 0x0(%rax,%rax,1)
> > (gdb) p/x $rax
> > $4 = 0x0
> > (gdb) p/x $r10
> > $5 = 0x7fffeece9c6d
> > (gdb) l
> > 225 Lisp_Object innermost_MB;
> > 226
> > 227 if (!minibuf_level)
> > 228 return Qnil;
> > 229
> > 230 innermost_MB = nth_minibuffer (minibuf_level);
> > 231 FOR_EACH_FRAME (frames, frame)
> > 232 {
> > 233 f = XFRAME (frame);
> > 234 if (FRAME_LIVE_P (f)
> > (gdb) p minibuf_level
> > $6 = 2
> > (gdb) p Vminibuffer_list
> > $7 = (Lisp_Object) 0x555555c9aca3
> > (gdb) p $*
> > A syntax error in expression, near `'.
> > (gdb) p *$
> > $8 = <incomplete type>
> > (gdb)
> >
> > Let me know if you want something else.
>
> I want this:
>
> (gdb) pp Vminibuffer_list
>
> If GDB says it doesn't know "pp", you need to source the .gdbinit file
> in the Emacs's src directory.
>
> Thanks.
>
--
Alex Bennée
KVM/QEMU Hacker for Linaro
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#48337; Package emacs.
(Tue, 11 May 2021 13:43:01 GMT) Full text and rfc822 format available.Message #29 received at 48337 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Alex Bennée <alex.bennee <at> linaro.org> Cc: acm <at> muc.de, 48337 <at> debbugs.gnu.org Subject: Re: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Tue, 11 May 2021 16:42:26 +0300
> From: Alex Bennée <alex.bennee <at> linaro.org> > Date: Tue, 11 May 2021 13:54:02 +0100 > Cc: 48337 <at> debbugs.gnu.org, Alan Mackenzie <acm <at> muc.de> > > (gdb) pp Vminibuffer_list > (#<buffer *Minibuf-0*> #<buffer *Minibuf-1*>) Thanks. Alan, the code in nth_minibuffer and its callers is unsafe. First, Fnthcdr can return nil, and then XCAR of that in nth_minibuffer crashes. I fixed that now on the master branch, but there're more problems: some the callers of nth_minibuffer don't seem to be protected from it returning nil. For example, we have this in read_minibuf_unwind: Fset_buffer (nth_minibuffer (minibuf_level)); and this in minibuffer_unwind: set_window_buffer (window, nth_minibuffer (0), 0, 0); In other cases you compare windows with nil, which can never be true, so a preliminary test for nil would be nice to avoid a loop that can never find anything useful. Please make this code more robust. Thanks.
bug-gnu-emacs <at> gnu.org:bug#48337; Package emacs.
(Tue, 11 May 2021 13:48:02 GMT) Full text and rfc822 format available.Message #32 received at 48337 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: acm <at> muc.de Cc: 48337 <at> debbugs.gnu.org, alex.bennee <at> linaro.org Subject: Re: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Tue, 11 May 2021 16:47:42 +0300
> Date: Tue, 11 May 2021 16:42:26 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: acm <at> muc.de, 48337 <at> debbugs.gnu.org
>
> In other cases you compare windows with nil, which can never be true,
^^^^^^^^^^^^^^^^^^^^^^^^
Sorry, I meant to say "compare windows' buffers with nil" instead.
bug-gnu-emacs <at> gnu.org:bug#48337; Package emacs.
(Tue, 11 May 2021 19:46:02 GMT) Full text and rfc822 format available.Message #35 received at 48337 <at> debbugs.gnu.org (full text, mbox):
From: Alan Mackenzie <acm <at> muc.de> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 48337 <at> debbugs.gnu.org, Alex Bennée <alex.bennee <at> linaro.org> Subject: Re: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Tue, 11 May 2021 19:45:23 +0000
Hello, Eli. On Tue, May 11, 2021 at 16:42:26 +0300, Eli Zaretskii wrote: > > From: Alex Bennée <alex.bennee <at> linaro.org> > > Date: Tue, 11 May 2021 13:54:02 +0100 > > Cc: 48337 <at> debbugs.gnu.org, Alan Mackenzie <acm <at> muc.de> > > (gdb) pp Vminibuffer_list > > (#<buffer *Minibuf-0*> #<buffer *Minibuf-1*>) > Thanks. > Alan, the code in nth_minibuffer and its callers is unsafe. First, > Fnthcdr can return nil, and then XCAR of that in nth_minibuffer > crashes. I fixed that now on the master branch, .... That Fnthcdr call "can't possibly" return nil, unless there's a bug somewhere. Clearly there's a bug somewhere, and the fact it triggered an abort is a good thing, since it should enable us to find that bug more easily. nth_minibuffer is called only with argument DEPTH set to 0 or minibuf_level. minibuf_level is initialised to 0 and thereafter only altered at exactly 2 places, a minibuf_level++ when entering a new MB, and minibuf_level-- when exiting it. Vminibuffer_list, the list of minibuffers, is extended by one element when a new minibuffer level is entered for the first time. This is done by function get_minibuffer. Once *Minibuf-2* has been created, it is reused every time a recursive MB call at that level happens, and it is never garbage collected. My hypothesis at the moment is that minibuf_level++ has happened (setting its value to 2), but get_minibuffer(2) hasn't happened yet, so VMinibuffer_list is only 2 elements long, ( *Minibuf-0* *Minibuf-1*). Something is trying to call nth_minibuffer (minibuf_level) in that inconsistent state. There is a window of ~115 lines of code in read_minibuf where that could happen. However, Alex's dump doesn't say what the current positionn in read_minibuf is. Instead it says "lisp.h:1008", which is unhelpful in the extreme. Why does GDB have to be so "clever"? Is there any way to stop GDB doing this and make it report the actual position in the prime source code as well as the position in some inline function? I'm going to write to Alex asking him to provide more details - his posts are lacking a lisp backtrace, a recipe, and so much needed information is <optimized out>. Why does GDB fail to display this information? Surely it should know what processor registers the arguments and local variables are stored in, and where in the stack frame they have been pushed? > .... but there're more problems: some the callers of nth_minibuffer > don't seem to be protected from it returning nil. For example, we > have this in read_minibuf_unwind: > Fset_buffer (nth_minibuffer (minibuf_level)); This, I think, can be justified - if read_minibuf_unwind can't find the minibuffer it's unwinding, we've got a serious problem and ought to abort Emacs ASAP. Should that, perhaps, be an explicit assert? > and this in minibuffer_unwind: > set_window_buffer (window, nth_minibuffer (0), 0, 0); This is similar: If we're unwinding a minibuffer call, *Minibuf-0* is "bound" to exist. Perhaps there should be an explicit assert here, too? > In other cases you compare windows' buffers [EZ's textual correction > incorporated] with nil, which can never be true, so a preliminary test > for nil would be nice to avoid a loop that can never find anything > useful. > Please make this code more robust. OK. I will do this. > Thanks. -- Alan Mackenzie (Nuremberg, Germany).
bug-gnu-emacs <at> gnu.org:bug#48337; Package emacs.
(Tue, 11 May 2021 19:56:02 GMT) Full text and rfc822 format available.Message #38 received at 48337 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Alan Mackenzie <acm <at> muc.de> Cc: 48337 <at> debbugs.gnu.org, alex.bennee <at> linaro.org Subject: Re: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Tue, 11 May 2021 22:55:55 +0300
> Date: Tue, 11 May 2021 19:45:23 +0000 > Cc: Alex Bennée <alex.bennee <at> linaro.org>, > 48337 <at> debbugs.gnu.org > From: Alan Mackenzie <acm <at> muc.de> > > > Alan, the code in nth_minibuffer and its callers is unsafe. First, > > Fnthcdr can return nil, and then XCAR of that in nth_minibuffer > > crashes. I fixed that now on the master branch, .... > > That Fnthcdr call "can't possibly" return nil, unless there's a bug > somewhere. Then the commentary of nth_minibuffer is outdated and should be updated: it claims that returning nil is part of the contract. > > Fset_buffer (nth_minibuffer (minibuf_level)); > > This, I think, can be justified - if read_minibuf_unwind can't find the > minibuffer it's unwinding, we've got a serious problem and ought to > abort Emacs ASAP. Should that, perhaps, be an explicit assert? If you want to abort, assertions is not TRT, as it will not be compiled in an optimized build. Call emacs_abort instead.
bug-gnu-emacs <at> gnu.org:bug#48337; Package emacs.
(Tue, 11 May 2021 20:15:02 GMT) Full text and rfc822 format available.Message #41 received at 48337 <at> debbugs.gnu.org (full text, mbox):
From: Alan Mackenzie <acm <at> muc.de> To: Alex Bennée <alex.bennee <at> linaro.org> Cc: Eli Zaretskii <eliz <at> gnu.org>, 48337 <at> debbugs.gnu.org Subject: Re: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Tue, 11 May 2021 20:14:47 +0000
Hello, Alex.
On Tue, May 11, 2021 at 07:51:20 +0100, Alex Bennée wrote:
> I can now recreate at will with a magit sequence (l o hackbox/ TAB) which
> triggers a minibuffer re-size to accommodate the list of git branches:
Could you possibly give us a precise recipe to reproduce this bug, and a
GDB backtrace with Emacs compiled with CFLAGS='-O0 g3' (or similar)? So
much of the needed information in your large dump post has been
optimised away by the compiler. Would you please also make sure that
the Lisp backtrace is at the end of the GDB backtrace. I think this
should happen automatically if you have an Emacs .gdbinit in the
directory where you start GDB from.
That Factive_minibuffer_window is throwing an error is mainly because it
is being invalidly called. In particular, the variable minibuf_level
appears to be invalid, as compared with the internal list of
minibuffers.
Would you please also test my theory of the last paragraph, by applying
the following patch (which reverses Eli's recent patch) and seeing if
the bug still happens. Thanks!
diff --git a/src/minibuf.c b/src/minibuf.c
index 52d1275451..3afba0db68 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -653,6 +653,7 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
}
minibuf_level++; /* Before calling choose_minibuf_frame. */
+ minibuffer = get_minibuffer (minibuf_level); /* Temporary fix, 2021-05-11. */
/* Choose the minibuffer window and frame, and take action on them. */
@@ -766,7 +767,8 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
/* Switch to the minibuffer. */
- minibuffer = get_minibuffer (minibuf_level);
+ /* minibuffer = get_minibuffer (minibuf_level); Temporarily moved,
+ 2021-05-11. */
set_minibuffer_mode (minibuffer, minibuf_level);
Fset_buffer (minibuffer);
@@ -969,8 +971,8 @@ is_minibuffer (EMACS_INT depth, Lisp_Object buf)
nth_minibuffer (EMACS_INT depth)
{
Lisp_Object tail = Fnthcdr (make_fixnum (depth), Vminibuffer_list);
- if (NILP (tail))
- return Qnil;
+ /* if (NILP (tail)) Temporarily commented out, 2021-05-11
+ return Qnil; */
return XCAR (tail);
}
[ .... ]
> Let me know if you want something else.
See above. ;-)
[ .... ]
> On Tue, 11 May 2021 at 03:24, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > Please show the Lisp value of Vminibuffer_list.
I have seen the answer to this request. Thanks!
> --
> Alex Bennée
> KVM/QEMU Hacker for Linaro
--
Alan Mackenzie (Nuremberg, Germany).
bug-gnu-emacs <at> gnu.org:bug#48337; Package emacs.
(Tue, 11 May 2021 22:10:01 GMT) Full text and rfc822 format available.Message #44 received at 48337 <at> debbugs.gnu.org (full text, mbox):
From: Alex Bennée <alex.bennee <at> linaro.org> To: Alan Mackenzie <acm <at> muc.de> Cc: Eli Zaretskii <eliz <at> gnu.org>, 48337 <at> debbugs.gnu.org Subject: Re: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Tue, 11 May 2021 23:07:01 +0100
Alan Mackenzie <acm <at> muc.de> writes:
> Hello, Alex.
>
> On Tue, May 11, 2021 at 07:51:20 +0100, Alex Bennée wrote:
>> I can now recreate at will with a magit sequence (l o hackbox/ TAB) which
>> triggers a minibuffer re-size to accommodate the list of git branches:
>
> Could you possibly give us a precise recipe to reproduce this bug, and a
> GDB backtrace with Emacs compiled with CFLAGS='-O0 g3' (or similar)? So
> much of the needed information in your large dump post has been
> optimised away by the compiler. Would you please also make sure that
> the Lisp backtrace is at the end of the GDB backtrace. I think this
> should happen automatically if you have an Emacs .gdbinit in the
> directory where you start GDB from.
The later rr dumps have more symbols but didn't have the benefit of the
Emacs' .gdbinit Lips backtrace. However I'm fairly confident it's being
triggered by doom-modeline:
(doom-modeline-def-segment window-number
(let ((num (cond
((bound-and-true-p ace-window-display-mode)
(aw-update)
(window-parameter (selected-window) 'ace-window-path))
((bound-and-true-p winum-mode)
(setq winum-auto-setup-mode-line nil)
(winum-get-number-string))
((bound-and-true-p window-numbering-mode)
(window-numbering-get-number-string))
(t ""))))
(if (and (< 0 (length num))
(< (if (active-minibuffer-window) 2 1) ; exclude minibuffer
(length (cl-mapcan
(lambda (frame)
;; Exclude child frames
(unless (and (fboundp 'frame-parent)
(frame-parent frame))
(window-list)))
(visible-frame-list)))))
(propertize (format " %s " num)
'face (if (doom-modeline--active)
'doom-modeline-buffer-major-mode
'mode-line-inactive)))))
I'll try and get a better capture of it in action next time I restart my Emacs.
>
> That Factive_minibuffer_window is throwing an error is mainly because it
> is being invalidly called. In particular, the variable minibuf_level
> appears to be invalid, as compared with the internal list of
> minibuffers.
>
> Would you please also test my theory of the last paragraph, by applying
> the following patch (which reverses Eli's recent patch) and seeing if
> the bug still happens. Thanks!
>
>
>
> diff --git a/src/minibuf.c b/src/minibuf.c
> index 52d1275451..3afba0db68 100644
> --- a/src/minibuf.c
> +++ b/src/minibuf.c
> @@ -653,6 +653,7 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
> }
>
> minibuf_level++; /* Before calling choose_minibuf_frame. */
> + minibuffer = get_minibuffer (minibuf_level); /* Temporary fix, 2021-05-11. */
>
> /* Choose the minibuffer window and frame, and take action on them. */
>
> @@ -766,7 +767,8 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
>
> /* Switch to the minibuffer. */
>
> - minibuffer = get_minibuffer (minibuf_level);
> + /* minibuffer = get_minibuffer (minibuf_level); Temporarily moved,
> + 2021-05-11. */
> set_minibuffer_mode (minibuffer, minibuf_level);
> Fset_buffer (minibuffer);
>
> @@ -969,8 +971,8 @@ is_minibuffer (EMACS_INT depth, Lisp_Object buf)
> nth_minibuffer (EMACS_INT depth)
> {
> Lisp_Object tail = Fnthcdr (make_fixnum (depth), Vminibuffer_list);
> - if (NILP (tail))
> - return Qnil;
> + /* if (NILP (tail)) Temporarily commented out, 2021-05-11
> + return Qnil; */
> return XCAR (tail);
> }
>
>
> [ .... ]
>
>> Let me know if you want something else.
>
> See above. ;-)
>
> [ .... ]
>
>> On Tue, 11 May 2021 at 03:24, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>> > Please show the Lisp value of Vminibuffer_list.
>
> I have seen the answer to this request. Thanks!
>
>> --
>> Alex Bennée
>> KVM/QEMU Hacker for Linaro
--
Alex Bennée
bug-gnu-emacs <at> gnu.org:bug#48337; Package emacs.
(Wed, 12 May 2021 18:55:01 GMT) Full text and rfc822 format available.Message #47 received at 48337 <at> debbugs.gnu.org (full text, mbox):
From: Alan Mackenzie <acm <at> muc.de> To: Eli Zaretskii <eliz <at> gnu.org> Cc: martin rudalics <rudalics <at> gmx.at>, 48337 <at> debbugs.gnu.org, alex.bennee <at> linaro.org, acm <at> muc.de Subject: Re: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Wed, 12 May 2021 18:54:05 +0000
Hello, Eli. On Tue, May 11, 2021 at 22:55:55 +0300, Eli Zaretskii wrote: > > Date: Tue, 11 May 2021 19:45:23 +0000 > > Cc: Alex Bennée <alex.bennee <at> linaro.org>, > > 48337 <at> debbugs.gnu.org > > From: Alan Mackenzie <acm <at> muc.de> > > > Alan, the code in nth_minibuffer and its callers is unsafe. First, > > > Fnthcdr can return nil, and then XCAR of that in nth_minibuffer > > > crashes. I fixed that now on the master branch, .... > > That Fnthcdr call "can't possibly" return nil, unless there's a bug > > somewhere. > Then the commentary of nth_minibuffer is outdated and should be > updated: it claims that returning nil is part of the contract. I will clean up this unclean coding. > > > Fset_buffer (nth_minibuffer (minibuf_level)); > > This, I think, can be justified - if read_minibuf_unwind can't find > > the minibuffer it's unwinding, we've got a serious problem and ought > > to abort Emacs ASAP. Should that, perhaps, be an explicit assert? > If you want to abort, assertions is not TRT, as it will not be > compiled in an optimized build. Call emacs_abort instead. Thanks for the tip! I now understand the immediate cause of the bug completely. Partly this is due to me seeing better backtrace information from a subsequent post from Alex. This backtrace contains: #18 0x000055e3c57335da in Frun_hooks (nargs=1, args=0x7ffe48045368) at eval.c:2701 ...... ...... #26 0x000055e3c56a82b0 in read_minibuf (map=..., initial=..., prompt=..., expflag=false, histvar=..., histpos=..., defalt=..., allow_props=false, inherit_input_method=false) at minibuf.c:683 .. The minibuf.c:683 identifies the failing point in read_minibuf as a call to record-window-buffer. r-w-b ends by calling the hook buffer-list-update-hook. At the time of calling record-window-buffer, minibuf_level has been incremented to 2, but *Minibuf-2* has not yet been created and added to minibuf.c's internal list of minibuffers. This is an inconsistent state. Something on buffer-list-update-hook calls active-minibuffer-window, and because of the inconsistent state, this crashes. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; The deeper cause of the bug is that calling buffer-list-update-hook simply doesn't belong in record-window-buffer. That hook should be called when the buffer list changes, not when a window's current buffer gets "recorded". So, as the main fix, I propose moving the call of buffer-list-update-hook to (some of) the places where record-window-buffer gets called, those places where the buffer list changes. There are exactly two such places, both in window.c. This will prevent the chain of events in read_minibuf outlined above. Also, I intend to prevent the indicated inconsistency in the minibuffer list by creating *Minibuf-2* earlier, immediately after incrementing minibuf_level to 2. And, as promised, I will tidy up the untidy and unsafe coding. Does anybody have any comments before I start hacking this? -- Alan Mackenzie (Nuremberg, Germany).
bug-gnu-emacs <at> gnu.org:bug#48337; Package emacs.
(Thu, 13 May 2021 07:56:01 GMT) Full text and rfc822 format available.Message #50 received at 48337 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Alan Mackenzie <acm <at> muc.de>, Eli Zaretskii <eliz <at> gnu.org> Cc: 48337 <at> debbugs.gnu.org, alex.bennee <at> linaro.org Subject: Re: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Thu, 13 May 2021 09:54:52 +0200
> The deeper cause of the bug is that calling buffer-list-update-hook > simply doesn't belong in record-window-buffer. That hook should be > called when the buffer list changes, not when a window's current buffer > gets "recorded". > > So, as the main fix, I propose moving the call of buffer-list-update-hook > to (some of) the places where record-window-buffer gets called, those > places where the buffer list changes. There are exactly two such places, > both in window.c. This will prevent the chain of events in read_minibuf > outlined above. Alan, please take one step back and reconsider. IIUC you added the `record-window-buffer' call to read_minibuf, added the DO-MINIBUF argument to `record-window-buffer' and now decide that `buffer-list-update-hook' doesn't belong into `record-window-buffer'. Aren't you putting the cart before the horse? That decision might be correct but still constitutes a change that affects all applications running `buffer-list-update-hook'. martin
bug-gnu-emacs <at> gnu.org:bug#48337; Package emacs.
(Thu, 13 May 2021 09:53:02 GMT) Full text and rfc822 format available.Message #53 received at 48337 <at> debbugs.gnu.org (full text, mbox):
From: Alan Mackenzie <acm <at> muc.de> To: martin rudalics <rudalics <at> gmx.at> Cc: Eli Zaretskii <eliz <at> gnu.org>, alex.bennee <at> linaro.org, 48337 <at> debbugs.gnu.org Subject: Re: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Thu, 13 May 2021 09:52:19 +0000
Hello, Martin. On Thu, May 13, 2021 at 09:54:52 +0200, martin rudalics wrote: > > The deeper cause of the bug is that calling buffer-list-update-hook > > simply doesn't belong in record-window-buffer. That hook should be > > called when the buffer list changes, not when a window's current buffer > > gets "recorded". > > So, as the main fix, I propose moving the call of buffer-list-update-hook > > to (some of) the places where record-window-buffer gets called, those > > places where the buffer list changes. There are exactly two such places, > > both in window.c. This will prevent the chain of events in read_minibuf > > outlined above. > Alan, please take one step back and reconsider. IIUC you added the > `record-window-buffer' call to read_minibuf, added the DO-MINIBUF > argument to `record-window-buffer' and now decide that > `buffer-list-update-hook' doesn't belong into `record-window-buffer'. > Aren't you putting the cart before the horse? That decision might be > correct but still constitutes a change that affects all applications > running `buffer-list-update-hook'. Maybe you're right. I've never really liked those changes to record-window-buffer, they're a bit scruffy. The requirement is simply to push a minibuffer onto w->prev_buffers, where w is the mini-window of a frame. Maybe I should instead undo those changes to r-w-b, and write a separate function for pushing the minibuffer onto w->prev_buffers. This would surely be cleaner. Whether that function should be in C or in Lisp (like record-window-buffer) would need to be decided. Maybe r-w-b could use that new function to avoid duplicating code. > martin -- Alan Mackenzie (Nuremberg, Germany).
bug-gnu-emacs <at> gnu.org:bug#48337; Package emacs.
(Thu, 13 May 2021 11:55:02 GMT) Full text and rfc822 format available.Message #56 received at 48337 <at> debbugs.gnu.org (full text, mbox):
From: Alan Mackenzie <acm <at> muc.de> To: martin rudalics <rudalics <at> gmx.at> Cc: Eli Zaretskii <eliz <at> gnu.org>, alex.bennee <at> linaro.org, 48337 <at> debbugs.gnu.org Subject: Re: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Thu, 13 May 2021 11:54:37 +0000
Hello again, Martin.
On Thu, May 13, 2021 at 09:52:19 +0000, Alan Mackenzie wrote:
> On Thu, May 13, 2021 at 09:54:52 +0200, martin rudalics wrote:
> > > The deeper cause of the bug is that calling buffer-list-update-hook
> > > simply doesn't belong in record-window-buffer. That hook should be
> > > called when the buffer list changes, not when a window's current buffer
> > > gets "recorded".
> > > So, as the main fix, I propose moving the call of buffer-list-update-hook
> > > to (some of) the places where record-window-buffer gets called, those
> > > places where the buffer list changes. There are exactly two such places,
> > > both in window.c. This will prevent the chain of events in read_minibuf
> > > outlined above.
> > Alan, please take one step back and reconsider. IIUC you added the
> > `record-window-buffer' call to read_minibuf, added the DO-MINIBUF
> > argument to `record-window-buffer' and now decide that
> > `buffer-list-update-hook' doesn't belong into `record-window-buffer'.
> > Aren't you putting the cart before the horse? That decision might be
> > correct but still constitutes a change that affects all applications
> > running `buffer-list-update-hook'.
> Maybe you're right. I've never really liked those changes to
> record-window-buffer, they're a bit scruffy. The requirement is simply
> to push a minibuffer onto w->prev_buffers, where w is the mini-window of
> a frame.
> Maybe I should instead undo those changes to r-w-b, and write a separate
> function for pushing the minibuffer onto w->prev_buffers. This would
> surely be cleaner. Whether that function should be in C or in Lisp
> (like record-window-buffer) would need to be decided. Maybe r-w-b could
> use that new function to avoid duplicating code.
How about the following functions, in which minibuf.c now bypasses
record-window-buffer, instead calling push-window-buffer-onto-prev
direct? I'm still not convinced that the call to
buffer-list-update-hooks belongs in record-window-buffer, but that
doesn't seem too important any more. On preliminary testing, these
appear to work:
(defun push-window-buffer-onto-prev (&optional window)
"Push entry for WINDOW's buffer onto WINDOW's prev-buffers list.
WINDOW must be a live window and defaults to the selected one.
Any duplicate entries for the buffer in the list are removed."
(let* ((window (window-normalize-window window t))
(buffer (window-buffer window))
(w-list (window-prev-buffers window))
(entry (assq buffer w-list)))
(when entry
(setq w-list (assq-delete-all buffer w-list)))
(let ((start (window-start window))
(point (window-point window)))
(setq entry
(cons buffer
(if entry
;; We have an entry, update marker position.
(list (set-marker (nth 1 entry) start)
(set-marker (nth 2 entry) point))
(list (copy-marker start)
(copy-marker
;; Preserve window-point-insertion-type
;; (Bug#12855)
point (with-current-buffer buffer
window-point-insertion-type))))))
(set-window-prev-buffers window (cons entry w-list)))))
(defun record-window-buffer (&optional window)
"Record WINDOW's buffer.
WINDOW must be a live window and defaults to the selected one.
If WINDOW is a minibuffer, it will only be recorded if DO-MINIBUF
is non-nil."
(let* ((window (window-normalize-window window t))
(buffer (window-buffer window)))
;; Reset WINDOW's next buffers. If needed, they are resurrected by
;; `switch-to-prev-buffer' and `switch-to-next-buffer'.
(set-window-next-buffers window nil)
;; Don't record insignificant buffers.
(when (not (eq (aref (buffer-name buffer) 0) ?\s))
(push-window-buffer-onto-prev window)
(run-hooks 'buffer-list-update-hook))))
> > martin
--
Alan Mackenzie (Nuremberg, Germany).
bug-gnu-emacs <at> gnu.org:bug#48337; Package emacs.
(Thu, 13 May 2021 12:10:01 GMT) Full text and rfc822 format available.Message #59 received at 48337 <at> debbugs.gnu.org (full text, mbox):
From: Alan Mackenzie <acm <at> muc.de> To: martin rudalics <rudalics <at> gmx.at> Cc: Eli Zaretskii <eliz <at> gnu.org>, alex.bennee <at> linaro.org, 48337 <at> debbugs.gnu.org Subject: Re: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Thu, 13 May 2021 12:09:44 +0000
Hello, Martin. On Thu, May 13, 2021 at 11:54:37 +0000, Alan Mackenzie wrote: > How about the following functions, in which minibuf.c now bypasses > record-window-buffer, instead calling push-window-buffer-onto-prev > direct? I'm still not convinced that the call to > buffer-list-update-hooks belongs in record-window-buffer, but that > doesn't seem too important any more. On preliminary testing, these > appear to work: OK, I've wrongly moved the with-current-buffer form in the first function. I'm aware of this and will correct it. Also, I've forgotten to amend the doc string of record-window-buffer. I'll correct that, too. > (defun push-window-buffer-onto-prev (&optional window) > "Push entry for WINDOW's buffer onto WINDOW's prev-buffers list. > WINDOW must be a live window and defaults to the selected one. > Any duplicate entries for the buffer in the list are removed." > (let* ((window (window-normalize-window window t)) > (buffer (window-buffer window)) > (w-list (window-prev-buffers window)) > (entry (assq buffer w-list))) > (when entry > (setq w-list (assq-delete-all buffer w-list))) > (let ((start (window-start window)) > (point (window-point window))) > (setq entry > (cons buffer > (if entry > ;; We have an entry, update marker position. > (list (set-marker (nth 1 entry) start) > (set-marker (nth 2 entry) point)) > (list (copy-marker start) > (copy-marker > ;; Preserve window-point-insertion-type > ;; (Bug#12855) > point (with-current-buffer buffer > window-point-insertion-type)))))) > (set-window-prev-buffers window (cons entry w-list))))) -- Alan Mackenzie (Nuremberg, Germany).
bug-gnu-emacs <at> gnu.org:bug#48337; Package emacs.
(Fri, 14 May 2021 15:21:01 GMT) Full text and rfc822 format available.Message #62 received at 48337 <at> debbugs.gnu.org (full text, mbox):
From: Gregory Heytings <gregory <at> heytings.org> To: martin rudalics <rudalics <at> gmx.at> Cc: Alan Mackenzie <acm <at> muc.de>, Eli Zaretskii <eliz <at> gnu.org>, alex.bennee <at> linaro.org, 48337 <at> debbugs.gnu.org Subject: Re: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Fri, 14 May 2021 15:20:11 +0000
> > Alan, please take one step back and reconsider. IIUC you added the > `record-window-buffer' call to read_minibuf, added the DO-MINIBUF > argument to `record-window-buffer' and now decide that > `buffer-list-update-hook' doesn't belong into `record-window-buffer'. > > Aren't you putting the cart before the horse? That decision might be > correct but still constitutes a change that affects all applications > running `buffer-list-update-hook'. > As I said to Eli a week ago or so: "So far I haven't seen a single concrete example that demonstrates that this feature is either (a) necessary in some circumstances (as was bidirectional editing support), or (b) not necessary but at least useful in some circumstances." Does anyone have such a concrete example? I'm all ears. It seems to me that the only benefit of this feature is a slightly different minibuffer behavior, that some users may perhaps find more convenient, as would be, for example, the possibility to display the minibuffer at the top of the frames. Adding such a feature should not make Emacs 28 backward-incompatible in any way. This experiment started in a bad way: its purpose was to fix a supposed bug, which, as it turned out, was not a bug at all, but the result of a misunderstanding, namely that isearch uses the echo area and not the minibuffer. From then on, more and more changes were added to Emacs. At a minimum, this experiment should be moved to a feature branch, and its result carefully reviewed before being merged again in the trunk.
bug-gnu-emacs <at> gnu.org:bug#48337; Package emacs.
(Fri, 14 May 2021 16:06:02 GMT) Full text and rfc822 format available.Message #65 received at 48337 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Gregory Heytings <gregory <at> heytings.org> Cc: rudalics <at> gmx.at, 48337 <at> debbugs.gnu.org, alex.bennee <at> linaro.org, acm <at> muc.de Subject: Re: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Fri, 14 May 2021 19:05:19 +0300
> Date: Fri, 14 May 2021 15:20:11 +0000 > From: Gregory Heytings <gregory <at> heytings.org> > cc: Eli Zaretskii <eliz <at> gnu.org>, Alan Mackenzie <acm <at> muc.de>, > 48337 <at> debbugs.gnu.org, alex.bennee <at> linaro.org > > As I said to Eli a week ago or so: "So far I haven't seen a single > concrete example that demonstrates that this feature is either (a) > necessary in some circumstances (as was bidirectional editing support), or > (b) not necessary but at least useful in some circumstances." Does anyone > have such a concrete example? I'm all ears. > > It seems to me that the only benefit of this feature is a slightly > different minibuffer behavior, that some users may perhaps find more > convenient, as would be, for example, the possibility to display the > minibuffer at the top of the frames. Adding such a feature should not > make Emacs 28 backward-incompatible in any way. > > This experiment started in a bad way: its purpose was to fix a supposed > bug, which, as it turned out, was not a bug at all, but the result of a > misunderstanding, namely that isearch uses the echo area and not the > minibuffer. From then on, more and more changes were added to Emacs. We are a diverse group of people with different interests in Emacs development, each one scratching the itches that we have, which aren't necessarily itches for others. We should therefore all of us respect the interests and motivations of others, even if they scratch itches that don't look like itches to us. In this case, you have repeatedly stated your opposition to this change, and nothing positive can be expected from expressing that opposition one more time. Can you please calm down and let Alan fix whatever breakage he caused?
bug-gnu-emacs <at> gnu.org:bug#48337; Package emacs.
(Fri, 14 May 2021 16:33:02 GMT) Full text and rfc822 format available.Message #68 received at 48337 <at> debbugs.gnu.org (full text, mbox):
From: Alan Mackenzie <acm <at> muc.de> To: Alex Bennée <alex.bennee <at> linaro.org> Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>, 48337 <at> debbugs.gnu.org, acm <at> muc.de Subject: Re: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Fri, 14 May 2021 16:31:56 +0000
Hello, Alex. On Tue, May 11, 2021 at 23:07:01 +0100, Alex Bennée wrote: > Alan Mackenzie <acm <at> muc.de> writes: > > On Tue, May 11, 2021 at 07:51:20 +0100, Alex Bennée wrote: > >> I can now recreate at will with a magit sequence (l o hackbox/ TAB) which > >> triggers a minibuffer re-size to accommodate the list of git branches: > > Could you possibly give us a precise recipe to reproduce this bug, and a > > GDB backtrace with Emacs compiled with CFLAGS='-O0 g3' (or similar)? So > > much of the needed information in your large dump post has been > > optimised away by the compiler. Would you please also make sure that > > the Lisp backtrace is at the end of the GDB backtrace. I think this > > should happen automatically if you have an Emacs .gdbinit in the > > directory where you start GDB from. I now understand what the bug was, and have just committed a patch which should have fixed it. Could you please update your Emacs and test your bug scenario, and either confirm to me that the bug is fixed, or say what is still wrong. If this has to wait until Monday that's OK, but please let us know that. Then, hopefully, we can close the bug. > The later rr dumps have more symbols but didn't have the benefit of the > Emacs' .gdbinit Lips backtrace. However I'm fairly confident it's being > triggered by doom-modeline: The actual trigger was something on buffer-list-update-hook. That should now no longer cause a problem. [ .... ] > -- > Alex Bennée -- Alan Mackenzie (Nuremberg, Germany).
bug-gnu-emacs <at> gnu.org:bug#48337; Package emacs.
(Fri, 14 May 2021 16:54:02 GMT) Full text and rfc822 format available.Message #71 received at 48337 <at> debbugs.gnu.org (full text, mbox):
From: Alex Bennée <alex.bennee <at> linaro.org> To: Alan Mackenzie <acm <at> muc.de> Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>, 48337 <at> debbugs.gnu.org Subject: Re: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Fri, 14 May 2021 17:52:46 +0100
[Message part 1 (text/plain, inline)]
Sadly not, testing with 780b1db126fcfdbb50da5c1acf24b3c6e614dd9f I got a crash when I tried to switch buffer. On Fri, 14 May 2021 at 17:31, Alan Mackenzie <acm <at> muc.de> wrote: > Hello, Alex. > > On Tue, May 11, 2021 at 23:07:01 +0100, Alex Bennée wrote: > > > Alan Mackenzie <acm <at> muc.de> writes: > > > > On Tue, May 11, 2021 at 07:51:20 +0100, Alex Bennée wrote: > > >> I can now recreate at will with a magit sequence (l o hackbox/ TAB) > which > > >> triggers a minibuffer re-size to accommodate the list of git branches: > > > > Could you possibly give us a precise recipe to reproduce this bug, and > a > > > GDB backtrace with Emacs compiled with CFLAGS='-O0 g3' (or similar)? > So > > > much of the needed information in your large dump post has been > > > optimised away by the compiler. Would you please also make sure that > > > the Lisp backtrace is at the end of the GDB backtrace. I think this > > > should happen automatically if you have an Emacs .gdbinit in the > > > directory where you start GDB from. > > I now understand what the bug was, and have just committed a patch which > should have fixed it. Could you please update your Emacs and test your > bug scenario, and either confirm to me that the bug is fixed, or say what > is still wrong. If this has to wait until Monday that's OK, but please > let us know that. > > Then, hopefully, we can close the bug. > > > The later rr dumps have more symbols but didn't have the benefit of the > > Emacs' .gdbinit Lips backtrace. However I'm fairly confident it's being > > triggered by doom-modeline: > > The actual trigger was something on buffer-list-update-hook. That should > now no longer cause a problem. > > [ .... ] > > > -- > > Alex Bennée > > -- > Alan Mackenzie (Nuremberg, Germany). > -- Alex Bennée KVM/QEMU Hacker for Linaro
[Message part 2 (text/html, inline)]
[testing.txt (text/plain, attachment)]
bug-gnu-emacs <at> gnu.org:bug#48337; Package emacs.
(Fri, 14 May 2021 17:32:01 GMT) Full text and rfc822 format available.Message #74 received at 48337 <at> debbugs.gnu.org (full text, mbox):
From: Gregory Heytings <gregory <at> heytings.org> To: Eli Zaretskii <eliz <at> gnu.org> Cc: rudalics <at> gmx.at, 48337 <at> debbugs.gnu.org, alex.bennee <at> linaro.org, acm <at> muc.de Subject: Re: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Fri, 14 May 2021 17:31:12 +0000
>> As I said to Eli a week ago or so: "So far I haven't seen a single >> concrete example that demonstrates that this feature is either (a) >> necessary in some circumstances (as was bidirectional editing support), >> or (b) not necessary but at least useful in some circumstances." Does >> anyone have such a concrete example? I'm all ears. >> >> It seems to me that the only benefit of this feature is a slightly >> different minibuffer behavior, that some users may perhaps find more >> convenient, as would be, for example, the possibility to display the >> minibuffer at the top of the frames. Adding such a feature should not >> make Emacs 28 backward-incompatible in any way. >> >> This experiment started in a bad way: its purpose was to fix a supposed >> bug, which, as it turned out, was not a bug at all, but the result of a >> misunderstanding, namely that isearch uses the echo area and not the >> minibuffer. From then on, more and more changes were added to Emacs. > > We are a diverse group of people with different interests in Emacs > development, each one scratching the itches that we have, which aren't > necessarily itches for others. We should therefore all of us respect > the interests and motivations of others, even if they scratch itches > that don't look like itches to us. > > In this case, you have repeatedly stated your opposition to this change, > and nothing positive can be expected from expressing that opposition one > more time. Can you please calm down and let Alan fix whatever breakage > he caused? > I'm very calm. Indeed I opposed this change, from day one, as much as, and with the same energy as you opposed the change of the TAB key in xref in bug#44611 for example. I will continue to do so until someone explains why this change is a "significant improvement" as you said, so significant that it's suddenly okay to introduce backward-incompatible changes in a central UI element of Emacs. IOW, the "something positive" that can be expected from that opposition is an answer to that question.
bug-gnu-emacs <at> gnu.org:bug#48337; Package emacs.
(Fri, 14 May 2021 18:20:01 GMT) Full text and rfc822 format available.Message #77 received at 48337 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Gregory Heytings <gregory <at> heytings.org> Cc: rudalics <at> gmx.at, 48337 <at> debbugs.gnu.org, alex.bennee <at> linaro.org, acm <at> muc.de Subject: Re: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Fri, 14 May 2021 21:19:24 +0300
> Date: Fri, 14 May 2021 17:31:12 +0000 > From: Gregory Heytings <gregory <at> heytings.org> > cc: rudalics <at> gmx.at, acm <at> muc.de, 48337 <at> debbugs.gnu.org, alex.bennee <at> linaro.org > > > In this case, you have repeatedly stated your opposition to this change, > > and nothing positive can be expected from expressing that opposition one > > more time. Can you please calm down and let Alan fix whatever breakage > > he caused? > > I'm very calm. Indeed I opposed this change, from day one, as much as, > and with the same energy as you opposed the change of the TAB key in xref > in bug#44611 for example. My job here includes the need to try to provide guidance regarding directions I think are beneficial for future developments and those which I think aren't. You are not yet in that position. > I will continue to do so until someone explains why this change is a > "significant improvement" No one is under any obligation to give you such an explanation. So my recommendation is to stop asking for it, because nothing but aggravation can ever come out of that. You expressed your opposition and provided your arguments, so people who want to hear will take that under consideration.
bug-gnu-emacs <at> gnu.org:bug#48337; Package emacs.
(Fri, 14 May 2021 18:41:01 GMT) Full text and rfc822 format available.Message #80 received at 48337 <at> debbugs.gnu.org (full text, mbox):
From: Alan Mackenzie <acm <at> muc.de> To: Alex Bennée <alex.bennee <at> linaro.org> Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>, 48337 <at> debbugs.gnu.org Subject: Re: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Fri, 14 May 2021 18:40:03 +0000
Hello, Alex.
On Fri, May 14, 2021 at 17:52:46 +0100, Alex Bennée wrote:
> Sadly not, testing with 780b1db126fcfdbb50da5c1acf24b3c6e614dd9f I got a
> crash when I tried to switch buffer.
Thanks for the two dumps. They make it obvious what has happened.
buffer-list-update-hook is getting called before the new minibuffer has
been pushed onto the minnibuffer list.
Could I ask you to try out the following patch which should fix that
problem. Thanks!
diff --git a/src/minibuf.c b/src/minibuf.c
index 428998a639..d4702ee684 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -653,11 +653,11 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
return unbind_to (count, val);
}
- minibuf_level++; /* Before calling choose_minibuf_frame. */
/* Ensure now that the latest minibuffer has been created, in case
anything happens which depends on MINNIBUF_LEVEL and
Vminibuffer_list being consistent with eachother. */
- minibuffer = get_minibuffer (minibuf_level);
+ minibuffer = get_minibuffer (minibuf_level + 1);
+ minibuf_level++; /* Before calling choose_minibuf_frame. */
/* Choose the minibuffer window and frame, and take action on them. */
> On Fri, 14 May 2021 at 17:31, Alan Mackenzie <acm <at> muc.de> wrote:
> > Hello, Alex.
> > On Tue, May 11, 2021 at 23:07:01 +0100, Alex Bennée wrote:
> > > Alan Mackenzie <acm <at> muc.de> writes:
> > > > On Tue, May 11, 2021 at 07:51:20 +0100, Alex Bennée wrote:
> > > >> I can now recreate at will with a magit sequence (l o hackbox/ TAB)
> > which
> > > >> triggers a minibuffer re-size to accommodate the list of git branches:
> > > > Could you possibly give us a precise recipe to reproduce this bug, and
> > a
> > > > GDB backtrace with Emacs compiled with CFLAGS='-O0 g3' (or similar)?
> > So
> > > > much of the needed information in your large dump post has been
> > > > optimised away by the compiler. Would you please also make sure that
> > > > the Lisp backtrace is at the end of the GDB backtrace. I think this
> > > > should happen automatically if you have an Emacs .gdbinit in the
> > > > directory where you start GDB from.
> > I now understand what the bug was, and have just committed a patch which
> > should have fixed it. Could you please update your Emacs and test your
> > bug scenario, and either confirm to me that the bug is fixed, or say what
> > is still wrong. If this has to wait until Monday that's OK, but please
> > let us know that.
> > Then, hopefully, we can close the bug.
> > > The later rr dumps have more symbols but didn't have the benefit of the
> > > Emacs' .gdbinit Lips backtrace. However I'm fairly confident it's being
> > > triggered by doom-modeline:
> > The actual trigger was something on buffer-list-update-hook. That should
> > now no longer cause a problem.
> > [ .... ]
> --
> Alex Bennée
> KVM/QEMU Hacker for Linaro
> +bt
> #0 0x00007ffff4e955cb in raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> #1 0x0000555555728708 in terminate_due_to_signal (sig=6, backtrace_limit=40) at emacs.c:437
> #2 0x000055555575daa0 in emacs_abort () at sysdep.c:2282
> #3 0x0000555555783080 in Factive_minibuffer_window () at minibuf.c:231
> #4 0x0000555555810a6e in funcall_subr (subr=0x555555e0c6c0 <Sactive_minibuffer_window>, numargs=0, args=0x7fffffffad70) at eval.c:3109
> #5 0x000055555581053e in Ffuncall (nargs=1, args=0x7fffffffad68) at eval.c:3036
> #6 0x000055555586ad5b in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x7fffffffb238) at bytecode.c:632
> #7 0x0000555555810d06 in fetch_and_exec_byte_code (fun=..., syms_left=..., nargs=1, args=0x7fffffffb230) at eval.c:3160
> #8 0x000055555581118c in funcall_lambda (fun=..., nargs=1, arg_vector=0x7fffffffb230) at eval.c:3241
> #9 0x0000555555810592 in Ffuncall (nargs=2, args=0x7fffffffb228) at eval.c:3040
> #10 0x000055555586ad5b in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=0, args=0x7fffffffb7a0) at bytecode.c:632
> #11 0x0000555555810d06 in fetch_and_exec_byte_code (fun=..., syms_left=..., nargs=0, args=0x7fffffffb7a0) at eval.c:3160
> #12 0x000055555581118c in funcall_lambda (fun=..., nargs=0, arg_vector=0x7fffffffb7a0) at eval.c:3241
> #13 0x0000555555810592 in Ffuncall (nargs=1, args=0x7fffffffb798) at eval.c:3040
> #14 0x000055555580f7a4 in funcall_nil (nargs=1, args=0x7fffffffb798) at eval.c:2677
> #15 0x000055555580fcce in run_hook_with_args (nargs=1, args=0x7fffffffb798, funcall=0x55555580f781 <funcall_nil>) at eval.c:2854
> #16 0x000055555580f82a in Frun_hook_with_args (nargs=1, args=0x7fffffffb798) at eval.c:2719
> #17 0x000055555580fd66 in run_hook (hook=...) at eval.c:2867
> #18 0x000055555580f7e5 in Frun_hooks (nargs=1, args=0x7fffffffb8f8) at eval.c:2701
> #19 0x0000555555810978 in funcall_subr (subr=0x555555e15660 <Srun_hooks>, numargs=1, args=0x7fffffffb8f8) at eval.c:3091
> #20 0x000055555581053e in Ffuncall (nargs=2, args=0x7fffffffb8f0) at eval.c:3036
> #21 0x000055555580fe5b in call1 (fn=..., arg1=...) at eval.c:2896
> #22 0x00005555557650a0 in run_buffer_list_update_hook (buf=0x555555f4ba60) at buffer.c:529
> #23 0x0000555555765504 in Fget_buffer_create (buffer_or_name=..., inhibit_buffer_hooks=...) at buffer.c:635
> #24 0x0000555555785d94 in get_minibuffer (depth=1) at minibuf.c:1028 <=======================================
> #25 0x00005555557841fd in read_minibuf (map=..., initial=..., prompt=..., expflag=false, histvar=..., histpos=..., defalt=..., allow_props=false, inherit_input_method=false) at minibuf.c:660
--
Alan Mackenzie (Nuremberg, Germany).
bug-gnu-emacs <at> gnu.org:bug#48337; Package emacs.
(Fri, 14 May 2021 22:37:02 GMT) Full text and rfc822 format available.Message #83 received at 48337 <at> debbugs.gnu.org (full text, mbox):
From: Alex Bennée <alex.bennee <at> linaro.org> To: Alan Mackenzie <acm <at> muc.de> Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>, 48337 <at> debbugs.gnu.org Subject: Re: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Fri, 14 May 2021 23:35:34 +0100
Alan Mackenzie <acm <at> muc.de> writes: > Hello, Alex. > > On Fri, May 14, 2021 at 17:52:46 +0100, Alex Bennée wrote: >> Sadly not, testing with 780b1db126fcfdbb50da5c1acf24b3c6e614dd9f I got a >> crash when I tried to switch buffer. > > Thanks for the two dumps. They make it obvious what has happened. > buffer-list-update-hook is getting called before the new minibuffer has > been pushed onto the minnibuffer list. > > Could I ask you to try out the following patch which should fix that > problem. Thanks! That seems to sort out both the recent crash and the original failure mode I reported in this bug. > > > diff --git a/src/minibuf.c b/src/minibuf.c > index 428998a639..d4702ee684 100644 > --- a/src/minibuf.c > +++ b/src/minibuf.c > @@ -653,11 +653,11 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt, > return unbind_to (count, val); > } > > - minibuf_level++; /* Before calling choose_minibuf_frame. */ > /* Ensure now that the latest minibuffer has been created, in case > anything happens which depends on MINNIBUF_LEVEL and > Vminibuffer_list being consistent with eachother. */ > - minibuffer = get_minibuffer (minibuf_level); > + minibuffer = get_minibuffer (minibuf_level + 1); > + minibuf_level++; /* Before calling choose_minibuf_frame. */ > > /* Choose the minibuffer window and frame, and take action on them. */ > > > > >> On Fri, 14 May 2021 at 17:31, Alan Mackenzie <acm <at> muc.de> wrote: > >> > Hello, Alex. > >> > On Tue, May 11, 2021 at 23:07:01 +0100, Alex Bennée wrote: > >> > > Alan Mackenzie <acm <at> muc.de> writes: > >> > > > On Tue, May 11, 2021 at 07:51:20 +0100, Alex Bennée wrote: >> > > >> I can now recreate at will with a magit sequence (l o hackbox/ TAB) >> > which >> > > >> triggers a minibuffer re-size to accommodate the list of git branches: > >> > > > Could you possibly give us a precise recipe to reproduce this bug, and >> > a >> > > > GDB backtrace with Emacs compiled with CFLAGS='-O0 g3' (or similar)? >> > So >> > > > much of the needed information in your large dump post has been >> > > > optimised away by the compiler. Would you please also make sure that >> > > > the Lisp backtrace is at the end of the GDB backtrace. I think this >> > > > should happen automatically if you have an Emacs .gdbinit in the >> > > > directory where you start GDB from. > >> > I now understand what the bug was, and have just committed a patch which >> > should have fixed it. Could you please update your Emacs and test your >> > bug scenario, and either confirm to me that the bug is fixed, or say what >> > is still wrong. If this has to wait until Monday that's OK, but please >> > let us know that. > >> > Then, hopefully, we can close the bug. > >> > > The later rr dumps have more symbols but didn't have the benefit of the >> > > Emacs' .gdbinit Lips backtrace. However I'm fairly confident it's being >> > > triggered by doom-modeline: > >> > The actual trigger was something on buffer-list-update-hook. That should >> > now no longer cause a problem. > >> > [ .... ] > > > >> -- >> Alex Bennée >> KVM/QEMU Hacker for Linaro > >> +bt >> #0 0x00007ffff4e955cb in raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:50 >> #1 0x0000555555728708 in terminate_due_to_signal (sig=6, backtrace_limit=40) at emacs.c:437 >> #2 0x000055555575daa0 in emacs_abort () at sysdep.c:2282 >> #3 0x0000555555783080 in Factive_minibuffer_window () at minibuf.c:231 >> #4 0x0000555555810a6e in funcall_subr (subr=0x555555e0c6c0 <Sactive_minibuffer_window>, numargs=0, args=0x7fffffffad70) at eval.c:3109 >> #5 0x000055555581053e in Ffuncall (nargs=1, args=0x7fffffffad68) at eval.c:3036 >> #6 0x000055555586ad5b in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x7fffffffb238) at bytecode.c:632 >> #7 0x0000555555810d06 in fetch_and_exec_byte_code (fun=..., syms_left=..., nargs=1, args=0x7fffffffb230) at eval.c:3160 >> #8 0x000055555581118c in funcall_lambda (fun=..., nargs=1, arg_vector=0x7fffffffb230) at eval.c:3241 >> #9 0x0000555555810592 in Ffuncall (nargs=2, args=0x7fffffffb228) at eval.c:3040 >> #10 0x000055555586ad5b in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=0, args=0x7fffffffb7a0) at bytecode.c:632 >> #11 0x0000555555810d06 in fetch_and_exec_byte_code (fun=..., syms_left=..., nargs=0, args=0x7fffffffb7a0) at eval.c:3160 >> #12 0x000055555581118c in funcall_lambda (fun=..., nargs=0, arg_vector=0x7fffffffb7a0) at eval.c:3241 >> #13 0x0000555555810592 in Ffuncall (nargs=1, args=0x7fffffffb798) at eval.c:3040 >> #14 0x000055555580f7a4 in funcall_nil (nargs=1, args=0x7fffffffb798) at eval.c:2677 >> #15 0x000055555580fcce in run_hook_with_args (nargs=1, args=0x7fffffffb798, funcall=0x55555580f781 <funcall_nil>) at eval.c:2854 >> #16 0x000055555580f82a in Frun_hook_with_args (nargs=1, args=0x7fffffffb798) at eval.c:2719 >> #17 0x000055555580fd66 in run_hook (hook=...) at eval.c:2867 >> #18 0x000055555580f7e5 in Frun_hooks (nargs=1, args=0x7fffffffb8f8) at eval.c:2701 >> #19 0x0000555555810978 in funcall_subr (subr=0x555555e15660 <Srun_hooks>, numargs=1, args=0x7fffffffb8f8) at eval.c:3091 >> #20 0x000055555581053e in Ffuncall (nargs=2, args=0x7fffffffb8f0) at eval.c:3036 >> #21 0x000055555580fe5b in call1 (fn=..., arg1=...) at eval.c:2896 >> #22 0x00005555557650a0 in run_buffer_list_update_hook (buf=0x555555f4ba60) at buffer.c:529 >> #23 0x0000555555765504 in Fget_buffer_create (buffer_or_name=..., inhibit_buffer_hooks=...) at buffer.c:635 >> #24 0x0000555555785d94 in get_minibuffer (depth=1) at minibuf.c:1028 <======================================= >> #25 0x00005555557841fd in read_minibuf (map=..., initial=..., prompt=..., expflag=false, histvar=..., histpos=..., defalt=..., allow_props=false, inherit_input_method=false) at minibuf.c:660 -- Alex Bennée
bug-gnu-emacs <at> gnu.org:bug#48337; Package emacs.
(Sat, 15 May 2021 09:46:01 GMT) Full text and rfc822 format available.Message #86 received at 48337 <at> debbugs.gnu.org (full text, mbox):
From: Gregory Heytings <gregory <at> heytings.org> To: Eli Zaretskii <eliz <at> gnu.org> Cc: acm <at> muc.de, 48337 <at> debbugs.gnu.org, alex.bennee <at> linaro.org Subject: Re: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Sat, 15 May 2021 09:45:29 +0000
>> I will continue to do so until someone explains why this change is a >> "significant improvement" > > No one is under any obligation to give you such an explanation. So my > recommendation is to stop asking for it, because nothing but aggravation > can ever come out of that. You expressed your opposition and provided > your arguments, so people who want to hear will take that under > consideration. > That's an answer. Not the one I expected, obviously.
bug-gnu-emacs <at> gnu.org:bug#48337; Package emacs.
(Sat, 15 May 2021 12:01:01 GMT) Full text and rfc822 format available.Message #89 received at 48337 <at> debbugs.gnu.org (full text, mbox):
From: Alan Mackenzie <acm <at> muc.de> To: Alex Bennée <alex.bennee <at> linaro.org> Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>, 48337 <at> debbugs.gnu.org Subject: Re: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Sat, 15 May 2021 12:00:01 +0000
Hello, Alex. On Fri, May 14, 2021 at 23:35:34 +0100, Alex Bennée wrote: > Alan Mackenzie <acm <at> muc.de> writes: > > On Fri, May 14, 2021 at 17:52:46 +0100, Alex Bennée wrote: > >> Sadly not, testing with 780b1db126fcfdbb50da5c1acf24b3c6e614dd9f I got a > >> crash when I tried to switch buffer. > > Thanks for the two dumps. They make it obvious what has happened. > > buffer-list-update-hook is getting called before the new minibuffer has > > been pushed onto the minnibuffer list. > > Could I ask you to try out the following patch which should fix that > > problem. Thanks! > That seems to sort out both the recent crash and the original failure > mode I reported in this bug. Excellent! Thanks for doing the testing. I think I'd rather leave the bug open a bit longer, just in case any other failures turn up. > > diff --git a/src/minibuf.c b/src/minibuf.c > > index 428998a639..d4702ee684 100644 > > --- a/src/minibuf.c > > +++ b/src/minibuf.c > > @@ -653,11 +653,11 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt, > > return unbind_to (count, val); > > } > > - minibuf_level++; /* Before calling choose_minibuf_frame. */ > > /* Ensure now that the latest minibuffer has been created, in case > > anything happens which depends on MINNIBUF_LEVEL and > > Vminibuffer_list being consistent with eachother. */ > > - minibuffer = get_minibuffer (minibuf_level); > > + minibuffer = get_minibuffer (minibuf_level + 1); > > + minibuf_level++; /* Before calling choose_minibuf_frame. */ > > > > /* Choose the minibuffer window and frame, and take action on them. */ > -- > Alex Bennée -- Alan Mackenzie (Nuremberg, Germany).
Alan Mackenzie <acm <at> muc.de>:Alex Bennée <alex.bennee <at> linaro.org>:Message #94 received at 48337-done <at> debbugs.gnu.org (full text, mbox):
From: Alan Mackenzie <acm <at> muc.de> To: Alex Bennée <alex.bennee <at> linaro.org> Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>, 48337-done <at> debbugs.gnu.org, acm <at> muc.de Subject: Re: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Sun, 16 May 2021 14:24:27 +0000
Hello, Alex. On Sat, May 15, 2021 at 12:00:01 +0000, Alan Mackenzie wrote: > On Fri, May 14, 2021 at 23:35:34 +0100, Alex Bennée wrote: > > Alan Mackenzie <acm <at> muc.de> writes: [ .... ] > > > Could I ask you to try out the following patch which should fix > > > that problem. Thanks! > > That seems to sort out both the recent crash and the original > > failure mode I reported in this bug. > Excellent! Thanks for doing the testing. > I think I'd rather leave the bug open a bit longer, just in case any > other failures turn up. The emacs-devel list has gone quiet over this bug, so it seems that Eli Z's fixes from yesterday have completed the fix. So, I'm closing this bug, now. > > -- > > Alex Bennée -- Alan Mackenzie (Nuremberg, Germany).
Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org.
(Mon, 14 Jun 2021 11:24:05 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.