* bug#34655: 26.1.92; Segfault in module with --module-assertions
@ 2019-02-25 21:00 Basil L. Contovounesios
2019-02-26 2:59 ` Richard Stallman
2019-02-26 15:45 ` Eli Zaretskii
0 siblings, 2 replies; 32+ messages in thread
From: Basil L. Contovounesios @ 2019-02-25 21:00 UTC (permalink / raw)
To: 34655
[-- Attachment #1: GDB log --]
[-- Type: text/plain, Size: 45468 bytes --]
Starting program: /home/blc/.local/src/emacs26/src/emacs -Q --module-assertions
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff01cb700 (LWP 8299)]
[New Thread 0x7fffef9ac700 (LWP 8300)]
[New Thread 0x7fffef1ab700 (LWP 8301)]
Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
re_search_2 (bufp=0xbf5d00 <searchbufs+384>, str1=0x0, size1=0, str2=0x0, size2=18, startpos=0,
range=18, regs=0x0, stop=18) at regex.c:4354
4354 buf_ch = STRING_CHAR_AND_LENGTH (d, buf_charlen);
#0 0x0000000000608594 in re_search_2
(bufp=0xbf5d00 <searchbufs+384>, str1=0x0, size1=0, str2=0x0, size2=18, startpos=0, range=18, regs=0x0, stop=18) at regex.c:4354
buf_charlen = 0
irange = 18
lim = 0
d = 0x0
buf_ch = 18
val = 691541629
string1 = 0x0
string2 = 0x0
fastmap = 0xbf5d38 <searchbufs+440> ""
translate = make_number(0)
total_size = 18
endpos = 18
anchored_start = 0 '\000'
multibyte = 1 '\001'
#1 0x0000000000607f91 in re_search
(bufp=0xbf5d00 <searchbufs+384>, string=0x0, size=18, startpos=0, range=18, regs=0x0)
at regex.c:4181
#2 0x00000000005f3fd0 in fast_string_match_internal
(regexp=XIL(0x8c761c), string=XIL(0x3036ec4), table=XIL(0)) at search.c:485
val = 140737488336288
bufp = 0xbf5d00 <searchbufs+384>
#3 0x0000000000581b5e in fast_string_match (regexp=XIL(0x8c761c), string=XIL(0x3036ec4)) at lisp.h:4061
#4 0x00000000005d7b2d in Ffind_file_name_handler (filename=XIL(0x3036ec4), operation=XIL(0x5af0))
at fileio.c:313
string = XIL(0x8c761c)
match_pos = 140737488336448
handler = XIL(0x4e1380)
operations = XIL(0x10b5c83)
elt = XIL(0x10ae193)
chain = XIL(0x15749e3)
inhibited_handlers = XIL(0)
result = XIL(0)
pos = -1
#5 0x00000000005d8002 in Ffile_name_as_directory (file=XIL(0x3036ec4)) at fileio.c:547
buf = 0x7fffffffb6b0 "P\267\377\377\377\177"
length = 4458226606852
handler = make_number(4)
val = XIL(0x57e6cb)
sa_avail = 16384
sa_count = 24
sa_must_free = false
#6 0x0000000000644443 in funcall_subr
(subr=0x7e7d00 <Sfile_name_as_directory>, numargs=1, args=0x7fffffffb7c8) at eval.c:2851
internal_argbuf =
{XIL(0x7e7d00), XIL(0x7fffffffb718), make_number(1440909), XIL(0xa00c0b080), XIL(0x7e7d05), XIL(0x7fffffffb738), XIL(0x7e7d00), XIL(0x7fffffffb730)}
internal_args = 0x7fffffffb7c8
#7 0x0000000000643f75 in Ffuncall (nargs=2, args=0x7fffffffb7c0) at eval.c:2776
fun = XIL(0x7e7d05)
original_fun = XIL(0x5af0)
funcar = XIL(0x57e6cb)
numargs = 1
val = XIL(0x3031c43)
count = 23
#8 0x0000000000682ae1 in module_funcall (env=0x3036810, fun=0x2e4d680, nargs=1, args=0x7fffffffb8f0)
at emacs-module.c:478
internal_handler_CONDITION_CASE = 0x2c803a0
internal_cleanup_CONDITION_CASE = 0x2c803a0
internal_handler_CATCHER_ALL = 0x2c818d0
internal_cleanup_CATCHER_ALL = 0x2c818d0
newargs = 0x7fffffffb7c0
sa_avail = 16368
sa_count = 23
sa_must_free = false
nargs1 = 2
result = 0x7fffffffb880
#9 0x00007fffee6d21e4 in () at /tmp/tmp.wcwAarLF0X/realpath/realpath.so
#10 0x00007fffee6d2407 in () at /tmp/tmp.wcwAarLF0X/realpath/realpath.so
#11 0x0000000000684e4b in funcall_module (function=XIL(0x1436cd5), nargs=1, arglist=0x7fffffffbb70)
at emacs-module.c:783
func = 0x1436cd0 <bss_sbrk_buffer+8420464>
pub = {
size = 210453397508,
private_members = 0x0,
make_global_ref = 0x0,
free_global_ref = 0x770000005b,
non_local_exit_check = 0x0,
non_local_exit_clear = 0x0,
non_local_exit_get = 0x13,
non_local_exit_signal = 0x0,
non_local_exit_throw = 0x7fffffffb9e0,
make_function = 0xc17f20 <lispsym+52896>,
funcall = 0xfffffffffffffc48,
intern = 0xcea0,
type_of = 0x7fffffffba00,
is_not_nil = 0x57e6cb <builtin_lisp_symbol+48>,
eq = 0x0,
extract_integer = 0x44e01043390,
make_integer = 0x7fffffffba40,
extract_float = 0x61f56e <Fsymbol_value+43>,
make_float = 0x57f236 <PSEUDOVECTORP+63>,
copy_string_contents = 0x438310 <x_figure_window_size+6133>,
make_string = 0x7fffffffba40,
make_user_ptr = 0x8096c4 <pure+130788>,
get_user_ptr = 0xb8f000 <Sadd1>,
set_user_ptr = 0x0,
get_user_finalizer = 0x7fffffffbb60,
set_user_finalizer = 0x642070 <eval_sub+210>,
vec_get = 0x7fffffffba70,
vec_set = 0x438310 <x_figure_window_size+6133>,
vec_size = 0x7fffffffbad0,
should_quit = 0x1105398 <bss_sbrk_buffer+5071672>
}
priv = {
pending_non_local_exit = emacs_funcall_exit_return,
non_local_exit_symbol = XIL(0),
non_local_exit_data = XIL(0),
values = XIL(0xc9a023)
}
env = 0x3036810
count = 22
sa_avail = 16376
sa_count = 23
sa_must_free = false
args = 0x7fffffffb930
ret = 0x1100642c1e
#12 0x0000000000644baa in funcall_lambda (fun=XIL(0x1436cd5), nargs=1, arg_vector=0x7fffffffbb70)
at eval.c:2987
val = XIL(0x648c9c)
syms_left = XIL(0x7fffffffbb70)
next = XIL(0x20b9830)
lexenv = XIL(0x580de9)
count = 22
i = 34314288
optional = false
rest = false
previous_optional_or_rest = false
#13 0x00000000006447f1 in apply_lambda (fun=XIL(0x1436cd5), args=XIL(0x2fc8cb3), count=21)
at eval.c:2913
args_left = XIL(0)
i = 1
numargs = 1
arg_vector = 0x7fffffffbb70
tem = XIL(0x8096c4)
sa_avail = 16376
sa_count = 22
sa_must_free = false
#14 0x00000000006429c9 in eval_sub (form=XIL(0x2fc8ca3)) at eval.c:2286
fun = XIL(0x1436cd5)
val = make_number(230)
original_fun = XIL(0x20b9830)
original_args = XIL(0x2fc8cb3)
funcar = XIL(0x2fab7e9)
count = 21
argvals =
{XIL(0x2fc8833), XIL(0x2fc8db3), XIL(0x2fc8873), XIL(0x2fb2868), XIL(0x41f2b0), XIL(0x685581), XIL(0x10), make_number(2)}
#15 0x000000000063cef2 in Fprogn (body=XIL(0x2fc8e13)) at eval.c:459
form = XIL(0x2fc8ca3)
val = XIL(0)
#16 0x000000000063cf24 in prog_ignore (body=XIL(0x2fc8e23)) at eval.c:470
#17 0x000000000063f11c in Fwhile (args=XIL(0x2fc8e33)) at eval.c:992
test = XIL(0x2fc8db3)
body = XIL(0x2fc8e23)
#18 0x0000000000642382 in eval_sub (form=XIL(0x2fc8e43)) at eval.c:2193
args_left = XIL(0x2fc8e33)
numargs = make_number(3)
fun = XIL(0xb90f45)
val = XIL(0x7fffffffbe80)
original_fun = XIL(0xae0a0)
original_args = XIL(0x2fc8e33)
funcar = XIL(0xc0b080)
count = 20
argvals =
{XIL(0), XIL(0), XIL(0x2fb4ad0), XIL(0), XIL(0x7fffffffbfc0), XIL(0x684bff), XIL(0x7fffffffbe60), XIL(0x2d788b4)}
#19 0x000000000063cef2 in Fprogn (body=XIL(0)) at eval.c:459
form = XIL(0x2fc8e43)
val = XIL(0)
#20 0x000000000063f03c in Flet (args=XIL(0x2fc8e63)) at eval.c:973
temps = 0x7fffffffbf00
tem = make_number(0)
lexenv = XIL(0)
elt = XIL(0x2fc8d63)
varlist = XIL(0)
count = 18
argnum = 2
sa_avail = 16368
sa_count = 18
sa_must_free = false
varlist_len = 2
nvars = 2
#21 0x0000000000642382 in eval_sub (form=XIL(0x2fc8e73)) at eval.c:2193
args_left = XIL(0x2fc8e63)
numargs = make_number(2)
fun = XIL(0xb90f05)
val = XIL(0xc2a0)
original_fun = XIL(0x83a0)
original_args = XIL(0x2fc8e63)
funcar = XIL(0x57e6cb)
count = 17
argvals =
{XIL(0x2d788b4), XIL(0), make_number(0), XIL(0xc0a7a0), XIL(0x7fffffffc060), XIL(0xc0b080), XIL(0x2fc9323), XIL(0)}
#22 0x000000000063cef2 in Fprogn (body=XIL(0)) at eval.c:459
form = XIL(0x2fc8e73)
val = XIL(0xc2a0)
#23 0x0000000000642382 in eval_sub (form=XIL(0x2fc8f43)) at eval.c:2193
args_left = XIL(0x2fc8f53)
numargs = make_number(2)
fun = XIL(0xb90bc5)
val = XIL(0x1105280)
original_fun = XIL(0xa920)
original_args = XIL(0x2fc8f53)
funcar = make_number(1644217)
count = 16
argvals =
{XIL(0x7fffffffc190), XIL(0xc0a7a0), XIL(0xc9e400), XIL(0), XIL(0x7fffffffc1b0), XIL(0xc12a90), XIL(0x580b87), XIL(0)}
#24 0x0000000000641d39 in Feval (form=XIL(0x2fc8f43), lexical=XIL(0)) at eval.c:2061
count = 15
#25 0x0000000000644464 in funcall_subr (subr=0xb911c0 <Seval>, numargs=2, args=0x7fffffffc3f0)
at eval.c:2853
internal_argbuf =
{XIL(0xb911c0), XIL(0x7fffffffc2d8), make_number(1440909), XIL(0xa00c0b080), XIL(0xb911c5), XIL(0x7fffffffc2f8), XIL(0xb911c0), XIL(0x7fffffffc2f0)}
internal_args = 0x7fffffffc3f0
#26 0x0000000000643f75 in Ffuncall (nargs=3, args=0x7fffffffc3e8) at eval.c:2776
fun = XIL(0xb911c5)
original_fun = XIL(0x53a0)
funcar = make_number(1604955)
numargs = 2
val = XIL(0x7fffffffc370)
count = 14
#27 0x00000000006996f0 in exec_byte_code
(bytestr=XIL(0x94685c), vector=XIL(0x94687d), maxdepth=make_number(16), args_template=make_number(257), nargs=1, args=0x7fffffffc890) at bytecode.c:630
op = 2
type = (unknown: 2218598600)
targets =
{0x69c65f <exec_byte_code+15689>, 0x69c684 <exec_byte_code+15726>, 0x69c686 <exec_byte_code+15728>, 0x69c688 <exec_byte_code+15730>, 0x69c68a <exec_byte_code+15732>, 0x69c68a <exec_byte_code+15732>, 0x69c6ef <exec_byte_code+15833>, 0x69c763 <exec_byte_code+15949>, 0x698e2a <exec_byte_code+1300>, 0x698e2c <exec_byte_code+1302>, 0x698e2e <exec_byte_code+1304>, 0x698e30 <exec_byte_code+1306>, 0x698e32 <exec_byte_code+1308>, 0x698e32 <exec_byte_code+1308>, 0x698e38 <exec_byte_code+1314>, 0x698df9 <exec_byte_code+1251>, 0x6992fe <exec_byte_code+2536>, 0x699300 <exec_byte_code+2538>, 0x699302 <exec_byte_code+2540>, 0x699304 <exec_byte_code+2542>, 0x699306 <exec_byte_code+2544>, 0x699306 <exec_byte_code+2544>, 0x69933b <exec_byte_code+2597>, 0x69930c <exec_byte_code+2550>, 0x69960d <exec_byte_code+3319>, 0x69960f <exec_byte_code+3321>, 0x699611 <exec_byte_code+3323>, 0x699613 <exec_byte_code+3325>, 0x699615 <exec_byte_code+3327>, 0x699615 <exec_byte_code+3327>, 0x6995c7 <exec_byte_code+3249>, 0x6995de <exec_byte_code+3272>, 0x6996bd <exec_byte_code+3495>, 0x6996bf <exec_byte_code+3497>, 0x6996c1 <exec_byte_code+3499>, 0x6996c3 <exec_byte_code+3501>, 0x6996c5 <exec_byte_code+3503>, 0x6996c5 <exec_byte_code+3503>, 0x699677 <exec_byte_code+3425>, 0x69968e <exec_byte_code+3448>, 0x699772 <exec_byte_code+3676>, 0x699774 <exec_byte_code+3678>, 0x699776 <exec_byte_code+3680>, 0x699778 <exec_byte_code+3682>, 0x69977a <exec_byte_code+3684>, 0x69977a <exec_byte_code+3684>, 0x69972c <exec_byte_code+3606>, 0x699743 <exec_byte_code+3629>, 0x699fd1 <exec_byte_code+5819>, 0x699eb7 <exec_byte_code+5537>, 0x699eae <exec_byte_code+5528>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69a202 <exec_byte_code+6380>, 0x69a321 <exec_byte_code+6667>, 0x69a38b <exec_byte_code+6773>, 0x69a3f6 <exec_byte_code+6880>, 0x69a462 <exec_byte_code+6988>, 0x699151 <exec_byte_code+2107>, 0x6991d6 <exec_byte_code+2240>, 0x69a4e3 <exec_byte_code+7117>, 0x699092 <exec_byte_code+1916>, 0x69923e <exec_byte_code+2344>, 0x69a555 <exec_byte_code+7231>, 0x69a5bd <exec_byte_code+7335>, 0x69a605 <exec_byte_code+7407>, 0x69a66d <exec_byte_code+7511>, 0x69a6bf <exec_byte_code+7593>, 0x69a790 <exec_byte_code+7802>, 0x69a7d8 <exec_byte_code+7874>, 0x69a840 <exec_byte_code+7978>, 0x69a8c5 <exec_byte_code+8111>, 0x69a90d <exec_byte_code+8183>, 0x69a955 <exec_byte_code+8255>, 0x69a9bd <exec_byte_code+8359>, 0x69aa25 <exec_byte_code+8463>, 0x69aa8d <exec_byte_code+8567>, 0x69ab12 <exec_byte_code+8700>, 0x69ab64 <exec_byte_code+8782>, 0x69abb6 <exec_byte_code+8864>, 0x69ac87 <exec_byte_code+9073>, 0x69ad01 <exec_byte_code+9195>, 0x69ad7b <exec_byte_code+9317>, 0x69af47 <exec_byte_code+9777>, 0x69afb4 <exec_byte_code+9886>, 0x69b021 <exec_byte_code+9995>, 0x69b08e <exec_byte_code+10104>, 0x69b0fb <exec_byte_code+10213>, 0x69b14d <exec_byte_code+10295>, 0x69b1cb <exec_byte_code+10421>, 0x69b21d <exec_byte_code+10503>, 0x69b26f <exec_byte_code+10585>, 0x69b2c1 <exec_byte_code+10667>, 0x69b3cd <exec_byte_code+10935>, 0x699d31 <exec_byte_code+5147>, 0x69b42b <exec_byte_code+11029>, 0x69b473 <exec_byte_code+11101>, 0x69b53f <exec_byte_code+11305>, 0x69b5a8 <exec_byte_code+11410>, 0x69b606 <exec_byte_code+11504>, 0x69b64e <exec_byte_code+11576>, 0x69b694 <exec_byte_code+11646>, 0x69b6da <exec_byte_code+11716>, 0x69b728 <exec_byte_code+11794>, 0x69c65f <exec_byte_code+15689>, 0x69b780 <exec_byte_code+11882>, 0x69b7c6 <exec_byte_code+11952>, 0x69b80c <exec_byte_code+12022>, 0x69b852 <exec_byte_code+12092>, 0x69b898 <exec_byte_code+12162>, 0x69b8de <exec_byte_code+12232>, 0x699d31 <exec_byte_code+5147>, 0x69c65f <exec_byte_code+15689>, 0x69b926 <exec_byte_code+12304>, 0x69b97b <exec_byte_code+12389>, 0x69b9c3 <exec_byte_code+12461>, 0x69ba0b <exec_byte_code+12533>, 0x69ba73 <exec_byte_code+12637>, 0x69badb <exec_byte_code+12741>, 0x69bb23 <exec_byte_code+12813>, 0x69bc3d <exec_byte_code+13095>, 0x69bca5 <exec_byte_code+13199>, 0x69bd0d <exec_byte_code+13303>, 0x69bd75 <exec_byte_code+13407>, 0x69bdbb <exec_byte_code+13477>, 0x69c65f <exec_byte_code+15689>, 0x699c65 <exec_byte_code+4943>, 0x699829 <exec_byte_code+3859>, 0x699003 <exec_byte_code+1773>, 0x6998d5 <exec_byte_code+4031>, 0x699956 <exec_byte_code+4160>, 0x6999d4 <exec_byte_code+4286>, 0x699c19 <exec_byte_code+4867>, 0x699c2e <exec_byte_code+4888>, 0x699574 <exec_byte_code+3166>, 0x699ce8 <exec_byte_code+5074>, 0x699d68 <exec_byte_code+5202>, 0x699df6 <exec_byte_code+5344>, 0x699e3f <exec_byte_code+5417>, 0x69a01d <exec_byte_code+5895>, 0x69a09a <exec_byte_code+6020>, 0x69a11f <exec_byte_code+6153>, 0x69a17f <exec_byte_code+6249>, 0x6997db <exec_byte_code+3781>, 0x69be03 <exec_byte_code+13549>, 0x69be88 <exec_byte_code+13682>, 0x69bed0 <exec_byte_code+13754>, 0x69bf18 <exec_byte_code+13826>, 0x69bf60 <exec_byte_code+13898>, 0x69bfa8 <exec_byte_code+13970>, 0x69c010 <exec_byte_code+14074>, 0x69c078 <exec_byte_code+14178>, 0x69c0e0 <exec_byte_code+14282>, 0x69c148 <exec_byte_code+14386>, 0x69c2be <exec_byte_code+14760>, 0x69c326 <exec_byte_code+14864>, 0x69c38e <exec_byte_code+14968>, 0x69c3d6 <exec_byte_code+15040>, 0x69c43e <exec_byte_code+15144>, 0x69c4a6 <exec_byte_code+15248>, 0x69c4ee <exec_byte_code+15320>, 0x69c536 <exec_byte_code+15392>, 0x69b313 <exec_byte_code+10749>, 0x69b365 <exec_byte_code+10831>, 0x69c588 <exec_byte_code+15474>, 0x69c5f4 <exec_byte_code+15582>, 0x69c65f <exec_byte_code+15689>, 0x699a52 <exec_byte_code+4412>, 0x699a6f <exec_byte_code+4441>, 0x699adb <exec_byte_code+4549>, 0x699b47 <exec_byte_code+4657>, 0x699bb0 <exec_byte_code+4762>, 0x69a711 <exec_byte_code+7675>, 0x69ac08 <exec_byte_code+8946>, 0x69b4c0 <exec_byte_code+11178>, 0x69c7f6 <exec_byte_code+16096>, 0x69c86b <exec_byte_code+16213>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c901 <exec_byte_code+16363>, 0x69c988 <exec_byte_code+16498>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69cb9c <exec_byte_code+17030> <repeats 64 times>}
const_length = 7
bytestr_length = 43
vectorp = 0x946880 <pure+1429664>
quitcounter = 1 '\001'
stack_items = 17
sa_avail = 16205
sa_count = 14
sa_must_free = false
stack_base = 0x7fffffffc380
stack_lim = 0x7fffffffc408
top = 0x7fffffffc3e8
void_stack_lim = 0x7fffffffc408
bytestr_data = 0x7fffffffc408 "\301\001!\211@\001A\211@\001A\211@\001A\001\004\006\a\302\303\304\305 !\b\"\002\203#"
pc = 0x7fffffffc423 "\002\203#"
count = 14
result = XIL(0)
#28 0x0000000000644b6f in funcall_lambda (fun=XIL(0x94682d), nargs=1, arg_vector=0x7fffffffc888)
at eval.c:2977
size = 5
val = XIL(0x7fffffffc7e8)
syms_left = make_number(257)
next = XIL(0x1200c0b080)
lexenv = XIL(0x7fffffffc7c0)
count = 14
i = 0
optional = false
rest = false
previous_optional_or_rest = false
#29 0x0000000000643fb9 in Ffuncall (nargs=2, args=0x7fffffffc880) at eval.c:2778
fun = XIL(0x94682d)
original_fun = XIL(0xa39960)
funcar = XIL(0x645e21)
numargs = 1
val = XIL(0x7fffffffc860)
count = 13
#30 0x00000000006996f0 in exec_byte_code
(bytestr=XIL(0x946afc), vector=XIL(0x946b1d), maxdepth=make_number(4), args_template=make_number(257), nargs=1, args=0x7fffffffcd10) at bytecode.c:630
op = 1
type = (unknown: 12114688)
targets =
{0x69c65f <exec_byte_code+15689>, 0x69c684 <exec_byte_code+15726>, 0x69c686 <exec_byte_code+15728>, 0x69c688 <exec_byte_code+15730>, 0x69c68a <exec_byte_code+15732>, 0x69c68a <exec_byte_code+15732>, 0x69c6ef <exec_byte_code+15833>, 0x69c763 <exec_byte_code+15949>, 0x698e2a <exec_byte_code+1300>, 0x698e2c <exec_byte_code+1302>, 0x698e2e <exec_byte_code+1304>, 0x698e30 <exec_byte_code+1306>, 0x698e32 <exec_byte_code+1308>, 0x698e32 <exec_byte_code+1308>, 0x698e38 <exec_byte_code+1314>, 0x698df9 <exec_byte_code+1251>, 0x6992fe <exec_byte_code+2536>, 0x699300 <exec_byte_code+2538>, 0x699302 <exec_byte_code+2540>, 0x699304 <exec_byte_code+2542>, 0x699306 <exec_byte_code+2544>, 0x699306 <exec_byte_code+2544>, 0x69933b <exec_byte_code+2597>, 0x69930c <exec_byte_code+2550>, 0x69960d <exec_byte_code+3319>, 0x69960f <exec_byte_code+3321>, 0x699611 <exec_byte_code+3323>, 0x699613 <exec_byte_code+3325>, 0x699615 <exec_byte_code+3327>, 0x699615 <exec_byte_code+3327>, 0x6995c7 <exec_byte_code+3249>, 0x6995de <exec_byte_code+3272>, 0x6996bd <exec_byte_code+3495>, 0x6996bf <exec_byte_code+3497>, 0x6996c1 <exec_byte_code+3499>, 0x6996c3 <exec_byte_code+3501>, 0x6996c5 <exec_byte_code+3503>, 0x6996c5 <exec_byte_code+3503>, 0x699677 <exec_byte_code+3425>, 0x69968e <exec_byte_code+3448>, 0x699772 <exec_byte_code+3676>, 0x699774 <exec_byte_code+3678>, 0x699776 <exec_byte_code+3680>, 0x699778 <exec_byte_code+3682>, 0x69977a <exec_byte_code+3684>, 0x69977a <exec_byte_code+3684>, 0x69972c <exec_byte_code+3606>, 0x699743 <exec_byte_code+3629>, 0x699fd1 <exec_byte_code+5819>, 0x699eb7 <exec_byte_code+5537>, 0x699eae <exec_byte_code+5528>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69a202 <exec_byte_code+6380>, 0x69a321 <exec_byte_code+6667>, 0x69a38b <exec_byte_code+6773>, 0x69a3f6 <exec_byte_code+6880>, 0x69a462 <exec_byte_code+6988>, 0x699151 <exec_byte_code+2107>, 0x6991d6 <exec_byte_code+2240>, 0x69a4e3 <exec_byte_code+7117>, 0x699092 <exec_byte_code+1916>, 0x69923e <exec_byte_code+2344>, 0x69a555 <exec_byte_code+7231>, 0x69a5bd <exec_byte_code+7335>, 0x69a605 <exec_byte_code+7407>, 0x69a66d <exec_byte_code+7511>, 0x69a6bf <exec_byte_code+7593>, 0x69a790 <exec_byte_code+7802>, 0x69a7d8 <exec_byte_code+7874>, 0x69a840 <exec_byte_code+7978>, 0x69a8c5 <exec_byte_code+8111>, 0x69a90d <exec_byte_code+8183>, 0x69a955 <exec_byte_code+8255>, 0x69a9bd <exec_byte_code+8359>, 0x69aa25 <exec_byte_code+8463>, 0x69aa8d <exec_byte_code+8567>, 0x69ab12 <exec_byte_code+8700>, 0x69ab64 <exec_byte_code+8782>, 0x69abb6 <exec_byte_code+8864>, 0x69ac87 <exec_byte_code+9073>, 0x69ad01 <exec_byte_code+9195>, 0x69ad7b <exec_byte_code+9317>, 0x69af47 <exec_byte_code+9777>, 0x69afb4 <exec_byte_code+9886>, 0x69b021 <exec_byte_code+9995>, 0x69b08e <exec_byte_code+10104>, 0x69b0fb <exec_byte_code+10213>, 0x69b14d <exec_byte_code+10295>, 0x69b1cb <exec_byte_code+10421>, 0x69b21d <exec_byte_code+10503>, 0x69b26f <exec_byte_code+10585>, 0x69b2c1 <exec_byte_code+10667>, 0x69b3cd <exec_byte_code+10935>, 0x699d31 <exec_byte_code+5147>, 0x69b42b <exec_byte_code+11029>, 0x69b473 <exec_byte_code+11101>, 0x69b53f <exec_byte_code+11305>, 0x69b5a8 <exec_byte_code+11410>, 0x69b606 <exec_byte_code+11504>, 0x69b64e <exec_byte_code+11576>, 0x69b694 <exec_byte_code+11646>, 0x69b6da <exec_byte_code+11716>, 0x69b728 <exec_byte_code+11794>, 0x69c65f <exec_byte_code+15689>, 0x69b780 <exec_byte_code+11882>, 0x69b7c6 <exec_byte_code+11952>, 0x69b80c <exec_byte_code+12022>, 0x69b852 <exec_byte_code+12092>, 0x69b898 <exec_byte_code+12162>, 0x69b8de <exec_byte_code+12232>, 0x699d31 <exec_byte_code+5147>, 0x69c65f <exec_byte_code+15689>, 0x69b926 <exec_byte_code+12304>, 0x69b97b <exec_byte_code+12389>, 0x69b9c3 <exec_byte_code+12461>, 0x69ba0b <exec_byte_code+12533>, 0x69ba73 <exec_byte_code+12637>, 0x69badb <exec_byte_code+12741>, 0x69bb23 <exec_byte_code+12813>, 0x69bc3d <exec_byte_code+13095>, 0x69bca5 <exec_byte_code+13199>, 0x69bd0d <exec_byte_code+13303>, 0x69bd75 <exec_byte_code+13407>, 0x69bdbb <exec_byte_code+13477>, 0x69c65f <exec_byte_code+15689>, 0x699c65 <exec_byte_code+4943>, 0x699829 <exec_byte_code+3859>, 0x699003 <exec_byte_code+1773>, 0x6998d5 <exec_byte_code+4031>, 0x699956 <exec_byte_code+4160>, 0x6999d4 <exec_byte_code+4286>, 0x699c19 <exec_byte_code+4867>, 0x699c2e <exec_byte_code+4888>, 0x699574 <exec_byte_code+3166>, 0x699ce8 <exec_byte_code+5074>, 0x699d68 <exec_byte_code+5202>, 0x699df6 <exec_byte_code+5344>, 0x699e3f <exec_byte_code+5417>, 0x69a01d <exec_byte_code+5895>, 0x69a09a <exec_byte_code+6020>, 0x69a11f <exec_byte_code+6153>, 0x69a17f <exec_byte_code+6249>, 0x6997db <exec_byte_code+3781>, 0x69be03 <exec_byte_code+13549>, 0x69be88 <exec_byte_code+13682>, 0x69bed0 <exec_byte_code+13754>, 0x69bf18 <exec_byte_code+13826>, 0x69bf60 <exec_byte_code+13898>, 0x69bfa8 <exec_byte_code+13970>, 0x69c010 <exec_byte_code+14074>, 0x69c078 <exec_byte_code+14178>, 0x69c0e0 <exec_byte_code+14282>, 0x69c148 <exec_byte_code+14386>, 0x69c2be <exec_byte_code+14760>, 0x69c326 <exec_byte_code+14864>, 0x69c38e <exec_byte_code+14968>, 0x69c3d6 <exec_byte_code+15040>, 0x69c43e <exec_byte_code+15144>, 0x69c4a6 <exec_byte_code+15248>, 0x69c4ee <exec_byte_code+15320>, 0x69c536 <exec_byte_code+15392>, 0x69b313 <exec_byte_code+10749>, 0x69b365 <exec_byte_code+10831>, 0x69c588 <exec_byte_code+15474>, 0x69c5f4 <exec_byte_code+15582>, 0x69c65f <exec_byte_code+15689>, 0x699a52 <exec_byte_code+4412>, 0x699a6f <exec_byte_code+4441>, 0x699adb <exec_byte_code+4549>, 0x699b47 <exec_byte_code+4657>, 0x699bb0 <exec_byte_code+4762>, 0x69a711 <exec_byte_code+7675>, 0x69ac08 <exec_byte_code+8946>, 0x69b4c0 <exec_byte_code+11178>, 0x69c7f6 <exec_byte_code+16096>, 0x69c86b <exec_byte_code+16213>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c901 <exec_byte_code+16363>, 0x69c988 <exec_byte_code+16498>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69cb9c <exec_byte_code+17030> <repeats 64 times>}
const_length = 4
bytestr_length = 29
vectorp = 0x946b20 <pure+1430336>
quitcounter = 1 '\001'
stack_items = 5
sa_avail = 16315
sa_count = 12
sa_must_free = false
stack_base = 0x7fffffffc870
stack_lim = 0x7fffffffc898
top = 0x7fffffffc880
void_stack_lim = 0x7fffffffc898
bytestr_data = 0x7fffffffc898 "\b\204\b"
pc = 0x7fffffffc8a5 "\n)B\211A\t=\204\032"
count = 12
result = XIL(0x7fffffffcb30)
#31 0x0000000000644b6f in funcall_lambda (fun=XIL(0x946abd), nargs=1, arg_vector=0x7fffffffcd08)
at eval.c:2977
size = 6
val = XIL(0x7fffffffcc68)
syms_left = make_number(257)
next = XIL(0x1200c0b080)
lexenv = make_number(1440909)
count = 12
i = 0
optional = false
rest = false
previous_optional_or_rest = false
#32 0x0000000000643fb9 in Ffuncall (nargs=2, args=0x7fffffffcd00) at eval.c:2778
fun = XIL(0x946abd)
original_fun = XIL(0x4dd0a0)
funcar = XIL(0xc0b080)
numargs = 1
val = XIL(0xc2a0)
count = 11
#33 0x00000000006996f0 in exec_byte_code
(bytestr=XIL(0x94601c), vector=XIL(0x94603d), maxdepth=make_number(3), args_template=make_number(256), nargs=1, args=0x7fffffffd2a8) at bytecode.c:630
op = 1
type = (unknown: 12133568)
targets =
{0x69c65f <exec_byte_code+15689>, 0x69c684 <exec_byte_code+15726>, 0x69c686 <exec_byte_code+15728>, 0x69c688 <exec_byte_code+15730>, 0x69c68a <exec_byte_code+15732>, 0x69c68a <exec_byte_code+15732>, 0x69c6ef <exec_byte_code+15833>, 0x69c763 <exec_byte_code+15949>, 0x698e2a <exec_byte_code+1300>, 0x698e2c <exec_byte_code+1302>, 0x698e2e <exec_byte_code+1304>, 0x698e30 <exec_byte_code+1306>, 0x698e32 <exec_byte_code+1308>, 0x698e32 <exec_byte_code+1308>, 0x698e38 <exec_byte_code+1314>, 0x698df9 <exec_byte_code+1251>, 0x6992fe <exec_byte_code+2536>, 0x699300 <exec_byte_code+2538>, 0x699302 <exec_byte_code+2540>, 0x699304 <exec_byte_code+2542>, 0x699306 <exec_byte_code+2544>, 0x699306 <exec_byte_code+2544>, 0x69933b <exec_byte_code+2597>, 0x69930c <exec_byte_code+2550>, 0x69960d <exec_byte_code+3319>, 0x69960f <exec_byte_code+3321>, 0x699611 <exec_byte_code+3323>, 0x699613 <exec_byte_code+3325>, 0x699615 <exec_byte_code+3327>, 0x699615 <exec_byte_code+3327>, 0x6995c7 <exec_byte_code+3249>, 0x6995de <exec_byte_code+3272>, 0x6996bd <exec_byte_code+3495>, 0x6996bf <exec_byte_code+3497>, 0x6996c1 <exec_byte_code+3499>, 0x6996c3 <exec_byte_code+3501>, 0x6996c5 <exec_byte_code+3503>, 0x6996c5 <exec_byte_code+3503>, 0x699677 <exec_byte_code+3425>, 0x69968e <exec_byte_code+3448>, 0x699772 <exec_byte_code+3676>, 0x699774 <exec_byte_code+3678>, 0x699776 <exec_byte_code+3680>, 0x699778 <exec_byte_code+3682>, 0x69977a <exec_byte_code+3684>, 0x69977a <exec_byte_code+3684>, 0x69972c <exec_byte_code+3606>, 0x699743 <exec_byte_code+3629>, 0x699fd1 <exec_byte_code+5819>, 0x699eb7 <exec_byte_code+5537>, 0x699eae <exec_byte_code+5528>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69a202 <exec_byte_code+6380>, 0x69a321 <exec_byte_code+6667>, 0x69a38b <exec_byte_code+6773>, 0x69a3f6 <exec_byte_code+6880>, 0x69a462 <exec_byte_code+6988>, 0x699151 <exec_byte_code+2107>, 0x6991d6 <exec_byte_code+2240>, 0x69a4e3 <exec_byte_code+7117>, 0x699092 <exec_byte_code+1916>, 0x69923e <exec_byte_code+2344>, 0x69a555 <exec_byte_code+7231>, 0x69a5bd <exec_byte_code+7335>, 0x69a605 <exec_byte_code+7407>, 0x69a66d <exec_byte_code+7511>, 0x69a6bf <exec_byte_code+7593>, 0x69a790 <exec_byte_code+7802>, 0x69a7d8 <exec_byte_code+7874>, 0x69a840 <exec_byte_code+7978>, 0x69a8c5 <exec_byte_code+8111>, 0x69a90d <exec_byte_code+8183>, 0x69a955 <exec_byte_code+8255>, 0x69a9bd <exec_byte_code+8359>, 0x69aa25 <exec_byte_code+8463>, 0x69aa8d <exec_byte_code+8567>, 0x69ab12 <exec_byte_code+8700>, 0x69ab64 <exec_byte_code+8782>, 0x69abb6 <exec_byte_code+8864>, 0x69ac87 <exec_byte_code+9073>, 0x69ad01 <exec_byte_code+9195>, 0x69ad7b <exec_byte_code+9317>, 0x69af47 <exec_byte_code+9777>, 0x69afb4 <exec_byte_code+9886>, 0x69b021 <exec_byte_code+9995>, 0x69b08e <exec_byte_code+10104>, 0x69b0fb <exec_byte_code+10213>, 0x69b14d <exec_byte_code+10295>, 0x69b1cb <exec_byte_code+10421>, 0x69b21d <exec_byte_code+10503>, 0x69b26f <exec_byte_code+10585>, 0x69b2c1 <exec_byte_code+10667>, 0x69b3cd <exec_byte_code+10935>, 0x699d31 <exec_byte_code+5147>, 0x69b42b <exec_byte_code+11029>, 0x69b473 <exec_byte_code+11101>, 0x69b53f <exec_byte_code+11305>, 0x69b5a8 <exec_byte_code+11410>, 0x69b606 <exec_byte_code+11504>, 0x69b64e <exec_byte_code+11576>, 0x69b694 <exec_byte_code+11646>, 0x69b6da <exec_byte_code+11716>, 0x69b728 <exec_byte_code+11794>, 0x69c65f <exec_byte_code+15689>, 0x69b780 <exec_byte_code+11882>, 0x69b7c6 <exec_byte_code+11952>, 0x69b80c <exec_byte_code+12022>, 0x69b852 <exec_byte_code+12092>, 0x69b898 <exec_byte_code+12162>, 0x69b8de <exec_byte_code+12232>, 0x699d31 <exec_byte_code+5147>, 0x69c65f <exec_byte_code+15689>, 0x69b926 <exec_byte_code+12304>, 0x69b97b <exec_byte_code+12389>, 0x69b9c3 <exec_byte_code+12461>, 0x69ba0b <exec_byte_code+12533>, 0x69ba73 <exec_byte_code+12637>, 0x69badb <exec_byte_code+12741>, 0x69bb23 <exec_byte_code+12813>, 0x69bc3d <exec_byte_code+13095>, 0x69bca5 <exec_byte_code+13199>, 0x69bd0d <exec_byte_code+13303>, 0x69bd75 <exec_byte_code+13407>, 0x69bdbb <exec_byte_code+13477>, 0x69c65f <exec_byte_code+15689>, 0x699c65 <exec_byte_code+4943>, 0x699829 <exec_byte_code+3859>, 0x699003 <exec_byte_code+1773>, 0x6998d5 <exec_byte_code+4031>, 0x699956 <exec_byte_code+4160>, 0x6999d4 <exec_byte_code+4286>, 0x699c19 <exec_byte_code+4867>, 0x699c2e <exec_byte_code+4888>, 0x699574 <exec_byte_code+3166>, 0x699ce8 <exec_byte_code+5074>, 0x699d68 <exec_byte_code+5202>, 0x699df6 <exec_byte_code+5344>, 0x699e3f <exec_byte_code+5417>, 0x69a01d <exec_byte_code+5895>, 0x69a09a <exec_byte_code+6020>, 0x69a11f <exec_byte_code+6153>, 0x69a17f <exec_byte_code+6249>, 0x6997db <exec_byte_code+3781>, 0x69be03 <exec_byte_code+13549>, 0x69be88 <exec_byte_code+13682>, 0x69bed0 <exec_byte_code+13754>, 0x69bf18 <exec_byte_code+13826>, 0x69bf60 <exec_byte_code+13898>, 0x69bfa8 <exec_byte_code+13970>, 0x69c010 <exec_byte_code+14074>, 0x69c078 <exec_byte_code+14178>, 0x69c0e0 <exec_byte_code+14282>, 0x69c148 <exec_byte_code+14386>, 0x69c2be <exec_byte_code+14760>, 0x69c326 <exec_byte_code+14864>, 0x69c38e <exec_byte_code+14968>, 0x69c3d6 <exec_byte_code+15040>, 0x69c43e <exec_byte_code+15144>, 0x69c4a6 <exec_byte_code+15248>, 0x69c4ee <exec_byte_code+15320>, 0x69c536 <exec_byte_code+15392>, 0x69b313 <exec_byte_code+10749>, 0x69b365 <exec_byte_code+10831>, 0x69c588 <exec_byte_code+15474>, 0x69c5f4 <exec_byte_code+15582>, 0x69c65f <exec_byte_code+15689>, 0x699a52 <exec_byte_code+4412>, 0x699a6f <exec_byte_code+4441>, 0x699adb <exec_byte_code+4549>, 0x699b47 <exec_byte_code+4657>, 0x699bb0 <exec_byte_code+4762>, 0x69a711 <exec_byte_code+7675>, 0x69ac08 <exec_byte_code+8946>, 0x69b4c0 <exec_byte_code+11178>, 0x69c7f6 <exec_byte_code+16096>, 0x69c86b <exec_byte_code+16213>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c901 <exec_byte_code+16363>, 0x69c988 <exec_byte_code+16498>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69cb9c <exec_byte_code+17030> <repeats 64 times>}
const_length = 4
bytestr_length = 17
vectorp = 0x946040 <pure+1427552>
quitcounter = 1 '\001'
stack_items = 4
sa_avail = 16335
sa_count = 10
sa_must_free = false
stack_base = 0x7fffffffccf0
stack_lim = 0x7fffffffcd10
top = 0x7fffffffcd00
void_stack_lim = 0x7fffffffcd10
bytestr_data = 0x7fffffffcd10 "p\030\301 \210\302\001\206\v"
pc = 0x7fffffffcd1c "\210\301 )\207\320\377\377\377\177"
count = 10
result = XIL(0x2fc92d3)
#34 0x0000000000644b6f in funcall_lambda (fun=XIL(0x945fdd), nargs=1, arg_vector=0x7fffffffd2a0)
at eval.c:2977
size = 6
val = XIL(0x7fffffffd0d8)
syms_left = make_number(256)
next = XIL(0x1200c0b080)
lexenv = XIL(0x7fffffffd0b0)
count = 10
i = 0
optional = false
rest = false
previous_optional_or_rest = false
#35 0x0000000000643fb9 in Ffuncall (nargs=2, args=0x7fffffffd298) at eval.c:2778
fun = XIL(0x945fdd)
original_fun = XIL(0xa39590)
funcar = XIL(0x589371)
numargs = 1
val = XIL(0)
count = 9
#36 0x0000000000639907 in Ffuncall_interactively (nargs=2, args=0x7fffffffd298) at callint.c:252
speccount = 8
#37 0x0000000000644337 in funcall_subr
(subr=0xb90a00 <Sfuncall_interactively>, numargs=2, args=0x7fffffffd298) at eval.c:2831
#38 0x0000000000643f75 in Ffuncall (nargs=3, args=0x7fffffffd290) at eval.c:2776
fun = XIL(0xb90a05)
original_fun = XIL(0x66c0)
funcar = XIL(0x645e21)
numargs = 2
val = XIL(0x7fffffffd280)
count = 7
#39 0x000000000063bde9 in Fcall_interactively
(function=XIL(0xa39590), record_flag=XIL(0), keys=XIL(0xca3695)) at callint.c:854
val = XIL(0)
args = 0x7fffffffd290
visargs = 0x7fffffffd2a8
specs = XIL(0x80fa7c)
filter_specs = XIL(0x80fa7c)
teml = XIL(0x7fffffffd108)
up_event = XIL(0)
enable = XIL(0)
sa_avail = 16310
sa_count = 6
sa_must_free = false
speccount = 6
next_event = 1
prefix_arg = XIL(0)
string = 0x7fffffffd2e0 "P"
tem = 0x77842b ""
varies = 0x7fffffffd2c0 ""
i = 3
nargs = 3
mark = 5760715
arg_from_tty = false
key_count = 1
record_then_fail = false
save_this_command = XIL(0xa39590)
save_last_command = XIL(0x4628d0)
save_this_original_command = XIL(0xa39590)
save_real_this_command = XIL(0xa39590)
#40 0x0000000000644490 in funcall_subr
(subr=0xb90a40 <Scall_interactively>, numargs=3, args=0x7fffffffd610) at eval.c:2856
internal_argbuf =
{XIL(0xb90a40), XIL(0x7fffffffd528), make_number(1440909), XIL(0xa00c0b080), XIL(0xb90a45), XIL(0x7fffffffd548), XIL(0xb90a40), XIL(0x7fffffffd540)}
internal_args = 0x7fffffffd610
#41 0x0000000000643f75 in Ffuncall (nargs=4, args=0x7fffffffd608) at eval.c:2776
fun = XIL(0xb90a45)
original_fun = XIL(0xb1b80)
funcar = XIL(0xc0b080)
numargs = 3
val = XIL(0)
count = 5
#42 0x00000000006996f0 in exec_byte_code
(bytestr=XIL(0x8aea5c), vector=XIL(0x8aea7d), maxdepth=make_number(13), args_template=make_number(1025), nargs=1, args=0x7fffffffdb40) at bytecode.c:630
op = 3
type = CATCHER
targets =
{0x69c65f <exec_byte_code+15689>, 0x69c684 <exec_byte_code+15726>, 0x69c686 <exec_byte_code+15728>, 0x69c688 <exec_byte_code+15730>, 0x69c68a <exec_byte_code+15732>, 0x69c68a <exec_byte_code+15732>, 0x69c6ef <exec_byte_code+15833>, 0x69c763 <exec_byte_code+15949>, 0x698e2a <exec_byte_code+1300>, 0x698e2c <exec_byte_code+1302>, 0x698e2e <exec_byte_code+1304>, 0x698e30 <exec_byte_code+1306>, 0x698e32 <exec_byte_code+1308>, 0x698e32 <exec_byte_code+1308>, 0x698e38 <exec_byte_code+1314>, 0x698df9 <exec_byte_code+1251>, 0x6992fe <exec_byte_code+2536>, 0x699300 <exec_byte_code+2538>, 0x699302 <exec_byte_code+2540>, 0x699304 <exec_byte_code+2542>, 0x699306 <exec_byte_code+2544>, 0x699306 <exec_byte_code+2544>, 0x69933b <exec_byte_code+2597>, 0x69930c <exec_byte_code+2550>, 0x69960d <exec_byte_code+3319>, 0x69960f <exec_byte_code+3321>, 0x699611 <exec_byte_code+3323>, 0x699613 <exec_byte_code+3325>, 0x699615 <exec_byte_code+3327>, 0x699615 <exec_byte_code+3327>, 0x6995c7 <exec_byte_code+3249>, 0x6995de <exec_byte_code+3272>, 0x6996bd <exec_byte_code+3495>, 0x6996bf <exec_byte_code+3497>, 0x6996c1 <exec_byte_code+3499>, 0x6996c3 <exec_byte_code+3501>, 0x6996c5 <exec_byte_code+3503>, 0x6996c5 <exec_byte_code+3503>, 0x699677 <exec_byte_code+3425>, 0x69968e <exec_byte_code+3448>, 0x699772 <exec_byte_code+3676>, 0x699774 <exec_byte_code+3678>, 0x699776 <exec_byte_code+3680>, 0x699778 <exec_byte_code+3682>, 0x69977a <exec_byte_code+3684>, 0x69977a <exec_byte_code+3684>, 0x69972c <exec_byte_code+3606>, 0x699743 <exec_byte_code+3629>, 0x699fd1 <exec_byte_code+5819>, 0x699eb7 <exec_byte_code+5537>, 0x699eae <exec_byte_code+5528>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69a202 <exec_byte_code+6380>, 0x69a321 <exec_byte_code+6667>, 0x69a38b <exec_byte_code+6773>, 0x69a3f6 <exec_byte_code+6880>, 0x69a462 <exec_byte_code+6988>, 0x699151 <exec_byte_code+2107>, 0x6991d6 <exec_byte_code+2240>, 0x69a4e3 <exec_byte_code+7117>, 0x699092 <exec_byte_code+1916>, 0x69923e <exec_byte_code+2344>, 0x69a555 <exec_byte_code+7231>, 0x69a5bd <exec_byte_code+7335>, 0x69a605 <exec_byte_code+7407>, 0x69a66d <exec_byte_code+7511>, 0x69a6bf <exec_byte_code+7593>, 0x69a790 <exec_byte_code+7802>, 0x69a7d8 <exec_byte_code+7874>, 0x69a840 <exec_byte_code+7978>, 0x69a8c5 <exec_byte_code+8111>, 0x69a90d <exec_byte_code+8183>, 0x69a955 <exec_byte_code+8255>, 0x69a9bd <exec_byte_code+8359>, 0x69aa25 <exec_byte_code+8463>, 0x69aa8d <exec_byte_code+8567>, 0x69ab12 <exec_byte_code+8700>, 0x69ab64 <exec_byte_code+8782>, 0x69abb6 <exec_byte_code+8864>, 0x69ac87 <exec_byte_code+9073>, 0x69ad01 <exec_byte_code+9195>, 0x69ad7b <exec_byte_code+9317>, 0x69af47 <exec_byte_code+9777>, 0x69afb4 <exec_byte_code+9886>, 0x69b021 <exec_byte_code+9995>, 0x69b08e <exec_byte_code+10104>, 0x69b0fb <exec_byte_code+10213>, 0x69b14d <exec_byte_code+10295>, 0x69b1cb <exec_byte_code+10421>, 0x69b21d <exec_byte_code+10503>, 0x69b26f <exec_byte_code+10585>, 0x69b2c1 <exec_byte_code+10667>, 0x69b3cd <exec_byte_code+10935>, 0x699d31 <exec_byte_code+5147>, 0x69b42b <exec_byte_code+11029>, 0x69b473 <exec_byte_code+11101>, 0x69b53f <exec_byte_code+11305>, 0x69b5a8 <exec_byte_code+11410>, 0x69b606 <exec_byte_code+11504>, 0x69b64e <exec_byte_code+11576>, 0x69b694 <exec_byte_code+11646>, 0x69b6da <exec_byte_code+11716>, 0x69b728 <exec_byte_code+11794>, 0x69c65f <exec_byte_code+15689>, 0x69b780 <exec_byte_code+11882>, 0x69b7c6 <exec_byte_code+11952>, 0x69b80c <exec_byte_code+12022>, 0x69b852 <exec_byte_code+12092>, 0x69b898 <exec_byte_code+12162>, 0x69b8de <exec_byte_code+12232>, 0x699d31 <exec_byte_code+5147>, 0x69c65f <exec_byte_code+15689>, 0x69b926 <exec_byte_code+12304>, 0x69b97b <exec_byte_code+12389>, 0x69b9c3 <exec_byte_code+12461>, 0x69ba0b <exec_byte_code+12533>, 0x69ba73 <exec_byte_code+12637>, 0x69badb <exec_byte_code+12741>, 0x69bb23 <exec_byte_code+12813>, 0x69bc3d <exec_byte_code+13095>, 0x69bca5 <exec_byte_code+13199>, 0x69bd0d <exec_byte_code+13303>, 0x69bd75 <exec_byte_code+13407>, 0x69bdbb <exec_byte_code+13477>, 0x69c65f <exec_byte_code+15689>, 0x699c65 <exec_byte_code+4943>, 0x699829 <exec_byte_code+3859>, 0x699003 <exec_byte_code+1773>, 0x6998d5 <exec_byte_code+4031>, 0x699956 <exec_byte_code+4160>, 0x6999d4 <exec_byte_code+4286>, 0x699c19 <exec_byte_code+4867>, 0x699c2e <exec_byte_code+4888>, 0x699574 <exec_byte_code+3166>, 0x699ce8 <exec_byte_code+5074>, 0x699d68 <exec_byte_code+5202>, 0x699df6 <exec_byte_code+5344>, 0x699e3f <exec_byte_code+5417>, 0x69a01d <exec_byte_code+5895>, 0x69a09a <exec_byte_code+6020>, 0x69a11f <exec_byte_code+6153>, 0x69a17f <exec_byte_code+6249>, 0x6997db <exec_byte_code+3781>, 0x69be03 <exec_byte_code+13549>, 0x69be88 <exec_byte_code+13682>, 0x69bed0 <exec_byte_code+13754>, 0x69bf18 <exec_byte_code+13826>, 0x69bf60 <exec_byte_code+13898>, 0x69bfa8 <exec_byte_code+13970>, 0x69c010 <exec_byte_code+14074>, 0x69c078 <exec_byte_code+14178>, 0x69c0e0 <exec_byte_code+14282>, 0x69c148 <exec_byte_code+14386>, 0x69c2be <exec_byte_code+14760>, 0x69c326 <exec_byte_code+14864>, 0x69c38e <exec_byte_code+14968>, 0x69c3d6 <exec_byte_code+15040>, 0x69c43e <exec_byte_code+15144>, 0x69c4a6 <exec_byte_code+15248>, 0x69c4ee <exec_byte_code+15320>, 0x69c536 <exec_byte_code+15392>, 0x69b313 <exec_byte_code+10749>, 0x69b365 <exec_byte_code+10831>, 0x69c588 <exec_byte_code+15474>, 0x69c5f4 <exec_byte_code+15582>, 0x69c65f <exec_byte_code+15689>, 0x699a52 <exec_byte_code+4412>, 0x699a6f <exec_byte_code+4441>, 0x699adb <exec_byte_code+4549>, 0x699b47 <exec_byte_code+4657>, 0x699bb0 <exec_byte_code+4762>, 0x69a711 <exec_byte_code+7675>, 0x69ac08 <exec_byte_code+8946>, 0x69b4c0 <exec_byte_code+11178>, 0x69c7f6 <exec_byte_code+16096>, 0x69c86b <exec_byte_code+16213>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c901 <exec_byte_code+16363>, 0x69c988 <exec_byte_code+16498>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69c65f <exec_byte_code+15689>, 0x69cb9c <exec_byte_code+17030> <repeats 64 times>}
const_length = 25
bytestr_length = 165
vectorp = 0x8aea80 <pure+807584>
quitcounter = 1 '\001'
stack_items = 14
sa_avail = 16107
sa_count = 5
sa_must_free = false
stack_base = 0x7fffffffd5d0
stack_lim = 0x7fffffffd640
top = 0x7fffffffd608
void_stack_lim = 0x7fffffffd640
bytestr_data = 0x7fffffffd640 "\306\020\211?\205\023"
pc = 0x7fffffffd6bb "\006\006\071\203\242"
count = 5
result = XIL(0)
#43 0x0000000000644b6f in funcall_lambda (fun=XIL(0x8aea2d), nargs=1, arg_vector=0x7fffffffdb38)
at eval.c:2977
size = 5
val = XIL(0x7fffffffda98)
syms_left = make_number(1025)
next = XIL(0x1200c0b080)
lexenv = make_number(34910567923712)
count = 5
i = 0
optional = false
rest = false
previous_optional_or_rest = false
#44 0x0000000000643fb9 in Ffuncall (nargs=2, args=0x7fffffffdb30) at eval.c:2778
fun = XIL(0x8aea2d)
original_fun = XIL(0x3f30)
funcar = XIL(0x1)
numargs = 1
val = XIL(0x7fffffffdb38)
count = 4
#45 0x0000000000643891 in call1 (fn=XIL(0x3f30), arg1=XIL(0xa39590)) at eval.c:2627
#46 0x000000000058a56b in command_loop_1 () at keyboard.c:1482
scount = 3
cmd = XIL(0xa39590)
keybuf =
{make_number(10), XIL(0x2012e48b3), XIL(0), XIL(0x7a10), XIL(0x10000010f), XIL(0), XIL(0xc0a7a0), XIL(0x7a10), make_number(55834574852), XIL(0xc12a90), XIL(0x7fffffffdbc0), XIL(0), XIL(0x7fffffffdc00), make_number(1644723), make_number(34910567923712), XIL(0xc0b080), XIL(0x580b87), XIL(0), XIL(0x7fffffffdc00), XIL(0x57e6cb), XIL(0), XIL(0xc0b080), XIL(0x7fffffffdc60), XIL(0), XIL(0x7fffffffdc30), XIL(0x57e6cb), XIL(0x5), XIL(0x7a10), XIL(0x7fffffffdc70), XIL(0x640415)}
i = 1
prev_modiff = 182
prev_buffer = 0xc9e400 <bss_sbrk_buffer+455584>
already_adjusted = false
#47 0x000000000063fffe in internal_condition_case
(bfun=0x589d5b <command_loop_1>, handlers=XIL(0x5280), hfun=0x5893bf <cmd_error>) at eval.c:1336
val = XIL(0x57e6cb)
c = 0x2c80280
#48 0x0000000000589971 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1110
val = XIL(0xc900)
#49 0x000000000063f4fd in internal_catch (tag=XIL(0xc900), func=0x589944 <command_loop_2>, arg=XIL(0))
at eval.c:1101
val = XIL(0)
c = 0x2c80160
#50 0x000000000058990f in command_loop () at keyboard.c:1089
#51 0x0000000000588ea8 in recursive_edit_1 () at keyboard.c:695
count = 1
val = XIL(0x7fffffffdde0)
#52 0x000000000058909d in Frecursive_edit () at keyboard.c:766
count = 0
buffer = XIL(0)
#53 0x0000000000586c3c in main (argc=3, argv=0x7fffffffe028) at emacs.c:1717
stack_bottom_variable = 0x2c6c290
do_initial_setlocale = true
dumping = false
skip_args = 1
no_loadup = false
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x0
original_pwd = 0x0
disable_aslr = false
rlim = {
rlim_cur = 10022912,
rlim_max = 18446744073709551615
}
sockfd = -1
module_assertions = true
Lisp Backtrace:
"file-name-as-directory" (0xffffb7c8)
"realpath-truename" (0xffffbb70)
"while" (0xffffbe50)
"let" (0xffffc070)
"progn" (0xffffc1c0)
"eval" (0xffffc3f0)
"elisp--eval-last-sexp" (0xffffc888)
"eval-last-sexp" (0xffffcd08)
"eval-print-last-sexp" (0xffffd2a0)
"funcall-interactively" (0xffffd298)
"call-interactively" (0xffffd610)
"command-execute" (0xffffdb38)
[-- Attachment #2: Type: text/plain, Size: 1968 bytes --]
I have written a dynamic module which provides a function
realpath-truename similar to file-truename, but which uses
canonicalize_file_name(3) internally and which doesn't respect file name
handlers. It is hosted at the following URL:
https://gitlab.com/basil-conto/realpath
Repeatedly calling realpath-truename on a directory name in an Emacs
started with --module-assertions segfaults in a call to
file-name-as-directory. The precise recipe I am using is the following:
0. git clone https://gitlab.com/basil-conto/realpath.git
1. cd realpath
2. make
3. cd /path/to/emacs/src
4. gdb emacs
5. set logging on
6. run -Q --module-assertions
7. (progn (module-load "/path/to/realpath.so")
(dotimes (_ 1000)
(realpath-truename user-emacs-directory)))
C-j
9. bt full
I attach the corresponding GDB log.
I am not confident that the module is written properly, in particular
w.r.t. nonlocal exits, but I don't see what, if anything, I am doing
wrong, so any help would be greatly appreciated.
Thanks,
--
Basil
In GNU Emacs 26.1.92 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2019-02-25 built on thunk
Repository revision: 1dff09739346037a588a3b9290800c09a9b3409a
Windowing system distributor 'The X.Org Foundation', version 11.0.12003000
System Description: Debian GNU/Linux buster/sid
Configured using:
'configure 'CC=ccache gcc' 'CFLAGS=-O0 -g3 -ggdb -gdwarf-4 -pipe'
--config-cache --prefix=/home/blc/.local --program-suffix=26
--enable-checking=yes,glyphs --enable-check-lisp-object-type
--with-mailutils --with-x-toolkit=lucid --with-modules
--with-file-notification=yes --with-x'
Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS
GLIB NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT
ZLIB TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM MODULES THREADS LIBSYSTEMD
LCMS2
Important settings:
value of $LANG: en_IE.UTF-8
locale-coding-system: utf-8-unix
^ permalink raw reply [flat|nested] 32+ messages in thread* bug#34655: 26.1.92; Segfault in module with --module-assertions 2019-02-25 21:00 bug#34655: 26.1.92; Segfault in module with --module-assertions Basil L. Contovounesios @ 2019-02-26 2:59 ` Richard Stallman 2019-02-26 11:16 ` Basil L. Contovounesios 2019-02-26 15:45 ` Eli Zaretskii 1 sibling, 1 reply; 32+ messages in thread From: Richard Stallman @ 2019-02-26 2:59 UTC (permalink / raw) To: Basil L. Contovounesios; +Cc: 34655 [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > I have written a dynamic module which provides a function > realpath-truename The function might be useful, but that is not the right name for it. In the GNU system we do not use "path" to mean a file name. Could you describe in words what job the function does? Then I could suggest a name. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#34655: 26.1.92; Segfault in module with --module-assertions 2019-02-26 2:59 ` Richard Stallman @ 2019-02-26 11:16 ` Basil L. Contovounesios 2019-02-26 15:27 ` Eli Zaretskii 2019-02-27 4:10 ` Richard Stallman 0 siblings, 2 replies; 32+ messages in thread From: Basil L. Contovounesios @ 2019-02-26 11:16 UTC (permalink / raw) To: Richard Stallman; +Cc: 34655 Richard Stallman <rms@gnu.org> writes: > > I have written a dynamic module which provides a function > > realpath-truename > > The function might be useful, but that is not the right name for it. > In the GNU system we do not use "path" to mean a file name. Thanks, I am aware of this. See below for how the name came to be. > Could you describe in words what job the function does? > Then I could suggest a name. Thanks, but just to clarify: I have not written this module with the intention of advertising it for others to use; I don't think anyone would find it of great use. I was motivated to write it to test Emacs' new (at the time) module system, and because, with enough packages installed, file-truename slowed down package-initialize (and thus my emacs-init-time) by a non-negligible amount. I thus overrode file-truename with realpath-truename using advice, with the caveat that realpath-truename does not respect file name handlers (in practice I never needed this). The new package-quickstart feature has made the module largely unnecessary. Either way, I regard it as a personal experiment. Re: the name, I chose 'realpath' because the original implementation was just that: a wrapper around realpath(3). It was only in a later version that I switched to using canonicalize_file_name(3) instead. Perhaps a better name would have been 'truename' or similar, but I don't think this is important enough a matter to justify renaming it now. Do you? The reason I submitted this bug report is because I don't know whether the switch --module-assertions has unveiled an issue in my module or Emacs' module implementation. -- Basil ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#34655: 26.1.92; Segfault in module with --module-assertions 2019-02-26 11:16 ` Basil L. Contovounesios @ 2019-02-26 15:27 ` Eli Zaretskii 2019-02-26 18:42 ` Basil L. Contovounesios 2019-02-27 4:10 ` Richard Stallman 1 sibling, 1 reply; 32+ messages in thread From: Eli Zaretskii @ 2019-02-26 15:27 UTC (permalink / raw) To: Basil L. Contovounesios; +Cc: 34655, rms > From: "Basil L. Contovounesios" <contovob@tcd.ie> > Date: Tue, 26 Feb 2019 11:16:56 +0000 > Cc: 34655@debbugs.gnu.org > > The reason I submitted this bug report is because I don't know whether > the switch --module-assertions has unveiled an issue in my module or > Emacs' module implementation. So without using --module-assertions the crash doesn't happen, is that what you are saying? ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#34655: 26.1.92; Segfault in module with --module-assertions 2019-02-26 15:27 ` Eli Zaretskii @ 2019-02-26 18:42 ` Basil L. Contovounesios 0 siblings, 0 replies; 32+ messages in thread From: Basil L. Contovounesios @ 2019-02-26 18:42 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 34655, rms Eli Zaretskii <eliz@gnu.org> writes: >> From: "Basil L. Contovounesios" <contovob@tcd.ie> >> Date: Tue, 26 Feb 2019 11:16:56 +0000 >> Cc: 34655@debbugs.gnu.org >> >> The reason I submitted this bug report is because I don't know whether >> the switch --module-assertions has unveiled an issue in my module or >> Emacs' module implementation. > > So without using --module-assertions the crash doesn't happen, is that > what you are saying? Yes. I can't guarantee the crash doesn't happen without --module-assertions of course, but in my tests it only seems to crop up with the switch (and reliably so). -- Basil ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#34655: 26.1.92; Segfault in module with --module-assertions 2019-02-26 11:16 ` Basil L. Contovounesios 2019-02-26 15:27 ` Eli Zaretskii @ 2019-02-27 4:10 ` Richard Stallman 1 sibling, 0 replies; 32+ messages in thread From: Richard Stallman @ 2019-02-27 4:10 UTC (permalink / raw) To: Basil L. Contovounesios; +Cc: 34655 [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Re: the name, I chose 'realpath' because the original implementation was > just that: a wrapper around realpath(3). It was only in a later version > that I switched to using canonicalize_file_name(3) instead. Perhaps a > better name would have been 'truename' or similar, but I don't think > this is important enough a matter to justify renaming it now. Do you? If you don't think it is worth publicizing, and you don't really want to use it, I won't claim that minor fixes in it are important. A good name might be nonmagic-file-truename -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#34655: 26.1.92; Segfault in module with --module-assertions 2019-02-25 21:00 bug#34655: 26.1.92; Segfault in module with --module-assertions Basil L. Contovounesios 2019-02-26 2:59 ` Richard Stallman @ 2019-02-26 15:45 ` Eli Zaretskii 2019-03-17 16:38 ` Basil L. Contovounesios 1 sibling, 1 reply; 32+ messages in thread From: Eli Zaretskii @ 2019-02-26 15:45 UTC (permalink / raw) To: Basil L. Contovounesios; +Cc: 34655 > From: "Basil L. Contovounesios" <contovob@tcd.ie> > Date: Mon, 25 Feb 2019 21:00:41 +0000 > > Starting program: /home/blc/.local/src/emacs26/src/emacs -Q --module-assertions > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > [New Thread 0x7ffff01cb700 (LWP 8299)] > [New Thread 0x7fffef9ac700 (LWP 8300)] > [New Thread 0x7fffef1ab700 (LWP 8301)] > > Thread 1 "emacs" received signal SIGSEGV, Segmentation fault. > re_search_2 (bufp=0xbf5d00 <searchbufs+384>, str1=0x0, size1=0, str2=0x0, size2=18, startpos=0, > range=18, regs=0x0, stop=18) at regex.c:4354 > 4354 buf_ch = STRING_CHAR_AND_LENGTH (d, buf_charlen); > #0 0x0000000000608594 in re_search_2 > (bufp=0xbf5d00 <searchbufs+384>, str1=0x0, size1=0, str2=0x0, size2=18, startpos=0, range=18, regs=0x0, stop=18) at regex.c:4354 > buf_charlen = 0 > irange = 18 > lim = 0 > d = 0x0 > buf_ch = 18 > val = 691541629 > string1 = 0x0 > string2 = 0x0 > fastmap = 0xbf5d38 <searchbufs+440> "" > translate = make_number(0) > total_size = 18 > endpos = 18 > anchored_start = 0 '\000' > multibyte = 1 '\001' > #1 0x0000000000607f91 in re_search > (bufp=0xbf5d00 <searchbufs+384>, string=0x0, size=18, startpos=0, range=18, regs=0x0) > at regex.c:4181 > #2 0x00000000005f3fd0 in fast_string_match_internal > (regexp=XIL(0x8c761c), string=XIL(0x3036ec4), table=XIL(0)) at search.c:485 > val = 140737488336288 > bufp = 0xbf5d00 <searchbufs+384> Here's your problem: fast_string_match_internal got a Lisp string=XIL(0x3036ec4), but its data passed to re_search as the 2nd arg is a NULL pointer. You need to find out how this happens, e.g. by setting a watchpoint on string's data inside Ffile_name_as_directory. Or maybe the string is already corrupted there? ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#34655: 26.1.92; Segfault in module with --module-assertions 2019-02-26 15:45 ` Eli Zaretskii @ 2019-03-17 16:38 ` Basil L. Contovounesios 2019-03-17 17:08 ` Eli Zaretskii 0 siblings, 1 reply; 32+ messages in thread From: Basil L. Contovounesios @ 2019-03-17 16:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 34655, Philipp Stephani [-- Attachment #1: gdb.txt --] [-- Type: text/plain, Size: 43910 bytes --] Starting program: /home/blc/.local/src/emacs26/src/emacs -Q --module-assertions [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7ffff07c1700 (LWP 31458)] [New Thread 0x7fffefe12700 (LWP 31459)] [New Thread 0x7fffef481700 (LWP 31460)] Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:364 364 signal (sig, SIG_DFL); #0 0x0000000000584d53 in terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:364 #1 0x000000000061bfdf in die (msg=0x786cf2 "STRINGP (*p) && SSDATA (*p)", file=0x7869a0 "emacs-module.c", line=984) at alloc.c:7406 #2 0x00000000006854ce in value_to_lisp (v=0x3059c90) at emacs-module.c:984 p = 0x3059c90 values = XIL(0x2fb6243) env = 0x3059b70 environments = XIL(0x2fb6353) vptr = 0x3059c90 optr = 0x3059c90 num_environments = 0 num_values = 3 b = true o = XIL(0x7fffffffb5b0) #3 0x0000000000682ad6 in module_funcall (env=0x3059b70, fun=0x2e52d60, nargs=1, args=0x7fffffffb728) at emacs-module.c:480 i = 0 internal_handler_CONDITION_CASE = 0x2c802a0 internal_cleanup_CONDITION_CASE = 0x2c802a0 internal_handler_CATCHER_ALL = 0x2c7f9c0 internal_cleanup_CATCHER_ALL = 0x2c7f9c0 newargs = 0x7fffffffb5e0 sa_avail = 16368 sa_count = 23 sa_must_free = false nargs1 = 2 result = 0x7fffffffb6a0 #4 0x00007fffee809263 in rp_funcall (env=0x3059b70, value=0x7fffffffb728, name=0x7fffee80a02d "file-name-as-directory", nargs=1, args=0x7fffffffb728) at realpath.c:62 #5 0x00007fffee80951e in Frealpath_truename (env=0x3059b70, nargs=1, args=0x7fffffffb750, data=0x0) at realpath.c:127 file = 0x3059c90 dir = 0x2e3db80 obuf = 0x3059c70 "/home/blc/.emacs.d/" nbuf = 0x3059ce0 "/home/blc/.emacs.d" #6 0x0000000000684eb8 in funcall_module (function=XIL(0x2cd8fc5), nargs=1, arglist=0x7fffffffb990) at emacs-module.c:788 func = 0x2cd8fc0 pub = { size = 140737488336824, private_members = 0x7ffff6c43760, make_global_ref = 0x2c85380, free_global_ref = 0x0, non_local_exit_check = 0x7fffffffb830, non_local_exit_clear = 0x8ec8b95782e18b00, non_local_exit_get = 0x2c85380, non_local_exit_signal = 0x2c85380, non_local_exit_throw = 0x7fffffffb840, make_function = 0xc17f20 <lispsym+52896>, funcall = 0x42, intern = 0xcea0, type_of = 0x7fffffffb820, is_not_nil = 0x57e6cb <builtin_lisp_symbol+48>, eq = 0x7fffffffb840, extract_integer = 0x44e01043390, make_integer = 0x7fffffffb860, extract_float = 0x61f56e <Fsymbol_value+43>, make_float = 0x7fffffffb840, copy_string_contents = 0x438310 <x_figure_window_size+6133>, make_string = 0x7fffffffb860, make_user_ptr = 0x8096c4 <pure+130788>, get_user_ptr = 0x580dca <FRAMEP+29>, set_user_ptr = 0x0, get_user_finalizer = 0x7fffffffb980, set_user_finalizer = 0x642070 <eval_sub+210>, vec_get = 0x7fffffffb890, vec_set = 0x438310 <x_figure_window_size+6133>, vec_size = 0x2d94b15, should_quit = 0x7e4480 <x_redisplay_interface> } priv = { pending_non_local_exit = emacs_funcall_exit_return, non_local_exit_symbol = XIL(0), non_local_exit_data = XIL(0), values = XIL(0xc9a023) } env = 0x3059b70 count = 22 sa_avail = 16376 sa_count = 23 sa_must_free = false args = 0x7fffffffb750 ret = 0x1100463791 #7 0x0000000000644baa in funcall_lambda (fun=XIL(0x2cd8fc5), nargs=1, arg_vector=0x7fffffffb990) at eval.c:2987 val = XIL(0x648c9c) syms_left = XIL(0x7fffffffb990) next = XIL(0x21055d0) lexenv = XIL(0x580de9) count = 22 i = 34624976 optional = false rest = false previous_optional_or_rest = false #8 0x00000000006447f1 in apply_lambda (fun=XIL(0x2cd8fc5), args=XIL(0x1295563), count=21) at eval.c:2913 args_left = XIL(0) i = 1 numargs = 1 arg_vector = 0x7fffffffb990 tem = XIL(0x8096c4) sa_avail = 16376 sa_count = 22 sa_must_free = false #9 0x00000000006429c9 in eval_sub (form=XIL(0x1295573)) at eval.c:2286 fun = XIL(0x2cd8fc5) val = XIL(0x3057534) original_fun = XIL(0x21055d0) original_args = XIL(0x1295563) funcar = XIL(0x2d6f6f1) count = 21 argvals = {XIL(0x7fffffffbae0), XIL(0x1293903), XIL(0x2105600), XIL(0x2d4e000), XIL(0x41f2b0), make_number(0), XIL(0x10), make_number(2)} #10 0x000000000063cef2 in Fprogn (body=XIL(0x129a7d3)) at eval.c:459 form = XIL(0x1295573) val = XIL(0x3057534) #11 0x000000000063cf24 in prog_ignore (body=XIL(0x129a773)) at eval.c:470 #12 0x000000000063f11c in Fwhile (args=XIL(0x129a6c3)) at eval.c:992 test = XIL(0x1293903) body = XIL(0x129a773) #13 0x0000000000642382 in eval_sub (form=XIL(0x129a663)) at eval.c:2193 args_left = XIL(0x129a6c3) numargs = make_number(4) fun = XIL(0xb90f45) val = XIL(0x7fffffffbca0) original_fun = XIL(0xae0a0) original_args = XIL(0x129a6c3) funcar = XIL(0xc0b080) count = 20 argvals = {XIL(0), XIL(0), XIL(0x2e3dad0), XIL(0), XIL(0x7fffffffbde0), XIL(0x684c6c), XIL(0x7fffffffbc80), XIL(0x2e501b4)} #14 0x000000000063cef2 in Fprogn (body=XIL(0)) at eval.c:459 form = XIL(0x129a663) val = XIL(0) #15 0x000000000063f03c in Flet (args=XIL(0x129a5d3)) at eval.c:973 temps = 0x7fffffffbd20 tem = make_number(0) lexenv = XIL(0) elt = XIL(0x1293a03) varlist = XIL(0) count = 18 argnum = 2 sa_avail = 16368 sa_count = 18 sa_must_free = false varlist_len = 2 nvars = 2 #16 0x0000000000642382 in eval_sub (form=XIL(0x129a5c3)) at eval.c:2193 args_left = XIL(0x129a5d3) numargs = make_number(2) fun = XIL(0xb90f05) val = XIL(0xc2a0) original_fun = XIL(0x83a0) original_args = XIL(0x129a5d3) funcar = XIL(0x57e6cb) count = 17 argvals = {XIL(0x2e501b4), XIL(0), make_number(0), XIL(0xc0a7a0), XIL(0x7fffffffbe80), XIL(0xc0b080), XIL(0x7fffffffbf00), XIL(0)} #17 0x000000000063cef2 in Fprogn (body=XIL(0)) at eval.c:459 form = XIL(0x129a5c3) val = XIL(0xc2a0) #18 0x0000000000642382 in eval_sub (form=XIL(0x1299623)) at eval.c:2193 args_left = XIL(0x1299613) numargs = make_number(2) fun = XIL(0xb90bc5) val = XIL(0x1105280) original_fun = XIL(0xa920) original_args = XIL(0x1299613) funcar = make_number(1644217) count = 16 argvals = {XIL(0x7fffffffbfb0), XIL(0xc0a7a0), XIL(0xc9e400), XIL(0), XIL(0x7fffffffbfd0), XIL(0xc12a90), XIL(0x580b87), XIL(0)} #19 0x0000000000641d39 in Feval (form=XIL(0x1299623), lexical=XIL(0)) at eval.c:2061 count = 15 #20 0x0000000000644464 in funcall_subr (subr=0xb911c0 <Seval>, numargs=2, args=0x7fffffffc210) at eval.c:2853 internal_argbuf = {XIL(0xb911c0), XIL(0x7fffffffc0f8), make_number(1440909), XIL(0xa00c0b080), XIL(0xb911c5), XIL(0x7fffffffc118), XIL(0xb911c0), XIL(0x7fffffffc110)} internal_args = 0x7fffffffc210 #21 0x0000000000643f75 in Ffuncall (nargs=3, args=0x7fffffffc208) at eval.c:2776 fun = XIL(0xb911c5) original_fun = XIL(0x53a0) funcar = make_number(1604955) numargs = 2 val = XIL(0x7fffffffc190) count = 14 #22 0x000000000069985f in exec_byte_code (bytestr=XIL(0x94686c), vector=XIL(0x94688d), maxdepth=make_number(16), args_template=make_number(257), nargs=1, args=0x7fffffffc6b0) at bytecode.c:630 op = 2 type = CATCHER targets = {0x69c7ce <exec_byte_code+15689>, 0x69c7f3 <exec_byte_code+15726>, 0x69c7f5 <exec_byte_code+15728>, 0x69c7f7 <exec_byte_code+15730>, 0x69c7f9 <exec_byte_code+15732>, 0x69c7f9 <exec_byte_code+15732>, 0x69c85e <exec_byte_code+15833>, 0x69c8d2 <exec_byte_code+15949>, 0x698f99 <exec_byte_code+1300>, 0x698f9b <exec_byte_code+1302>, 0x698f9d <exec_byte_code+1304>, 0x698f9f <exec_byte_code+1306>, 0x698fa1 <exec_byte_code+1308>, 0x698fa1 <exec_byte_code+1308>, 0x698fa7 <exec_byte_code+1314>, 0x698f68 <exec_byte_code+1251>, 0x69946d <exec_byte_code+2536>, 0x69946f <exec_byte_code+2538>, 0x699471 <exec_byte_code+2540>, 0x699473 <exec_byte_code+2542>, 0x699475 <exec_byte_code+2544>, 0x699475 <exec_byte_code+2544>, 0x6994aa <exec_byte_code+2597>, 0x69947b <exec_byte_code+2550>, 0x69977c <exec_byte_code+3319>, 0x69977e <exec_byte_code+3321>, 0x699780 <exec_byte_code+3323>, 0x699782 <exec_byte_code+3325>, 0x699784 <exec_byte_code+3327>, 0x699784 <exec_byte_code+3327>, 0x699736 <exec_byte_code+3249>, 0x69974d <exec_byte_code+3272>, 0x69982c <exec_byte_code+3495>, 0x69982e <exec_byte_code+3497>, 0x699830 <exec_byte_code+3499>, 0x699832 <exec_byte_code+3501>, 0x699834 <exec_byte_code+3503>, 0x699834 <exec_byte_code+3503>, 0x6997e6 <exec_byte_code+3425>, 0x6997fd <exec_byte_code+3448>, 0x6998e1 <exec_byte_code+3676>, 0x6998e3 <exec_byte_code+3678>, 0x6998e5 <exec_byte_code+3680>, 0x6998e7 <exec_byte_code+3682>, 0x6998e9 <exec_byte_code+3684>, 0x6998e9 <exec_byte_code+3684>, 0x69989b <exec_byte_code+3606>, 0x6998b2 <exec_byte_code+3629>, 0x69a140 <exec_byte_code+5819>, 0x69a026 <exec_byte_code+5537>, 0x69a01d <exec_byte_code+5528>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69a371 <exec_byte_code+6380>, 0x69a490 <exec_byte_code+6667>, 0x69a4fa <exec_byte_code+6773>, 0x69a565 <exec_byte_code+6880>, 0x69a5d1 <exec_byte_code+6988>, 0x6992c0 <exec_byte_code+2107>, 0x699345 <exec_byte_code+2240>, 0x69a652 <exec_byte_code+7117>, 0x699201 <exec_byte_code+1916>, 0x6993ad <exec_byte_code+2344>, 0x69a6c4 <exec_byte_code+7231>, 0x69a72c <exec_byte_code+7335>, 0x69a774 <exec_byte_code+7407>, 0x69a7dc <exec_byte_code+7511>, 0x69a82e <exec_byte_code+7593>, 0x69a8ff <exec_byte_code+7802>, 0x69a947 <exec_byte_code+7874>, 0x69a9af <exec_byte_code+7978>, 0x69aa34 <exec_byte_code+8111>, 0x69aa7c <exec_byte_code+8183>, 0x69aac4 <exec_byte_code+8255>, 0x69ab2c <exec_byte_code+8359>, 0x69ab94 <exec_byte_code+8463>, 0x69abfc <exec_byte_code+8567>, 0x69ac81 <exec_byte_code+8700>, 0x69acd3 <exec_byte_code+8782>, 0x69ad25 <exec_byte_code+8864>, 0x69adf6 <exec_byte_code+9073>, 0x69ae70 <exec_byte_code+9195>, 0x69aeea <exec_byte_code+9317>, 0x69b0b6 <exec_byte_code+9777>, 0x69b123 <exec_byte_code+9886>, 0x69b190 <exec_byte_code+9995>, 0x69b1fd <exec_byte_code+10104>, 0x69b26a <exec_byte_code+10213>, 0x69b2bc <exec_byte_code+10295>, 0x69b33a <exec_byte_code+10421>, 0x69b38c <exec_byte_code+10503>, 0x69b3de <exec_byte_code+10585>, 0x69b430 <exec_byte_code+10667>, 0x69b53c <exec_byte_code+10935>, 0x699ea0 <exec_byte_code+5147>, 0x69b59a <exec_byte_code+11029>, 0x69b5e2 <exec_byte_code+11101>, 0x69b6ae <exec_byte_code+11305>, 0x69b717 <exec_byte_code+11410>, 0x69b775 <exec_byte_code+11504>, 0x69b7bd <exec_byte_code+11576>, 0x69b803 <exec_byte_code+11646>, 0x69b849 <exec_byte_code+11716>, 0x69b897 <exec_byte_code+11794>, 0x69c7ce <exec_byte_code+15689>, 0x69b8ef <exec_byte_code+11882>, 0x69b935 <exec_byte_code+11952>, 0x69b97b <exec_byte_code+12022>, 0x69b9c1 <exec_byte_code+12092>, 0x69ba07 <exec_byte_code+12162>, 0x69ba4d <exec_byte_code+12232>, 0x699ea0 <exec_byte_code+5147>, 0x69c7ce <exec_byte_code+15689>, 0x69ba95 <exec_byte_code+12304>, 0x69baea <exec_byte_code+12389>, 0x69bb32 <exec_byte_code+12461>, 0x69bb7a <exec_byte_code+12533>, 0x69bbe2 <exec_byte_code+12637>, 0x69bc4a <exec_byte_code+12741>, 0x69bc92 <exec_byte_code+12813>, 0x69bdac <exec_byte_code+13095>, 0x69be14 <exec_byte_code+13199>, 0x69be7c <exec_byte_code+13303>, 0x69bee4 <exec_byte_code+13407>, 0x69bf2a <exec_byte_code+13477>, 0x69c7ce <exec_byte_code+15689>, 0x699dd4 <exec_byte_code+4943>, 0x699998 <exec_byte_code+3859>, 0x699172 <exec_byte_code+1773>, 0x699a44 <exec_byte_code+4031>, 0x699ac5 <exec_byte_code+4160>, 0x699b43 <exec_byte_code+4286>, 0x699d88 <exec_byte_code+4867>, 0x699d9d <exec_byte_code+4888>, 0x6996e3 <exec_byte_code+3166>, 0x699e57 <exec_byte_code+5074>, 0x699ed7 <exec_byte_code+5202>, 0x699f65 <exec_byte_code+5344>, 0x699fae <exec_byte_code+5417>, 0x69a18c <exec_byte_code+5895>, 0x69a209 <exec_byte_code+6020>, 0x69a28e <exec_byte_code+6153>, 0x69a2ee <exec_byte_code+6249>, 0x69994a <exec_byte_code+3781>, 0x69bf72 <exec_byte_code+13549>, 0x69bff7 <exec_byte_code+13682>, 0x69c03f <exec_byte_code+13754>, 0x69c087 <exec_byte_code+13826>, 0x69c0cf <exec_byte_code+13898>, 0x69c117 <exec_byte_code+13970>, 0x69c17f <exec_byte_code+14074>, 0x69c1e7 <exec_byte_code+14178>, 0x69c24f <exec_byte_code+14282>, 0x69c2b7 <exec_byte_code+14386>, 0x69c42d <exec_byte_code+14760>, 0x69c495 <exec_byte_code+14864>, 0x69c4fd <exec_byte_code+14968>, 0x69c545 <exec_byte_code+15040>, 0x69c5ad <exec_byte_code+15144>, 0x69c615 <exec_byte_code+15248>, 0x69c65d <exec_byte_code+15320>, 0x69c6a5 <exec_byte_code+15392>, 0x69b482 <exec_byte_code+10749>, 0x69b4d4 <exec_byte_code+10831>, 0x69c6f7 <exec_byte_code+15474>, 0x69c763 <exec_byte_code+15582>, 0x69c7ce <exec_byte_code+15689>, 0x699bc1 <exec_byte_code+4412>, 0x699bde <exec_byte_code+4441>, 0x699c4a <exec_byte_code+4549>, 0x699cb6 <exec_byte_code+4657>, 0x699d1f <exec_byte_code+4762>, 0x69a880 <exec_byte_code+7675>, 0x69ad77 <exec_byte_code+8946>, 0x69b62f <exec_byte_code+11178>, 0x69c965 <exec_byte_code+16096>, 0x69c9da <exec_byte_code+16213>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69ca70 <exec_byte_code+16363>, 0x69caf7 <exec_byte_code+16498>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69cd0b <exec_byte_code+17030> <repeats 64 times>} const_length = 7 bytestr_length = 43 vectorp = 0x946890 <pure+1429680> quitcounter = 1 '\001' stack_items = 17 sa_avail = 16205 sa_count = 14 sa_must_free = false stack_base = 0x7fffffffc1a0 stack_lim = 0x7fffffffc228 top = 0x7fffffffc208 void_stack_lim = 0x7fffffffc228 bytestr_data = 0x7fffffffc228 "\301\001!\211@\001A\211@\001A\211@\001A\001\004\006\a\302\303\304\305 !\b\"\002\203#" pc = 0x7fffffffc243 "\002\203#" count = 14 result = XIL(0) #23 0x0000000000644b6f in funcall_lambda (fun=XIL(0x94683d), nargs=1, arg_vector=0x7fffffffc6a8) at eval.c:2977 size = 5 val = XIL(0x7fffffffc608) syms_left = make_number(257) next = XIL(0x1200c0b080) lexenv = XIL(0x7fffffffc5e0) count = 14 i = 0 optional = false rest = false previous_optional_or_rest = false #24 0x0000000000643fb9 in Ffuncall (nargs=2, args=0x7fffffffc6a0) at eval.c:2778 fun = XIL(0x94683d) original_fun = XIL(0xa39960) funcar = XIL(0x645e21) numargs = 1 val = XIL(0x7fffffffc680) count = 13 #25 0x000000000069985f in exec_byte_code (bytestr=XIL(0x946b0c), vector=XIL(0x946b2d), maxdepth=make_number(4), args_template=make_number(257), nargs=1, args=0x7fffffffcb30) at bytecode.c:630 op = 1 type = (unknown: 12114688) targets = {0x69c7ce <exec_byte_code+15689>, 0x69c7f3 <exec_byte_code+15726>, 0x69c7f5 <exec_byte_code+15728>, 0x69c7f7 <exec_byte_code+15730>, 0x69c7f9 <exec_byte_code+15732>, 0x69c7f9 <exec_byte_code+15732>, 0x69c85e <exec_byte_code+15833>, 0x69c8d2 <exec_byte_code+15949>, 0x698f99 <exec_byte_code+1300>, 0x698f9b <exec_byte_code+1302>, 0x698f9d <exec_byte_code+1304>, 0x698f9f <exec_byte_code+1306>, 0x698fa1 <exec_byte_code+1308>, 0x698fa1 <exec_byte_code+1308>, 0x698fa7 <exec_byte_code+1314>, 0x698f68 <exec_byte_code+1251>, 0x69946d <exec_byte_code+2536>, 0x69946f <exec_byte_code+2538>, 0x699471 <exec_byte_code+2540>, 0x699473 <exec_byte_code+2542>, 0x699475 <exec_byte_code+2544>, 0x699475 <exec_byte_code+2544>, 0x6994aa <exec_byte_code+2597>, 0x69947b <exec_byte_code+2550>, 0x69977c <exec_byte_code+3319>, 0x69977e <exec_byte_code+3321>, 0x699780 <exec_byte_code+3323>, 0x699782 <exec_byte_code+3325>, 0x699784 <exec_byte_code+3327>, 0x699784 <exec_byte_code+3327>, 0x699736 <exec_byte_code+3249>, 0x69974d <exec_byte_code+3272>, 0x69982c <exec_byte_code+3495>, 0x69982e <exec_byte_code+3497>, 0x699830 <exec_byte_code+3499>, 0x699832 <exec_byte_code+3501>, 0x699834 <exec_byte_code+3503>, 0x699834 <exec_byte_code+3503>, 0x6997e6 <exec_byte_code+3425>, 0x6997fd <exec_byte_code+3448>, 0x6998e1 <exec_byte_code+3676>, 0x6998e3 <exec_byte_code+3678>, 0x6998e5 <exec_byte_code+3680>, 0x6998e7 <exec_byte_code+3682>, 0x6998e9 <exec_byte_code+3684>, 0x6998e9 <exec_byte_code+3684>, 0x69989b <exec_byte_code+3606>, 0x6998b2 <exec_byte_code+3629>, 0x69a140 <exec_byte_code+5819>, 0x69a026 <exec_byte_code+5537>, 0x69a01d <exec_byte_code+5528>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69a371 <exec_byte_code+6380>, 0x69a490 <exec_byte_code+6667>, 0x69a4fa <exec_byte_code+6773>, 0x69a565 <exec_byte_code+6880>, 0x69a5d1 <exec_byte_code+6988>, 0x6992c0 <exec_byte_code+2107>, 0x699345 <exec_byte_code+2240>, 0x69a652 <exec_byte_code+7117>, 0x699201 <exec_byte_code+1916>, 0x6993ad <exec_byte_code+2344>, 0x69a6c4 <exec_byte_code+7231>, 0x69a72c <exec_byte_code+7335>, 0x69a774 <exec_byte_code+7407>, 0x69a7dc <exec_byte_code+7511>, 0x69a82e <exec_byte_code+7593>, 0x69a8ff <exec_byte_code+7802>, 0x69a947 <exec_byte_code+7874>, 0x69a9af <exec_byte_code+7978>, 0x69aa34 <exec_byte_code+8111>, 0x69aa7c <exec_byte_code+8183>, 0x69aac4 <exec_byte_code+8255>, 0x69ab2c <exec_byte_code+8359>, 0x69ab94 <exec_byte_code+8463>, 0x69abfc <exec_byte_code+8567>, 0x69ac81 <exec_byte_code+8700>, 0x69acd3 <exec_byte_code+8782>, 0x69ad25 <exec_byte_code+8864>, 0x69adf6 <exec_byte_code+9073>, 0x69ae70 <exec_byte_code+9195>, 0x69aeea <exec_byte_code+9317>, 0x69b0b6 <exec_byte_code+9777>, 0x69b123 <exec_byte_code+9886>, 0x69b190 <exec_byte_code+9995>, 0x69b1fd <exec_byte_code+10104>, 0x69b26a <exec_byte_code+10213>, 0x69b2bc <exec_byte_code+10295>, 0x69b33a <exec_byte_code+10421>, 0x69b38c <exec_byte_code+10503>, 0x69b3de <exec_byte_code+10585>, 0x69b430 <exec_byte_code+10667>, 0x69b53c <exec_byte_code+10935>, 0x699ea0 <exec_byte_code+5147>, 0x69b59a <exec_byte_code+11029>, 0x69b5e2 <exec_byte_code+11101>, 0x69b6ae <exec_byte_code+11305>, 0x69b717 <exec_byte_code+11410>, 0x69b775 <exec_byte_code+11504>, 0x69b7bd <exec_byte_code+11576>, 0x69b803 <exec_byte_code+11646>, 0x69b849 <exec_byte_code+11716>, 0x69b897 <exec_byte_code+11794>, 0x69c7ce <exec_byte_code+15689>, 0x69b8ef <exec_byte_code+11882>, 0x69b935 <exec_byte_code+11952>, 0x69b97b <exec_byte_code+12022>, 0x69b9c1 <exec_byte_code+12092>, 0x69ba07 <exec_byte_code+12162>, 0x69ba4d <exec_byte_code+12232>, 0x699ea0 <exec_byte_code+5147>, 0x69c7ce <exec_byte_code+15689>, 0x69ba95 <exec_byte_code+12304>, 0x69baea <exec_byte_code+12389>, 0x69bb32 <exec_byte_code+12461>, 0x69bb7a <exec_byte_code+12533>, 0x69bbe2 <exec_byte_code+12637>, 0x69bc4a <exec_byte_code+12741>, 0x69bc92 <exec_byte_code+12813>, 0x69bdac <exec_byte_code+13095>, 0x69be14 <exec_byte_code+13199>, 0x69be7c <exec_byte_code+13303>, 0x69bee4 <exec_byte_code+13407>, 0x69bf2a <exec_byte_code+13477>, 0x69c7ce <exec_byte_code+15689>, 0x699dd4 <exec_byte_code+4943>, 0x699998 <exec_byte_code+3859>, 0x699172 <exec_byte_code+1773>, 0x699a44 <exec_byte_code+4031>, 0x699ac5 <exec_byte_code+4160>, 0x699b43 <exec_byte_code+4286>, 0x699d88 <exec_byte_code+4867>, 0x699d9d <exec_byte_code+4888>, 0x6996e3 <exec_byte_code+3166>, 0x699e57 <exec_byte_code+5074>, 0x699ed7 <exec_byte_code+5202>, 0x699f65 <exec_byte_code+5344>, 0x699fae <exec_byte_code+5417>, 0x69a18c <exec_byte_code+5895>, 0x69a209 <exec_byte_code+6020>, 0x69a28e <exec_byte_code+6153>, 0x69a2ee <exec_byte_code+6249>, 0x69994a <exec_byte_code+3781>, 0x69bf72 <exec_byte_code+13549>, 0x69bff7 <exec_byte_code+13682>, 0x69c03f <exec_byte_code+13754>, 0x69c087 <exec_byte_code+13826>, 0x69c0cf <exec_byte_code+13898>, 0x69c117 <exec_byte_code+13970>, 0x69c17f <exec_byte_code+14074>, 0x69c1e7 <exec_byte_code+14178>, 0x69c24f <exec_byte_code+14282>, 0x69c2b7 <exec_byte_code+14386>, 0x69c42d <exec_byte_code+14760>, 0x69c495 <exec_byte_code+14864>, 0x69c4fd <exec_byte_code+14968>, 0x69c545 <exec_byte_code+15040>, 0x69c5ad <exec_byte_code+15144>, 0x69c615 <exec_byte_code+15248>, 0x69c65d <exec_byte_code+15320>, 0x69c6a5 <exec_byte_code+15392>, 0x69b482 <exec_byte_code+10749>, 0x69b4d4 <exec_byte_code+10831>, 0x69c6f7 <exec_byte_code+15474>, 0x69c763 <exec_byte_code+15582>, 0x69c7ce <exec_byte_code+15689>, 0x699bc1 <exec_byte_code+4412>, 0x699bde <exec_byte_code+4441>, 0x699c4a <exec_byte_code+4549>, 0x699cb6 <exec_byte_code+4657>, 0x699d1f <exec_byte_code+4762>, 0x69a880 <exec_byte_code+7675>, 0x69ad77 <exec_byte_code+8946>, 0x69b62f <exec_byte_code+11178>, 0x69c965 <exec_byte_code+16096>, 0x69c9da <exec_byte_code+16213>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69ca70 <exec_byte_code+16363>, 0x69caf7 <exec_byte_code+16498>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69cd0b <exec_byte_code+17030> <repeats 64 times>} const_length = 4 bytestr_length = 29 vectorp = 0x946b30 <pure+1430352> quitcounter = 1 '\001' stack_items = 5 sa_avail = 16315 sa_count = 12 sa_must_free = false stack_base = 0x7fffffffc690 stack_lim = 0x7fffffffc6b8 top = 0x7fffffffc6a0 void_stack_lim = 0x7fffffffc6b8 bytestr_data = 0x7fffffffc6b8 "\b\204\b" pc = 0x7fffffffc6c5 "\n)B\211A\t=\204\032" count = 12 result = XIL(0x7fffffffc950) #26 0x0000000000644b6f in funcall_lambda (fun=XIL(0x946acd), nargs=1, arg_vector=0x7fffffffcb28) at eval.c:2977 size = 6 val = XIL(0x7fffffffca88) syms_left = make_number(257) next = XIL(0x1200c0b080) lexenv = make_number(1440909) count = 12 i = 0 optional = false rest = false previous_optional_or_rest = false #27 0x0000000000643fb9 in Ffuncall (nargs=2, args=0x7fffffffcb20) at eval.c:2778 fun = XIL(0x946acd) original_fun = XIL(0x4dd0a0) funcar = XIL(0xc0b080) numargs = 1 val = XIL(0xc2a0) count = 11 #28 0x000000000069985f in exec_byte_code (bytestr=XIL(0x94602c), vector=XIL(0x94604d), maxdepth=make_number(3), args_template=make_number(256), nargs=1, args=0x7fffffffd0c8) at bytecode.c:630 op = 1 type = (unknown: 12133568) targets = {0x69c7ce <exec_byte_code+15689>, 0x69c7f3 <exec_byte_code+15726>, 0x69c7f5 <exec_byte_code+15728>, 0x69c7f7 <exec_byte_code+15730>, 0x69c7f9 <exec_byte_code+15732>, 0x69c7f9 <exec_byte_code+15732>, 0x69c85e <exec_byte_code+15833>, 0x69c8d2 <exec_byte_code+15949>, 0x698f99 <exec_byte_code+1300>, 0x698f9b <exec_byte_code+1302>, 0x698f9d <exec_byte_code+1304>, 0x698f9f <exec_byte_code+1306>, 0x698fa1 <exec_byte_code+1308>, 0x698fa1 <exec_byte_code+1308>, 0x698fa7 <exec_byte_code+1314>, 0x698f68 <exec_byte_code+1251>, 0x69946d <exec_byte_code+2536>, 0x69946f <exec_byte_code+2538>, 0x699471 <exec_byte_code+2540>, 0x699473 <exec_byte_code+2542>, 0x699475 <exec_byte_code+2544>, 0x699475 <exec_byte_code+2544>, 0x6994aa <exec_byte_code+2597>, 0x69947b <exec_byte_code+2550>, 0x69977c <exec_byte_code+3319>, 0x69977e <exec_byte_code+3321>, 0x699780 <exec_byte_code+3323>, 0x699782 <exec_byte_code+3325>, 0x699784 <exec_byte_code+3327>, 0x699784 <exec_byte_code+3327>, 0x699736 <exec_byte_code+3249>, 0x69974d <exec_byte_code+3272>, 0x69982c <exec_byte_code+3495>, 0x69982e <exec_byte_code+3497>, 0x699830 <exec_byte_code+3499>, 0x699832 <exec_byte_code+3501>, 0x699834 <exec_byte_code+3503>, 0x699834 <exec_byte_code+3503>, 0x6997e6 <exec_byte_code+3425>, 0x6997fd <exec_byte_code+3448>, 0x6998e1 <exec_byte_code+3676>, 0x6998e3 <exec_byte_code+3678>, 0x6998e5 <exec_byte_code+3680>, 0x6998e7 <exec_byte_code+3682>, 0x6998e9 <exec_byte_code+3684>, 0x6998e9 <exec_byte_code+3684>, 0x69989b <exec_byte_code+3606>, 0x6998b2 <exec_byte_code+3629>, 0x69a140 <exec_byte_code+5819>, 0x69a026 <exec_byte_code+5537>, 0x69a01d <exec_byte_code+5528>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69a371 <exec_byte_code+6380>, 0x69a490 <exec_byte_code+6667>, 0x69a4fa <exec_byte_code+6773>, 0x69a565 <exec_byte_code+6880>, 0x69a5d1 <exec_byte_code+6988>, 0x6992c0 <exec_byte_code+2107>, 0x699345 <exec_byte_code+2240>, 0x69a652 <exec_byte_code+7117>, 0x699201 <exec_byte_code+1916>, 0x6993ad <exec_byte_code+2344>, 0x69a6c4 <exec_byte_code+7231>, 0x69a72c <exec_byte_code+7335>, 0x69a774 <exec_byte_code+7407>, 0x69a7dc <exec_byte_code+7511>, 0x69a82e <exec_byte_code+7593>, 0x69a8ff <exec_byte_code+7802>, 0x69a947 <exec_byte_code+7874>, 0x69a9af <exec_byte_code+7978>, 0x69aa34 <exec_byte_code+8111>, 0x69aa7c <exec_byte_code+8183>, 0x69aac4 <exec_byte_code+8255>, 0x69ab2c <exec_byte_code+8359>, 0x69ab94 <exec_byte_code+8463>, 0x69abfc <exec_byte_code+8567>, 0x69ac81 <exec_byte_code+8700>, 0x69acd3 <exec_byte_code+8782>, 0x69ad25 <exec_byte_code+8864>, 0x69adf6 <exec_byte_code+9073>, 0x69ae70 <exec_byte_code+9195>, 0x69aeea <exec_byte_code+9317>, 0x69b0b6 <exec_byte_code+9777>, 0x69b123 <exec_byte_code+9886>, 0x69b190 <exec_byte_code+9995>, 0x69b1fd <exec_byte_code+10104>, 0x69b26a <exec_byte_code+10213>, 0x69b2bc <exec_byte_code+10295>, 0x69b33a <exec_byte_code+10421>, 0x69b38c <exec_byte_code+10503>, 0x69b3de <exec_byte_code+10585>, 0x69b430 <exec_byte_code+10667>, 0x69b53c <exec_byte_code+10935>, 0x699ea0 <exec_byte_code+5147>, 0x69b59a <exec_byte_code+11029>, 0x69b5e2 <exec_byte_code+11101>, 0x69b6ae <exec_byte_code+11305>, 0x69b717 <exec_byte_code+11410>, 0x69b775 <exec_byte_code+11504>, 0x69b7bd <exec_byte_code+11576>, 0x69b803 <exec_byte_code+11646>, 0x69b849 <exec_byte_code+11716>, 0x69b897 <exec_byte_code+11794>, 0x69c7ce <exec_byte_code+15689>, 0x69b8ef <exec_byte_code+11882>, 0x69b935 <exec_byte_code+11952>, 0x69b97b <exec_byte_code+12022>, 0x69b9c1 <exec_byte_code+12092>, 0x69ba07 <exec_byte_code+12162>, 0x69ba4d <exec_byte_code+12232>, 0x699ea0 <exec_byte_code+5147>, 0x69c7ce <exec_byte_code+15689>, 0x69ba95 <exec_byte_code+12304>, 0x69baea <exec_byte_code+12389>, 0x69bb32 <exec_byte_code+12461>, 0x69bb7a <exec_byte_code+12533>, 0x69bbe2 <exec_byte_code+12637>, 0x69bc4a <exec_byte_code+12741>, 0x69bc92 <exec_byte_code+12813>, 0x69bdac <exec_byte_code+13095>, 0x69be14 <exec_byte_code+13199>, 0x69be7c <exec_byte_code+13303>, 0x69bee4 <exec_byte_code+13407>, 0x69bf2a <exec_byte_code+13477>, 0x69c7ce <exec_byte_code+15689>, 0x699dd4 <exec_byte_code+4943>, 0x699998 <exec_byte_code+3859>, 0x699172 <exec_byte_code+1773>, 0x699a44 <exec_byte_code+4031>, 0x699ac5 <exec_byte_code+4160>, 0x699b43 <exec_byte_code+4286>, 0x699d88 <exec_byte_code+4867>, 0x699d9d <exec_byte_code+4888>, 0x6996e3 <exec_byte_code+3166>, 0x699e57 <exec_byte_code+5074>, 0x699ed7 <exec_byte_code+5202>, 0x699f65 <exec_byte_code+5344>, 0x699fae <exec_byte_code+5417>, 0x69a18c <exec_byte_code+5895>, 0x69a209 <exec_byte_code+6020>, 0x69a28e <exec_byte_code+6153>, 0x69a2ee <exec_byte_code+6249>, 0x69994a <exec_byte_code+3781>, 0x69bf72 <exec_byte_code+13549>, 0x69bff7 <exec_byte_code+13682>, 0x69c03f <exec_byte_code+13754>, 0x69c087 <exec_byte_code+13826>, 0x69c0cf <exec_byte_code+13898>, 0x69c117 <exec_byte_code+13970>, 0x69c17f <exec_byte_code+14074>, 0x69c1e7 <exec_byte_code+14178>, 0x69c24f <exec_byte_code+14282>, 0x69c2b7 <exec_byte_code+14386>, 0x69c42d <exec_byte_code+14760>, 0x69c495 <exec_byte_code+14864>, 0x69c4fd <exec_byte_code+14968>, 0x69c545 <exec_byte_code+15040>, 0x69c5ad <exec_byte_code+15144>, 0x69c615 <exec_byte_code+15248>, 0x69c65d <exec_byte_code+15320>, 0x69c6a5 <exec_byte_code+15392>, 0x69b482 <exec_byte_code+10749>, 0x69b4d4 <exec_byte_code+10831>, 0x69c6f7 <exec_byte_code+15474>, 0x69c763 <exec_byte_code+15582>, 0x69c7ce <exec_byte_code+15689>, 0x699bc1 <exec_byte_code+4412>, 0x699bde <exec_byte_code+4441>, 0x699c4a <exec_byte_code+4549>, 0x699cb6 <exec_byte_code+4657>, 0x699d1f <exec_byte_code+4762>, 0x69a880 <exec_byte_code+7675>, 0x69ad77 <exec_byte_code+8946>, 0x69b62f <exec_byte_code+11178>, 0x69c965 <exec_byte_code+16096>, 0x69c9da <exec_byte_code+16213>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69ca70 <exec_byte_code+16363>, 0x69caf7 <exec_byte_code+16498>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69cd0b <exec_byte_code+17030> <repeats 64 times>} const_length = 4 bytestr_length = 17 vectorp = 0x946050 <pure+1427568> quitcounter = 1 '\001' stack_items = 4 sa_avail = 16335 sa_count = 10 sa_must_free = false stack_base = 0x7fffffffcb10 stack_lim = 0x7fffffffcb30 top = 0x7fffffffcb20 void_stack_lim = 0x7fffffffcb30 bytestr_data = 0x7fffffffcb30 "p\030\301 \210\302\001\206\v" pc = 0x7fffffffcb3c "\210\301 )\207\316\377\377\377\177" count = 10 result = XIL(0x128ca33) #29 0x0000000000644b6f in funcall_lambda (fun=XIL(0x945fed), nargs=1, arg_vector=0x7fffffffd0c0) at eval.c:2977 size = 6 val = XIL(0x7fffffffcef8) syms_left = make_number(256) next = XIL(0x1200c0b080) lexenv = XIL(0x7fffffffced0) count = 10 i = 0 optional = false rest = false previous_optional_or_rest = false #30 0x0000000000643fb9 in Ffuncall (nargs=2, args=0x7fffffffd0b8) at eval.c:2778 fun = XIL(0x945fed) original_fun = XIL(0xa39590) funcar = XIL(0x589371) numargs = 1 val = XIL(0) count = 9 #31 0x0000000000639907 in Ffuncall_interactively (nargs=2, args=0x7fffffffd0b8) at callint.c:252 speccount = 8 #32 0x0000000000644337 in funcall_subr (subr=0xb90a00 <Sfuncall_interactively>, numargs=2, args=0x7fffffffd0b8) at eval.c:2831 #33 0x0000000000643f75 in Ffuncall (nargs=3, args=0x7fffffffd0b0) at eval.c:2776 fun = XIL(0xb90a05) original_fun = XIL(0x66c0) funcar = XIL(0x645e21) numargs = 2 val = XIL(0x7fffffffd0a0) count = 7 #34 0x000000000063bde9 in Fcall_interactively (function=XIL(0xa39590), record_flag=XIL(0), keys=XIL(0xca3695)) at callint.c:854 val = XIL(0) args = 0x7fffffffd0b0 visargs = 0x7fffffffd0c8 specs = XIL(0x80fa7c) filter_specs = XIL(0x80fa7c) teml = XIL(0x7fffffffcf28) up_event = XIL(0) enable = XIL(0) sa_avail = 16310 sa_count = 6 sa_must_free = false speccount = 6 next_event = 1 prefix_arg = XIL(0) string = 0x7fffffffd100 "P" tem = 0x77842b "" varies = 0x7fffffffd0e0 "" i = 3 nargs = 3 mark = 5760715 arg_from_tty = false key_count = 1 record_then_fail = false save_this_command = XIL(0xa39590) save_last_command = XIL(0x4627b0) save_this_original_command = XIL(0xa39590) save_real_this_command = XIL(0xa39590) #35 0x0000000000644490 in funcall_subr (subr=0xb90a40 <Scall_interactively>, numargs=3, args=0x7fffffffd430) at eval.c:2856 internal_argbuf = {XIL(0xb90a40), XIL(0x7fffffffd348), make_number(1440909), XIL(0xa00c0b080), XIL(0xb90a45), XIL(0x7fffffffd368), XIL(0xb90a40), XIL(0x7fffffffd360)} internal_args = 0x7fffffffd430 #36 0x0000000000643f75 in Ffuncall (nargs=4, args=0x7fffffffd428) at eval.c:2776 fun = XIL(0xb90a45) original_fun = XIL(0xb1b80) funcar = XIL(0xc0b080) numargs = 3 val = XIL(0) count = 5 #37 0x000000000069985f in exec_byte_code (bytestr=XIL(0x8aea6c), vector=XIL(0x8aea8d), maxdepth=make_number(13), args_template=make_number(1025), nargs=1, args=0x7fffffffd960) at bytecode.c:630 op = 3 type = CATCHER targets = {0x69c7ce <exec_byte_code+15689>, 0x69c7f3 <exec_byte_code+15726>, 0x69c7f5 <exec_byte_code+15728>, 0x69c7f7 <exec_byte_code+15730>, 0x69c7f9 <exec_byte_code+15732>, 0x69c7f9 <exec_byte_code+15732>, 0x69c85e <exec_byte_code+15833>, 0x69c8d2 <exec_byte_code+15949>, 0x698f99 <exec_byte_code+1300>, 0x698f9b <exec_byte_code+1302>, 0x698f9d <exec_byte_code+1304>, 0x698f9f <exec_byte_code+1306>, 0x698fa1 <exec_byte_code+1308>, 0x698fa1 <exec_byte_code+1308>, 0x698fa7 <exec_byte_code+1314>, 0x698f68 <exec_byte_code+1251>, 0x69946d <exec_byte_code+2536>, 0x69946f <exec_byte_code+2538>, 0x699471 <exec_byte_code+2540>, 0x699473 <exec_byte_code+2542>, 0x699475 <exec_byte_code+2544>, 0x699475 <exec_byte_code+2544>, 0x6994aa <exec_byte_code+2597>, 0x69947b <exec_byte_code+2550>, 0x69977c <exec_byte_code+3319>, 0x69977e <exec_byte_code+3321>, 0x699780 <exec_byte_code+3323>, 0x699782 <exec_byte_code+3325>, 0x699784 <exec_byte_code+3327>, 0x699784 <exec_byte_code+3327>, 0x699736 <exec_byte_code+3249>, 0x69974d <exec_byte_code+3272>, 0x69982c <exec_byte_code+3495>, 0x69982e <exec_byte_code+3497>, 0x699830 <exec_byte_code+3499>, 0x699832 <exec_byte_code+3501>, 0x699834 <exec_byte_code+3503>, 0x699834 <exec_byte_code+3503>, 0x6997e6 <exec_byte_code+3425>, 0x6997fd <exec_byte_code+3448>, 0x6998e1 <exec_byte_code+3676>, 0x6998e3 <exec_byte_code+3678>, 0x6998e5 <exec_byte_code+3680>, 0x6998e7 <exec_byte_code+3682>, 0x6998e9 <exec_byte_code+3684>, 0x6998e9 <exec_byte_code+3684>, 0x69989b <exec_byte_code+3606>, 0x6998b2 <exec_byte_code+3629>, 0x69a140 <exec_byte_code+5819>, 0x69a026 <exec_byte_code+5537>, 0x69a01d <exec_byte_code+5528>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69a371 <exec_byte_code+6380>, 0x69a490 <exec_byte_code+6667>, 0x69a4fa <exec_byte_code+6773>, 0x69a565 <exec_byte_code+6880>, 0x69a5d1 <exec_byte_code+6988>, 0x6992c0 <exec_byte_code+2107>, 0x699345 <exec_byte_code+2240>, 0x69a652 <exec_byte_code+7117>, 0x699201 <exec_byte_code+1916>, 0x6993ad <exec_byte_code+2344>, 0x69a6c4 <exec_byte_code+7231>, 0x69a72c <exec_byte_code+7335>, 0x69a774 <exec_byte_code+7407>, 0x69a7dc <exec_byte_code+7511>, 0x69a82e <exec_byte_code+7593>, 0x69a8ff <exec_byte_code+7802>, 0x69a947 <exec_byte_code+7874>, 0x69a9af <exec_byte_code+7978>, 0x69aa34 <exec_byte_code+8111>, 0x69aa7c <exec_byte_code+8183>, 0x69aac4 <exec_byte_code+8255>, 0x69ab2c <exec_byte_code+8359>, 0x69ab94 <exec_byte_code+8463>, 0x69abfc <exec_byte_code+8567>, 0x69ac81 <exec_byte_code+8700>, 0x69acd3 <exec_byte_code+8782>, 0x69ad25 <exec_byte_code+8864>, 0x69adf6 <exec_byte_code+9073>, 0x69ae70 <exec_byte_code+9195>, 0x69aeea <exec_byte_code+9317>, 0x69b0b6 <exec_byte_code+9777>, 0x69b123 <exec_byte_code+9886>, 0x69b190 <exec_byte_code+9995>, 0x69b1fd <exec_byte_code+10104>, 0x69b26a <exec_byte_code+10213>, 0x69b2bc <exec_byte_code+10295>, 0x69b33a <exec_byte_code+10421>, 0x69b38c <exec_byte_code+10503>, 0x69b3de <exec_byte_code+10585>, 0x69b430 <exec_byte_code+10667>, 0x69b53c <exec_byte_code+10935>, 0x699ea0 <exec_byte_code+5147>, 0x69b59a <exec_byte_code+11029>, 0x69b5e2 <exec_byte_code+11101>, 0x69b6ae <exec_byte_code+11305>, 0x69b717 <exec_byte_code+11410>, 0x69b775 <exec_byte_code+11504>, 0x69b7bd <exec_byte_code+11576>, 0x69b803 <exec_byte_code+11646>, 0x69b849 <exec_byte_code+11716>, 0x69b897 <exec_byte_code+11794>, 0x69c7ce <exec_byte_code+15689>, 0x69b8ef <exec_byte_code+11882>, 0x69b935 <exec_byte_code+11952>, 0x69b97b <exec_byte_code+12022>, 0x69b9c1 <exec_byte_code+12092>, 0x69ba07 <exec_byte_code+12162>, 0x69ba4d <exec_byte_code+12232>, 0x699ea0 <exec_byte_code+5147>, 0x69c7ce <exec_byte_code+15689>, 0x69ba95 <exec_byte_code+12304>, 0x69baea <exec_byte_code+12389>, 0x69bb32 <exec_byte_code+12461>, 0x69bb7a <exec_byte_code+12533>, 0x69bbe2 <exec_byte_code+12637>, 0x69bc4a <exec_byte_code+12741>, 0x69bc92 <exec_byte_code+12813>, 0x69bdac <exec_byte_code+13095>, 0x69be14 <exec_byte_code+13199>, 0x69be7c <exec_byte_code+13303>, 0x69bee4 <exec_byte_code+13407>, 0x69bf2a <exec_byte_code+13477>, 0x69c7ce <exec_byte_code+15689>, 0x699dd4 <exec_byte_code+4943>, 0x699998 <exec_byte_code+3859>, 0x699172 <exec_byte_code+1773>, 0x699a44 <exec_byte_code+4031>, 0x699ac5 <exec_byte_code+4160>, 0x699b43 <exec_byte_code+4286>, 0x699d88 <exec_byte_code+4867>, 0x699d9d <exec_byte_code+4888>, 0x6996e3 <exec_byte_code+3166>, 0x699e57 <exec_byte_code+5074>, 0x699ed7 <exec_byte_code+5202>, 0x699f65 <exec_byte_code+5344>, 0x699fae <exec_byte_code+5417>, 0x69a18c <exec_byte_code+5895>, 0x69a209 <exec_byte_code+6020>, 0x69a28e <exec_byte_code+6153>, 0x69a2ee <exec_byte_code+6249>, 0x69994a <exec_byte_code+3781>, 0x69bf72 <exec_byte_code+13549>, 0x69bff7 <exec_byte_code+13682>, 0x69c03f <exec_byte_code+13754>, 0x69c087 <exec_byte_code+13826>, 0x69c0cf <exec_byte_code+13898>, 0x69c117 <exec_byte_code+13970>, 0x69c17f <exec_byte_code+14074>, 0x69c1e7 <exec_byte_code+14178>, 0x69c24f <exec_byte_code+14282>, 0x69c2b7 <exec_byte_code+14386>, 0x69c42d <exec_byte_code+14760>, 0x69c495 <exec_byte_code+14864>, 0x69c4fd <exec_byte_code+14968>, 0x69c545 <exec_byte_code+15040>, 0x69c5ad <exec_byte_code+15144>, 0x69c615 <exec_byte_code+15248>, 0x69c65d <exec_byte_code+15320>, 0x69c6a5 <exec_byte_code+15392>, 0x69b482 <exec_byte_code+10749>, 0x69b4d4 <exec_byte_code+10831>, 0x69c6f7 <exec_byte_code+15474>, 0x69c763 <exec_byte_code+15582>, 0x69c7ce <exec_byte_code+15689>, 0x699bc1 <exec_byte_code+4412>, 0x699bde <exec_byte_code+4441>, 0x699c4a <exec_byte_code+4549>, 0x699cb6 <exec_byte_code+4657>, 0x699d1f <exec_byte_code+4762>, 0x69a880 <exec_byte_code+7675>, 0x69ad77 <exec_byte_code+8946>, 0x69b62f <exec_byte_code+11178>, 0x69c965 <exec_byte_code+16096>, 0x69c9da <exec_byte_code+16213>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69ca70 <exec_byte_code+16363>, 0x69caf7 <exec_byte_code+16498>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69c7ce <exec_byte_code+15689>, 0x69cd0b <exec_byte_code+17030> <repeats 64 times>} const_length = 25 bytestr_length = 165 vectorp = 0x8aea90 <pure+807600> quitcounter = 1 '\001' stack_items = 14 sa_avail = 16107 sa_count = 5 sa_must_free = false stack_base = 0x7fffffffd3f0 stack_lim = 0x7fffffffd460 top = 0x7fffffffd428 void_stack_lim = 0x7fffffffd460 bytestr_data = 0x7fffffffd460 "\306\020\211?\205\023" pc = 0x7fffffffd4db "\006\006\071\203\242" count = 5 result = XIL(0) #38 0x0000000000644b6f in funcall_lambda (fun=XIL(0x8aea3d), nargs=1, arg_vector=0x7fffffffd958) at eval.c:2977 size = 5 val = XIL(0x7fffffffd8b8) syms_left = make_number(1025) next = XIL(0x1200c0b080) lexenv = make_number(34910567923712) count = 5 i = 0 optional = false rest = false previous_optional_or_rest = false #39 0x0000000000643fb9 in Ffuncall (nargs=2, args=0x7fffffffd950) at eval.c:2778 fun = XIL(0x8aea3d) original_fun = XIL(0x3f30) funcar = XIL(0x1) numargs = 1 val = XIL(0x7fffffffd958) count = 4 #40 0x0000000000643891 in call1 (fn=XIL(0x3f30), arg1=XIL(0xa39590)) at eval.c:2627 #41 0x000000000058a56b in command_loop_1 () at keyboard.c:1482 scount = 3 cmd = XIL(0xa39590) keybuf = {make_number(10), XIL(0x2012e48b3), XIL(0), XIL(0x7a10), XIL(0x10000010f), XIL(0), XIL(0xc0a7a0), XIL(0x7a10), make_number(55834574852), XIL(0xc12a90), XIL(0x7fffffffd9e0), XIL(0), XIL(0x7fffffffda20), make_number(1644723), make_number(34910567923712), XIL(0xc0b080), XIL(0x580b87), XIL(0), XIL(0x7fffffffda20), XIL(0x57e6cb), XIL(0), XIL(0xc0b080), XIL(0x7fffffffda80), XIL(0), XIL(0x7fffffffda50), XIL(0x57e6cb), XIL(0x5), XIL(0x7a10), XIL(0x7fffffffda90), XIL(0x640415)} i = 1 prev_modiff = 18 prev_buffer = 0xc9e400 <bss_sbrk_buffer+455584> already_adjusted = false #42 0x000000000063fffe in internal_condition_case (bfun=0x589d5b <command_loop_1>, handlers=XIL(0x5280), hfun=0x5893bf <cmd_error>) at eval.c:1336 val = XIL(0x57e6cb) c = 0x2c80180 #43 0x0000000000589971 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1110 val = XIL(0xc900) #44 0x000000000063f4fd in internal_catch (tag=XIL(0xc900), func=0x589944 <command_loop_2>, arg=XIL(0)) at eval.c:1101 val = XIL(0) c = 0x2c80060 #45 0x000000000058990f in command_loop () at keyboard.c:1089 #46 0x0000000000588ea8 in recursive_edit_1 () at keyboard.c:695 count = 1 val = XIL(0x7fffffffdc00) #47 0x000000000058909d in Frecursive_edit () at keyboard.c:766 count = 0 buffer = XIL(0) #48 0x0000000000586c3c in main (argc=3, argv=0x7fffffffde48) at emacs.c:1717 stack_bottom_variable = 0x2c6c290 do_initial_setlocale = true dumping = false skip_args = 1 no_loadup = false junk = 0x0 dname_arg = 0x0 ch_to_dir = 0x0 original_pwd = 0x0 disable_aslr = false rlim = { rlim_cur = 10022912, rlim_max = 18446744073709551615 } sockfd = -1 module_assertions = true Lisp Backtrace: "realpath-truename" (0xffffb990) "while" (0xffffbc70) "let" (0xffffbe90) "progn" (0xffffbfe0) "eval" (0xffffc210) "elisp--eval-last-sexp" (0xffffc6a8) "eval-last-sexp" (0xffffcb28) "eval-print-last-sexp" (0xffffd0c0) "funcall-interactively" (0xffffd0b8) "call-interactively" (0xffffd430) "command-execute" (0xffffd958) #2 0x00000000006854ce in value_to_lisp (v=0x3059c90) at emacs-module.c:984 984 eassert (STRINGP (*p) && SSDATA (*p)); $1 = (Lisp_Object *) 0x3059c90 Lisp_String $2 = (struct Lisp_String *) 0x3057690 0 quit [-- Attachment #2: Type: text/plain, Size: 2399 bytes --] [CCing Philipp as the author of module assertions.] Eli Zaretskii <eliz@gnu.org> writes: >> From: "Basil L. Contovounesios" <contovob@tcd.ie> >> Date: Mon, 25 Feb 2019 21:00:41 +0000 >> >> Starting program: /home/blc/.local/src/emacs26/src/emacs -Q --module-assertions >> [Thread debugging using libthread_db enabled] >> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". >> [New Thread 0x7ffff01cb700 (LWP 8299)] >> [New Thread 0x7fffef9ac700 (LWP 8300)] >> [New Thread 0x7fffef1ab700 (LWP 8301)] >> >> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault. >> re_search_2 (bufp=0xbf5d00 <searchbufs+384>, str1=0x0, size1=0, str2=0x0, size2=18, startpos=0, >> range=18, regs=0x0, stop=18) at regex.c:4354 >> 4354 buf_ch = STRING_CHAR_AND_LENGTH (d, buf_charlen); >> #0 0x0000000000608594 in re_search_2 >> (bufp=0xbf5d00 <searchbufs+384>, str1=0x0, size1=0, str2=0x0, size2=18, startpos=0, range=18, regs=0x0, stop=18) at regex.c:4354 >> buf_charlen = 0 >> irange = 18 >> lim = 0 >> d = 0x0 >> buf_ch = 18 >> val = 691541629 >> string1 = 0x0 >> string2 = 0x0 >> fastmap = 0xbf5d38 <searchbufs+440> "" >> translate = make_number(0) >> total_size = 18 >> endpos = 18 >> anchored_start = 0 '\000' >> multibyte = 1 '\001' >> #1 0x0000000000607f91 in re_search >> (bufp=0xbf5d00 <searchbufs+384>, string=0x0, size=18, startpos=0, range=18, regs=0x0) >> at regex.c:4181 >> #2 0x00000000005f3fd0 in fast_string_match_internal >> (regexp=XIL(0x8c761c), string=XIL(0x3036ec4), table=XIL(0)) at search.c:485 >> val = 140737488336288 >> bufp = 0xbf5d00 <searchbufs+384> > > Here's your problem: fast_string_match_internal got a Lisp > string=XIL(0x3036ec4), but its data passed to re_search as the 2nd arg > is a NULL pointer. You need to find out how this happens, e.g. by > setting a watchpoint on string's data inside Ffile_name_as_directory. > Or maybe the string is already corrupted there? The file name string is already corrupted when Ffile_name_as_directory is called; see below. First, I rewrote the dynamic module[1] to add nonlocal exit checks after almost every call to the module API. [1]: https://gitlab.com/basil-conto/realpath I also added the following assertions to src/emacs-module.c: [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #3: module-asserts.patch --] [-- Type: text/x-diff, Size: 2757 bytes --] diff --git a/src/emacs-module.c b/src/emacs-module.c index 0abfd3f6f1..4f2b0ecd4b 100644 --- a/src/emacs-module.c +++ b/src/emacs-module.c @@ -458,6 +458,8 @@ module_make_function (emacs_env *env, ptrdiff_t min_arity, ptrdiff_t max_arity, return lisp_to_value (env, result); } +static bool my_check = false; + static emacs_value module_funcall (emacs_env *env, emacs_value fun, ptrdiff_t nargs, emacs_value args[]) @@ -473,6 +475,7 @@ module_funcall (emacs_env *env, emacs_value fun, ptrdiff_t nargs, xsignal0 (Qoverflow_error); SAFE_ALLOCA_LISP (newargs, nargs1); newargs[0] = value_to_lisp (fun); + my_check = EQ (newargs[0], Qfile_name_as_directory); for (ptrdiff_t i = 0; i < nargs; i++) newargs[1 + i] = value_to_lisp (args[i]); emacs_value result = lisp_to_value (env, Ffuncall (nargs1, newargs)); @@ -581,8 +584,10 @@ module_make_string (emacs_env *env, const char *str, ptrdiff_t length) /* FIXME: AUTO_STRING_WITH_LEN requires STR to be null-terminated, but we shouldn't require that. */ AUTO_STRING_WITH_LEN (lstr, str, length); - return lisp_to_value (env, - code_convert_string_norecord (lstr, Qutf_8, false)); + Lisp_Object lisp = code_convert_string_norecord (lstr, Qutf_8, false); + eassert (STRINGP (lisp) && SSDATA (lisp)); + my_check = true; + return lisp_to_value (env, lisp); } static emacs_value @@ -955,6 +960,8 @@ value_to_lisp_bits (emacs_value v) static Lisp_Object value_to_lisp (emacs_value v) { + bool b = my_check; + my_check = false; if (module_assertions) { /* Check the liveness of the value by iterating over all live @@ -972,7 +979,11 @@ value_to_lisp (emacs_value v) { Lisp_Object *p = XSAVE_POINTER (XCAR (values), 0); if (p == optr) - return *p; + { + if (b) + eassert (STRINGP (*p) && SSDATA (*p)); + return *p; + } ++num_values; } ++num_environments; @@ -1008,6 +1019,8 @@ lisp_to_value_bits (Lisp_Object o) static emacs_value lisp_to_value (emacs_env *env, Lisp_Object o) { + bool b = my_check; + my_check = false; if (module_assertions) { /* Add the new value to the list of values allocated from this @@ -1020,6 +1033,11 @@ lisp_to_value (emacs_env *env, Lisp_Object o) ATTRIBUTE_MAY_ALIAS emacs_value ret = vptr; struct emacs_env_private *priv = env->private_members; priv->values = Fcons (make_save_ptr (ret), priv->values); + if (b) + { + eassert (STRINGP (o) && SSDATA (o)); + eassert (STRINGP (*optr) && SSDATA (*optr)); + } return ret; } [-- Attachment #4: Type: text/plain, Size: 890 bytes --] These reveal that value_to_lisp eventually returns a corrupted string, but I don't know why. I've seen comments in src/fileio.c referring to string-relocation during GC; could this be at play here? Either way, do you have any suggestions on how to proceed? Here's the full recipe again, now with debugging symbols for the module: 0. git clone https://gitlab.com/basil-conto/realpath.git 1. cd realpath 2. make DEBUG=1 3. cd /path/to/emacs/src 4. gdb emacs 5. set logging on 6. r -Q --module-assertions 7. (progn (module-load "/path/to/realpath.so") (dotimes (_ 1000) (realpath-truename user-emacs-directory))) C-j [The loop usually trips the assertions on its first run, but if it doesn't, just try again once or twice.] 8. bt full 9. f 2 10. p p 11. pr [#<INVALID_LISP_OBJECT 0x03059c90>] 12. xpr I attach the resulting GDB log. Thanks, -- Basil ^ permalink raw reply related [flat|nested] 32+ messages in thread
* bug#34655: 26.1.92; Segfault in module with --module-assertions 2019-03-17 16:38 ` Basil L. Contovounesios @ 2019-03-17 17:08 ` Eli Zaretskii 2019-03-17 23:52 ` Basil L. Contovounesios 0 siblings, 1 reply; 32+ messages in thread From: Eli Zaretskii @ 2019-03-17 17:08 UTC (permalink / raw) To: Basil L. Contovounesios; +Cc: 34655, p.stephani2 > From: "Basil L. Contovounesios" <contovob@tcd.ie> > Cc: <34655@debbugs.gnu.org>, Philipp Stephani <p.stephani2@gmail.com> > Date: Sun, 17 Mar 2019 16:38:58 +0000 > > These reveal that value_to_lisp eventually returns a corrupted string, > but I don't know why. Did you try to identify the code which causes the corruption, i.e. the data is valid before that code runs, and invalid after that? If not, can you try? The way to do that is by painstakingly stepping through the code while examining the relevant data, possibly with help of watchpoints and displays set up by the GDB "display" command. > I've seen comments in src/fileio.c referring to string-relocation > during GC; could this be at play here? It could be, if your module code holds onto C pointers to Lisp string data while Emacs runs parts of the interpreter which could GC. Does that happen anywhere in your code or in the code involved in module-assertions? > Either way, do you have any suggestions on how to proceed? See above. I tried at the time to reproduce your problem, and failed. But I did that on Windows, where I needed to replace the non-existent realpath by an equivalent function, so it's not a faithful reproduction. I will see if I can find time to look at this on a GNU machine, unless someone beats me to it. > 8. bt full > 9. f 2 > 10. p p > 11. pr [#<INVALID_LISP_OBJECT 0x03059c90>] > 12. xpr Why did you expect 'p' to be a valid Lisp object? It's actually a pointer to a Lisp object, i.e. try (gdb) p *p (gdb) xpr ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#34655: 26.1.92; Segfault in module with --module-assertions 2019-03-17 17:08 ` Eli Zaretskii @ 2019-03-17 23:52 ` Basil L. Contovounesios 2019-03-18 16:21 ` Eli Zaretskii 0 siblings, 1 reply; 32+ messages in thread From: Basil L. Contovounesios @ 2019-03-17 23:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 34655, p.stephani2 Eli Zaretskii <eliz@gnu.org> writes: >> From: "Basil L. Contovounesios" <contovob@tcd.ie> >> Cc: <34655@debbugs.gnu.org>, Philipp Stephani <p.stephani2@gmail.com> >> Date: Sun, 17 Mar 2019 16:38:58 +0000 >> >> These reveal that value_to_lisp eventually returns a corrupted string, >> but I don't know why. > > Did you try to identify the code which causes the corruption, i.e. the > data is valid before that code runs, and invalid after that? If not, > can you try? The way to do that is by painstakingly stepping through > the code while examining the relevant data, possibly with help of > watchpoints and displays set up by the GDB "display" command. The patch adding assertions to emacs-module.c narrows the problematic code to lines 123--127 of the dynamic module[1]: if (rp_lisp_string (env, &file, nbuf) && rp_funcall (env, &dir, "directory-name-p", 1, &dir) && env->is_not_nil (env, dir)) /* Return directory name when given one à la Ffile_truename. */ rp_funcall (env, &file, "file-name-as-directory", 1, &file); [1]: https://gitlab.com/basil-conto/realpath/blob/master/realpath.c#L123-127 On line 123, 'file' is set to an Emacs string created from the C string 'nbuf' ('rp_lisp_string' wraps 'module_make_string' along with a nonlocal exit check, and similarly 'rp_funcall' wraps 'module_funcall'). On line 127, 'file' is passed to 'file-name-as-directory'. The assertions added to 'module_make_string' and 'lisp_to_value' never fail, suggesting the string returned by them is fine (though the assertions in 'lisp_to_value' only target intermediate Lisp_Objects, not the returned emacs_value). The assertion added to 'value_to_lisp' via 'module_funcall', OTOH, does fail. I'll see if I can step through this, though I'm not yet sure how I'll distinguish the problematic call to the module function from the hundreds of unproblematic ones before it. There's probably a way to teach GDB how to inspect emacs_values which I'm not yet familiar with. >> I've seen comments in src/fileio.c referring to string-relocation >> during GC; could this be at play here? > > It could be, if your module code holds onto C pointers to Lisp string > data while Emacs runs parts of the interpreter which could GC. Does > that happen anywhere in your code or in the code involved in > module-assertions? I can't speak for emacs-module.c (I haven't yet understood how Vmodule_environments and its save pointers work), but the only exchange between C and Lisp strings in my code is via the module API, i.e. module_make_string and module_copy_string_contents. I would hope the API and its opaque emacs_value type make it difficult for such issues to arise. >> Either way, do you have any suggestions on how to proceed? > > See above. > > I tried at the time to reproduce your problem, and failed. But I did > that on Windows, where I needed to replace the non-existent realpath > by an equivalent function, so it's not a faithful reproduction. I > will see if I can find time to look at this on a GNU machine, unless > someone beats me to it. Replacing 'canonicalize_file_name' with 'strdup' still reproduces the issue for me. Perhaps increasing the number of calls to realpath-truename from 1000 to 5000 will also help. >> 8. bt full >> 9. f 2 >> 10. p p >> 11. pr [#<INVALID_LISP_OBJECT 0x03059c90>] >> 12. xpr > > Why did you expect 'p' to be a valid Lisp object? It's actually a > pointer to a Lisp object, i.e. try > > (gdb) p *p > (gdb) xpr Oops, that was a thinko. The only difference is GDB reports XIL(...) instead of (Lisp_Object *), though. Thank you for your help, I'll report more as time allows. -- Basil ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#34655: 26.1.92; Segfault in module with --module-assertions 2019-03-17 23:52 ` Basil L. Contovounesios @ 2019-03-18 16:21 ` Eli Zaretskii 2019-03-18 16:58 ` Basil L. Contovounesios 0 siblings, 1 reply; 32+ messages in thread From: Eli Zaretskii @ 2019-03-18 16:21 UTC (permalink / raw) To: Basil L. Contovounesios; +Cc: 34655, p.stephani2 > From: "Basil L. Contovounesios" <contovob@tcd.ie> > Cc: <34655@debbugs.gnu.org>, <p.stephani2@gmail.com> > Date: Sun, 17 Mar 2019 23:52:55 +0000 > > > I tried at the time to reproduce your problem, and failed. But I did > > that on Windows, where I needed to replace the non-existent realpath > > by an equivalent function, so it's not a faithful reproduction. I > > will see if I can find time to look at this on a GNU machine, unless > > someone beats me to it. > > Replacing 'canonicalize_file_name' with 'strdup' still reproduces the > issue for me. Perhaps increasing the number of calls to > realpath-truename from 1000 to 5000 will also help. Right, the strdup part did that for me. (My previous attempt also used strdup as part of the replacement, but still failed to reproduce. Memory corruption bugs are frequently weird that way.) So I modified your recipe slightly, like this: (progn (module-load "/path/to/realpath.so") (setq garbage-collection-messages t) (dotimes (i 5000) (message "%d" i) (realpath-truename user-emacs-directory))) put it on a file named rp.el, and then ran it under GDB: (gdb) r -batch --module-assertions -l ./rp.el Here's what I see: [...] 3077 3078 3079 3080 Garbage collecting... Garbage collecting...done Thread 1 received signal SIGSEGV, Segmentation fault. 0x011e9918 in rpl_re_search_2 (bufp=0x17c0260 <searchbufs+4736>, str1=0x0, size1=0, str2=0x0, size2=20, startpos=0, range=20, regs=0x0, stop=20) at regex-emacs.c:3322 3322 buf_ch = STRING_CHAR_AND_LENGTH (d, buf_charlen) Looks like it indeed crashes after a GC, and on my system needs more than 3000 iterations. So let's run it with a breakpoint at the beginning of GC: (gdb) break alloc.c:6044 Breakpoint 3 at 0x11fa1bb: file alloc.c, line 6044. (gdb) r -batch --module-assertions -l ./rp.el [...] 3080 Thread 1 hit Breakpoint 3, garbage_collect_1 (gcst=0x82bb84) at alloc.c:6044 6044 record_in_backtrace (QAutomatic_GC, 0, 0); The backtrace at this point: (gdb) bt #0 garbage_collect_1 (gcst=0x82bb84) at alloc.c:6044 #1 0x011fa88e in garbage_collect () at alloc.c:6241 #2 0x01149adc in maybe_gc () at lisp.h:5028 #3 0x0123b012 in Ffuncall (nargs=2, args=0x82bcb0) at eval.c:2829 #4 0x0128c3cf in module_funcall (env=0x6122730, fun=0x6122868, nargs=1, args=0x82bd50) at emacs-module.c:483 #5 0x62d8136f in rp_funcall (env=0x6122730, value=0x82bd50, name=0x62d83060 "directory-name-p", nargs=1, args=0x82bd50) at realpath.c:62 #6 0x62d815cc in Frealpath_truename (env=0x6122730, nargs=1, args=0x82bd90, data=0x0) at realpath.c:124 [...] Lisp Backtrace: "directory-name-p" (0x82bcb8) "realpath-truename" (0x82bf80) "while" (0x82c2c8) "let" (0x82c538) "eval-buffer" (0x82cab0) "load-with-code-conversion" (0x82d0f0) "load" (0x82d9b8) "command-line-1" (0x82e3d0) "command-line" (0x82efe8) "normal-top-level" (0x82f690) As you see, the call to Ffuncall is the one that triggers GC from time to time. What happens with our 'file' at this point? (gdb) fr 6 (gdb) p file $1 = (emacs_value) 0x6122848 (gdb) p *file $2 = <incomplete type> (gdb) p *(Lisp_Object *)file $3 = XIL(0x8000000006121ed0) (gdb) xtype Lisp_String (gdb) xstring $4 = (struct Lisp_String *) 0x6121ed0 "d:/usr/eli/.emacs.d/" Still valid. Now let's see who thrashes it: (gdb) p *$4 $5 = { u = { s = { size = 20, size_byte = 20, intervals = 0x0, data = 0x611e9fc "d:/usr/eli/.emacs.d/" }, next = 0x14, gcaligned = 20 '\024' } } (gdb) watch -l $4->u.s.data Hardware watchpoint 4: -location $4->u.s.data (gdb) c Continuing. Garbage collecting... Thread 1 hit Hardware watchpoint 4: -location $4->u.s.data Old value = (unsigned char *) 0x611e9fc "\024" New value = (unsigned char *) 0x0 sweep_strings () at alloc.c:2163 2163 NEXT_FREE_LISP_STRING (s) = string_free_list; (gdb) list 2158 /* Reset the strings's `data' member so that we 2159 know it's free. */ 2160 s->u.s.data = NULL; 2161 2162 /* Put the string on the free-list. */ 2163 NEXT_FREE_LISP_STRING (s) = string_free_list; 2164 string_free_list = ptr_bounds_clip (s, sizeof *s); 2165 ++nfree; 2166 } 2167 } Bingo! This is sweep_strings freeing our string, because it evidently doesn't think it's a Lisp object that is being still referenced. The culprit is this fragment from emacs-module.c, which is called each time you receive a Lisp object from Emacs which you want to use in your module: /* Convert O to an emacs_value. Allocate storage if needed; this can signal if memory is exhausted. Must be an injective function. */ static emacs_value lisp_to_value (emacs_env *env, Lisp_Object o) { if (module_assertions) { /* Add the new value to the list of values allocated from this environment. The value is actually a pointer to the Lisp_Object cast to emacs_value. We make a copy of the object on the free store to guarantee unique addresses. */ ATTRIBUTE_MAY_ALIAS Lisp_Object *optr = xmalloc (sizeof o); *optr = o; void *vptr = optr; ATTRIBUTE_MAY_ALIAS emacs_value ret = vptr; struct emacs_env_private *priv = env->private_members; priv->values = Fcons (make_mint_ptr (ret), priv->values); return ret; } What this does is make a copy of each Lisp object you get from Emacs, store that copy in memory allocated off the heap, and hand your module a pointer to the copy instead of the original object. So when you call, e.g., directory-name-p, an Emacs function, it gets that copy of the object. But memory allocation by xmalloc doesn't record the allocated memory in the red-black tree we maintain for the purposes of detecting Lisp objects referenced by C stack-based variables. So when GC comes to examine the C stack, it doesn't consider the variable 'file' in your module as being a pointer to a live Lisp object, and so it doesn't mark it. Then the sweep phase of GC recycles your Lisp object, which in this case involves setting the string's data to a NULL pointer. The patch to fix this is below; it simply marks these copied values by hand, thus preventing them from being GCed. It ran successfully with even 50,000 iterations. Philipp, any comments/objections? --- src/emacs-module.c~0 2019-02-25 10:18:35.000000000 +0200 +++ src/emacs-module.c 2019-03-18 08:33:00.564476000 +0200 @@ -1133,6 +1133,15 @@ mark_modules (void) mark_object (priv->non_local_exit_symbol); mark_object (priv->non_local_exit_data); mark_object (priv->values); + if (module_assertions) + { + for (Lisp_Object values = priv->values; + CONSP (values); values = XCDR (values)) + { + Lisp_Object *p = xmint_pointer (XCAR (values)); + mark_object (*p); + } + } } } ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#34655: 26.1.92; Segfault in module with --module-assertions 2019-03-18 16:21 ` Eli Zaretskii @ 2019-03-18 16:58 ` Basil L. Contovounesios 2019-03-18 17:53 ` Eli Zaretskii 0 siblings, 1 reply; 32+ messages in thread From: Basil L. Contovounesios @ 2019-03-18 16:58 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 34655, p.stephani2 Eli Zaretskii <eliz@gnu.org> writes: > The patch to fix this is below; it simply marks these copied values by > hand, thus preventing them from being GCed. It ran successfully with > even 50,000 iterations. I can confirm that your patch fixes the issue. I am very grateful not only for your looking into this, but also for taking the time to explain the whole process; it has been enlightening and would have taken me a lot of time to figure out alone. Thanks, -- Basil ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#34655: 26.1.92; Segfault in module with --module-assertions 2019-03-18 16:58 ` Basil L. Contovounesios @ 2019-03-18 17:53 ` Eli Zaretskii 2019-03-21 16:11 ` Philipp Stephani 0 siblings, 1 reply; 32+ messages in thread From: Eli Zaretskii @ 2019-03-18 17:53 UTC (permalink / raw) To: Basil L. Contovounesios; +Cc: 34655, p.stephani2 > From: "Basil L. Contovounesios" <contovob@tcd.ie> > Cc: <34655@debbugs.gnu.org>, <p.stephani2@gmail.com> > Date: Mon, 18 Mar 2019 16:58:35 +0000 > > Eli Zaretskii <eliz@gnu.org> writes: > > > The patch to fix this is below; it simply marks these copied values by > > hand, thus preventing them from being GCed. It ran successfully with > > even 50,000 iterations. > > I can confirm that your patch fixes the issue. Great, thanks for testing. > I am very grateful not only for your looking into this, but also for > taking the time to explain the whole process; it has been enlightening > and would have taken me a lot of time to figure out alone. You are welcome. I will wait for a few days to give Philipp and others a chance to comment, and push then if no one comes up with objections. ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#34655: 26.1.92; Segfault in module with --module-assertions 2019-03-18 17:53 ` Eli Zaretskii @ 2019-03-21 16:11 ` Philipp Stephani 2019-03-21 17:00 ` Eli Zaretskii 0 siblings, 1 reply; 32+ messages in thread From: Philipp Stephani @ 2019-03-21 16:11 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Basil L. Contovounesios, 34655 Am Mo., 18. März 2019 um 18:53 Uhr schrieb Eli Zaretskii <eliz@gnu.org>: > > > From: "Basil L. Contovounesios" <contovob@tcd.ie> > > Cc: <34655@debbugs.gnu.org>, <p.stephani2@gmail.com> > > Date: Mon, 18 Mar 2019 16:58:35 +0000 > > > > Eli Zaretskii <eliz@gnu.org> writes: > > > > > The patch to fix this is below; it simply marks these copied values by > > > hand, thus preventing them from being GCed. It ran successfully with > > > even 50,000 iterations. > > > > I can confirm that your patch fixes the issue. > > Great, thanks for testing. > > > I am very grateful not only for your looking into this, but also for > > taking the time to explain the whole process; it has been enlightening > > and would have taken me a lot of time to figure out alone. > > You are welcome. > > I will wait for a few days to give Philipp and others a chance to > comment, and push then if no one comes up with objections. I haven't checked everything in detail, but my impression is that this is rather another instance of bug#31238. Fixing this only when module assertions are enabled will probably not fix anything, but rather mask issues. Reverting commit 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a is still the right approach here. Can you please hold off a bit? I've almost completed the revert, but haven't pushed it yet. Once that's in we can check whether it also fixes this issue. Thanks! ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#34655: 26.1.92; Segfault in module with --module-assertions 2019-03-21 16:11 ` Philipp Stephani @ 2019-03-21 17:00 ` Eli Zaretskii 2019-03-21 18:28 ` Philipp Stephani 0 siblings, 1 reply; 32+ messages in thread From: Eli Zaretskii @ 2019-03-21 17:00 UTC (permalink / raw) To: Philipp Stephani, Stefan Monnier; +Cc: contovob, 34655 > From: Philipp Stephani <p.stephani2@gmail.com> > Date: Thu, 21 Mar 2019 17:11:41 +0100 > Cc: "Basil L. Contovounesios" <contovob@tcd.ie>, 34655@debbugs.gnu.org > > I haven't checked everything in detail, but my impression is that this > is rather another instance of bug#31238. Fixing this only when module > assertions are enabled will probably not fix anything, but rather mask > issues. Reverting commit 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a is > still the right approach here. Can you please hold off a bit? I've > almost completed the revert, but haven't pushed it yet. Once that's in > we can check whether it also fixes this issue. I will CC Stefan, who committed 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a. I'm not sure we should revert that; we could instead add GC protection for those parts that need it. And the list consed by module-assertions certainly is one of those. ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#34655: 26.1.92; Segfault in module with --module-assertions 2019-03-21 17:00 ` Eli Zaretskii @ 2019-03-21 18:28 ` Philipp Stephani 2019-03-21 19:23 ` Philipp Stephani 2019-03-21 19:27 ` Eli Zaretskii 0 siblings, 2 replies; 32+ messages in thread From: Philipp Stephani @ 2019-03-21 18:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Basil L. Contovounesios, 34655, Stefan Monnier Am Do., 21. März 2019 um 18:00 Uhr schrieb Eli Zaretskii <eliz@gnu.org>: > > > From: Philipp Stephani <p.stephani2@gmail.com> > > Date: Thu, 21 Mar 2019 17:11:41 +0100 > > Cc: "Basil L. Contovounesios" <contovob@tcd.ie>, 34655@debbugs.gnu.org > > > > I haven't checked everything in detail, but my impression is that this > > is rather another instance of bug#31238. Fixing this only when module > > assertions are enabled will probably not fix anything, but rather mask > > issues. Reverting commit 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a is > > still the right approach here. Can you please hold off a bit? I've > > almost completed the revert, but haven't pushed it yet. Once that's in > > we can check whether it also fixes this issue. > > I will CC Stefan, who committed 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a. > > I'm not sure we should revert that; we could instead add GC protection > for those parts that need it. Yes, that's what reverting that commit does :-) We need to mark the objects in all cases, not just when module assertions are enabled. Note that both the designer of the module API (Daniel) and I as one of its main implementers disagree with commit 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a. I'm happy to discuss alternatives, but for now we should revert it and discuss the alternatives *before* implementing them. I've already confirmed that reverting commit 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a fixes bug#31238, and I can try it with this bug as well. ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#34655: 26.1.92; Segfault in module with --module-assertions 2019-03-21 18:28 ` Philipp Stephani @ 2019-03-21 19:23 ` Philipp Stephani 2019-03-21 19:34 ` Eli Zaretskii 2019-03-21 21:29 ` Basil L. Contovounesios 2019-03-21 19:27 ` Eli Zaretskii 1 sibling, 2 replies; 32+ messages in thread From: Philipp Stephani @ 2019-03-21 19:23 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Basil L. Contovounesios, 34655, Stefan Monnier Am Do., 21. März 2019 um 19:28 Uhr schrieb Philipp Stephani <p.stephani2@gmail.com>: > > Am Do., 21. März 2019 um 18:00 Uhr schrieb Eli Zaretskii <eliz@gnu.org>: > > > > > From: Philipp Stephani <p.stephani2@gmail.com> > > > Date: Thu, 21 Mar 2019 17:11:41 +0100 > > > Cc: "Basil L. Contovounesios" <contovob@tcd.ie>, 34655@debbugs.gnu.org > > > > > > I haven't checked everything in detail, but my impression is that this > > > is rather another instance of bug#31238. Fixing this only when module > > > assertions are enabled will probably not fix anything, but rather mask > > > issues. Reverting commit 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a is > > > still the right approach here. Can you please hold off a bit? I've > > > almost completed the revert, but haven't pushed it yet. Once that's in > > > we can check whether it also fixes this issue. > > > > I will CC Stefan, who committed 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a. > > > > I'm not sure we should revert that; we could instead add GC protection > > for those parts that need it. > > Yes, that's what reverting that commit does :-) > We need to mark the objects in all cases, not just when module > assertions are enabled. > Note that both the designer of the module API (Daniel) and I as one of > its main implementers disagree with commit > 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a. I'm happy to discuss > alternatives, but for now we should revert it and discuss the > alternatives *before* implementing them. I've already confirmed that > reverting commit 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a fixes > bug#31238, and I can try it with this bug as well. I wasn't able to reproduce bug#34655 myself (these things tend to be rather flaky), but I've now reverted commit 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a, and at least bug#31238 is now consistently fixed (for me at least). Basil, can you check whether you can still reproduce bug#34655 with the current master? Thanks! ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#34655: 26.1.92; Segfault in module with --module-assertions 2019-03-21 19:23 ` Philipp Stephani @ 2019-03-21 19:34 ` Eli Zaretskii 2019-03-21 21:29 ` Basil L. Contovounesios 1 sibling, 0 replies; 32+ messages in thread From: Eli Zaretskii @ 2019-03-21 19:34 UTC (permalink / raw) To: Philipp Stephani; +Cc: contovob, 34655, monnier > From: Philipp Stephani <p.stephani2@gmail.com> > Date: Thu, 21 Mar 2019 20:23:30 +0100 > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, "Basil L. Contovounesios" <contovob@tcd.ie>, 34655@debbugs.gnu.org > > I wasn't able to reproduce bug#34655 myself (these things tend to be > rather flaky), but I've now reverted commit > 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a And I've just reverted the revert. I'm sorry, but you cannot apply rules unilaterally: if you think it's not OK to make changes without waiting for consensus, please adhere to the same principles when you want to make your own changes. Let's wait for this discussion to run to completion, before we are doing any more changes in this area. ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#34655: 26.1.92; Segfault in module with --module-assertions 2019-03-21 19:23 ` Philipp Stephani 2019-03-21 19:34 ` Eli Zaretskii @ 2019-03-21 21:29 ` Basil L. Contovounesios 2019-03-22 7:11 ` Eli Zaretskii 1 sibling, 1 reply; 32+ messages in thread From: Basil L. Contovounesios @ 2019-03-21 21:29 UTC (permalink / raw) To: Philipp Stephani; +Cc: 34655, Stefan Monnier Philipp Stephani <p.stephani2@gmail.com> writes: > Am Do., 21. März 2019 um 19:28 Uhr schrieb Philipp Stephani > <p.stephani2@gmail.com>: >> >> Am Do., 21. März 2019 um 18:00 Uhr schrieb Eli Zaretskii <eliz@gnu.org>: >> > >> > > From: Philipp Stephani <p.stephani2@gmail.com> >> > > Date: Thu, 21 Mar 2019 17:11:41 +0100 >> > > Cc: "Basil L. Contovounesios" <contovob@tcd.ie>, 34655@debbugs.gnu.org >> > > >> > > I haven't checked everything in detail, but my impression is that this >> > > is rather another instance of bug#31238. Fixing this only when module >> > > assertions are enabled will probably not fix anything, but rather mask >> > > issues. Reverting commit 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a is >> > > still the right approach here. Can you please hold off a bit? I've >> > > almost completed the revert, but haven't pushed it yet. Once that's in >> > > we can check whether it also fixes this issue. >> > >> > I will CC Stefan, who committed 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a. >> > >> > I'm not sure we should revert that; we could instead add GC protection >> > for those parts that need it. >> >> Yes, that's what reverting that commit does :-) >> We need to mark the objects in all cases, not just when module >> assertions are enabled. >> Note that both the designer of the module API (Daniel) and I as one of >> its main implementers disagree with commit >> 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a. I'm happy to discuss >> alternatives, but for now we should revert it and discuss the >> alternatives *before* implementing them. I've already confirmed that >> reverting commit 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a fixes >> bug#31238, and I can try it with this bug as well. > > I wasn't able to reproduce bug#34655 myself (these things tend to be > rather flaky), but I've now reverted commit > 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a, and at least bug#31238 is > now consistently fixed (for me at least). Basil, can you check whether > you can still reproduce bug#34655 with the current master? FWIW, I cannot reproduce bug#34655 after reverting Stefan's commit. Thanks, -- Basil ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#34655: 26.1.92; Segfault in module with --module-assertions 2019-03-21 21:29 ` Basil L. Contovounesios @ 2019-03-22 7:11 ` Eli Zaretskii 0 siblings, 0 replies; 32+ messages in thread From: Eli Zaretskii @ 2019-03-22 7:11 UTC (permalink / raw) To: Basil L. Contovounesios; +Cc: 34655, p.stephani2, monnier > From: "Basil L. Contovounesios" <contovob@tcd.ie> > Cc: Eli Zaretskii <eliz@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>, 34655@debbugs.gnu.org > Date: Thu, 21 Mar 2019 21:29:14 +0000 > > FWIW, I cannot reproduce bug#34655 after reverting Stefan's commit. Great, thanks for testing. ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#34655: 26.1.92; Segfault in module with --module-assertions 2019-03-21 18:28 ` Philipp Stephani 2019-03-21 19:23 ` Philipp Stephani @ 2019-03-21 19:27 ` Eli Zaretskii 2019-03-21 19:37 ` Philipp Stephani 2019-03-22 0:56 ` Stefan Monnier 1 sibling, 2 replies; 32+ messages in thread From: Eli Zaretskii @ 2019-03-21 19:27 UTC (permalink / raw) To: Philipp Stephani; +Cc: contovob, 34655, monnier > > I will CC Stefan, who committed 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a. > > > > I'm not sure we should revert that; we could instead add GC protection > > for those parts that need it. > > Yes, that's what reverting that commit does :-) AFAIU, it does much more. Stefan intended for the conservative stack marking to do the job, so maybe there's a little more that should be done to get there. Or maybe Stefan didn't consider some important factor(s). In either case, I'd like to hear his POV on this before we decide how to proceed. > We need to mark the objects in all cases, not just when module > assertions are enabled. If we get stack marking to work, we won't need to mark objects explicitly. > Note that both the designer of the module API (Daniel) and I as one of > its main implementers disagree with commit > 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a. OK, but I think Stefan's opinion is not less important. > I've already confirmed that reverting commit > 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a fixes bug#31238, and I can > try it with this bug as well. Please do, it's important to know that, I think. Thanks. ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#34655: 26.1.92; Segfault in module with --module-assertions 2019-03-21 19:27 ` Eli Zaretskii @ 2019-03-21 19:37 ` Philipp Stephani 2019-03-21 19:50 ` Eli Zaretskii 2019-03-21 21:31 ` Basil L. Contovounesios 2019-03-22 0:56 ` Stefan Monnier 1 sibling, 2 replies; 32+ messages in thread From: Philipp Stephani @ 2019-03-21 19:37 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Basil L. Contovounesios, 34655, Stefan Monnier Am Do., 21. März 2019 um 20:27 Uhr schrieb Eli Zaretskii <eliz@gnu.org>: > > > > I will CC Stefan, who committed 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a. > > > > > > I'm not sure we should revert that; we could instead add GC protection > > > for those parts that need it. > > > > Yes, that's what reverting that commit does :-) > > AFAIU, it does much more. Stefan intended for the conservative stack > marking to do the job, so maybe there's a little more that should be > done to get there. Or maybe Stefan didn't consider some important > factor(s). In either case, I'd like to hear his POV on this before we > decide how to proceed. Let's go back to the known good state first, and then discuss how to go from there. > > > We need to mark the objects in all cases, not just when module > > assertions are enabled. > > If we get stack marking to work, we won't need to mark objects > explicitly. We can't get stack marking to work, even theoretically. A module is free to do emacs_value x = ...; uintptr_t y = ((uintrptr_t) x) ^ 0x123456u; (garbage-collect) emacs_value z = (emacs_value) (y ^ 0x123456u); ... use z ... During the garbage collection, x isn't on the stack anywhere, and the garbage collector couldn't possibly find it. Or: emacs_value x = ...; emacs_value *y = malloc (sizeof emacs_value); *y = x; ... stop using x... (garbage-collect) ...use *y ... Again, during garbage collection x is no longer on the stack. We can only use stack scanning in Emacs because we control the Emacs source code and can make sure these patterns don't occur. Module code is completely arbitrary. > > > Note that both the designer of the module API (Daniel) and I as one of > > its main implementers disagree with commit > > 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a. > > OK, but I think Stefan's opinion is not less important. I value his opinion, but again: let's make the thing work first, and then discuss options. > > > I've already confirmed that reverting commit > > 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a fixes bug#31238, and I can > > try it with this bug as well. > > Please do, it's important to know that, I think. Basil, could you check that with the revert your code now works? Thanks! ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#34655: 26.1.92; Segfault in module with --module-assertions 2019-03-21 19:37 ` Philipp Stephani @ 2019-03-21 19:50 ` Eli Zaretskii 2019-03-21 20:01 ` Philipp Stephani 2019-03-21 21:31 ` Basil L. Contovounesios 1 sibling, 1 reply; 32+ messages in thread From: Eli Zaretskii @ 2019-03-21 19:50 UTC (permalink / raw) To: Philipp Stephani; +Cc: contovob, 34655, monnier > From: Philipp Stephani <p.stephani2@gmail.com> > Date: Thu, 21 Mar 2019 20:37:24 +0100 > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, "Basil L. Contovounesios" <contovob@tcd.ie>, 34655@debbugs.gnu.org > > Let's go back to the known good state first, and then discuss how to > go from there. I don't see why that is better than discuss first and then go to where we decide to go. It's not like Emacs 27 will be released any time soon, so there's no rush. > We can't get stack marking to work, even theoretically. > > A module is free to do > > emacs_value x = ...; > uintptr_t y = ((uintrptr_t) x) ^ 0x123456u; > (garbage-collect) > emacs_value z = (emacs_value) (y ^ 0x123456u); > ... use z ... > > During the garbage collection, x isn't on the stack anywhere Why do you think x isn't on the stack in this case? Moreover, emacs_value is actually a pointer to a Lisp object, so this object is also somewhere on the stack, right? > emacs_value x = ...; > emacs_value *y = malloc (sizeof emacs_value); > *y = x; > ... stop using x... > (garbage-collect) > ...use *y ... > > Again, during garbage collection x is no longer on the stack. Why do you think it isn't on the stack? > We can only use stack scanning in Emacs because we control the Emacs > source code Actually, we do nothing special about stack-based values in our sources, except avoiding undefined behavior. > > OK, but I think Stefan's opinion is not less important. > > I value his opinion, but again: let's make the thing work first, and > then discuss options. Fixing one bug doesn't necessarily mean things now "work"; there's always one more bug. ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#34655: 26.1.92; Segfault in module with --module-assertions 2019-03-21 19:50 ` Eli Zaretskii @ 2019-03-21 20:01 ` Philipp Stephani 2019-03-21 20:14 ` Eli Zaretskii 0 siblings, 1 reply; 32+ messages in thread From: Philipp Stephani @ 2019-03-21 20:01 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Basil L. Contovounesios, 34655, Stefan Monnier Am Do., 21. März 2019 um 20:50 Uhr schrieb Eli Zaretskii <eliz@gnu.org>: > > > From: Philipp Stephani <p.stephani2@gmail.com> > > Date: Thu, 21 Mar 2019 20:37:24 +0100 > > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, "Basil L. Contovounesios" <contovob@tcd.ie>, 34655@debbugs.gnu.org > > > > Let's go back to the known good state first, and then discuss how to > > go from there. > > I don't see why that is better than discuss first and then go to where > we decide to go. It's not like Emacs 27 will be released any time > soon, so there's no rush. For one, it becomes harder and harder to revert commits the older they get. Also such discussions tend to turn into endless debates about the "perfect" solution until one side gives up, without improving anything. I strongly prefer fixing actual bugs that affect users in practice and then discussing (or not discussing) the gold-plating steps later. > > > We can't get stack marking to work, even theoretically. > > > > A module is free to do > > > > emacs_value x = ...; > > uintptr_t y = ((uintrptr_t) x) ^ 0x123456u; > > (garbage-collect) > > emacs_value z = (emacs_value) (y ^ 0x123456u); > > ... use z ... > > > > During the garbage collection, x isn't on the stack anywhere > > Why do you think x isn't on the stack in this case? Because the compiler reused the stack slot for something else? Because the module is written in a language that doesn't use the stack in a way that the garbage collector expects? There's no reason to assume modules have any form of C-compatible stack layout. > > Moreover, emacs_value is actually a pointer to a Lisp object, so this > object is also somewhere on the stack, right? > > > emacs_value x = ...; > > emacs_value *y = malloc (sizeof emacs_value); > > *y = x; > > ... stop using x... > > (garbage-collect) > > ...use *y ... > > > > Again, during garbage collection x is no longer on the stack. > > Why do you think it isn't on the stack? Same as above. > > > We can only use stack scanning in Emacs because we control the Emacs > > source code > > Actually, we do nothing special about stack-based values in our > sources, except avoiding undefined behavior. (Stack scanning is undefined behavior, but that's not the point.) We do something very specific with the stack: we make sure that Lisp_Objects are never manipulated in a way similar to the above, and we use the C language. > > > > OK, but I think Stefan's opinion is not less important. > > > > I value his opinion, but again: let's make the thing work first, and > > then discuss options. > > Fixing one bug doesn't necessarily mean things now "work"; there's > always one more bug. That might be theoretically true, but shouldn't impact decisions until that bug is actually found. All regression tests still pass after reverting the commit. ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#34655: 26.1.92; Segfault in module with --module-assertions 2019-03-21 20:01 ` Philipp Stephani @ 2019-03-21 20:14 ` Eli Zaretskii 2019-03-21 20:26 ` Philipp Stephani 0 siblings, 1 reply; 32+ messages in thread From: Eli Zaretskii @ 2019-03-21 20:14 UTC (permalink / raw) To: Philipp Stephani; +Cc: contovob, 34655, monnier > From: Philipp Stephani <p.stephani2@gmail.com> > Date: Thu, 21 Mar 2019 21:01:43 +0100 > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, "Basil L. Contovounesios" <contovob@tcd.ie>, 34655@debbugs.gnu.org, > Daniel Colascione <dancol@dancol.org> > > Am Do., 21. März 2019 um 20:50 Uhr schrieb Eli Zaretskii <eliz@gnu.org>: > > > > > From: Philipp Stephani <p.stephani2@gmail.com> > > > Date: Thu, 21 Mar 2019 20:37:24 +0100 > > > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, "Basil L. Contovounesios" <contovob@tcd.ie>, 34655@debbugs.gnu.org > > > > > > Let's go back to the known good state first, and then discuss how to > > > go from there. > > > > I don't see why that is better than discuss first and then go to where > > we decide to go. It's not like Emacs 27 will be released any time > > soon, so there's no rush. > > For one, it becomes harder and harder to revert commits the older they > get. Also such discussions tend to turn into endless debates about the > "perfect" solution until one side gives up, without improving > anything. I strongly prefer fixing actual bugs that affect users in > practice and then discussing (or not discussing) the gold-plating > steps later. I also prefer fixing bugs (which is why I spent several hours looking into Basil's crash, when no one else was replying to that bug report), but this is a community project, so we should discuss first and act later. Especially when controversial issues are involved. > > > We can't get stack marking to work, even theoretically. > > > > > > A module is free to do > > > > > > emacs_value x = ...; > > > uintptr_t y = ((uintrptr_t) x) ^ 0x123456u; > > > (garbage-collect) > > > emacs_value z = (emacs_value) (y ^ 0x123456u); > > > ... use z ... > > > > > > During the garbage collection, x isn't on the stack anywhere > > > > Why do you think x isn't on the stack in this case? > > Because the compiler reused the stack slot for something else? How can it? You are using the same pointer later. Garbage collection cannot happen unless you call an Emacs function, such as Ffuncall. Calling a function means that even if the pointer to a Lisp object was in a register, it will be put on the stack when calling Emacs. > Because the module is written in a language that doesn't use the stack > in a way that the garbage collector expects? Which language is that, and how can it use the emacs-module machinery? > > Moreover, emacs_value is actually a pointer to a Lisp object, so this > > object is also somewhere on the stack, right? No answer? > We do something very specific with the stack: we make sure that > Lisp_Objects are never manipulated in a way similar to the above, and > we use the C language. If worse comes to worst, we can request module writers to adhere to the same discipline. We already request them to do/not to do quite a few extraordinary things. > All regression tests still pass after reverting the commit. Didn't they also pass before? ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#34655: 26.1.92; Segfault in module with --module-assertions 2019-03-21 20:14 ` Eli Zaretskii @ 2019-03-21 20:26 ` Philipp Stephani 2019-03-21 20:44 ` Eli Zaretskii 2019-03-21 20:48 ` Daniel Colascione 0 siblings, 2 replies; 32+ messages in thread From: Philipp Stephani @ 2019-03-21 20:26 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Basil L. Contovounesios, 34655, Stefan Monnier Am Do., 21. März 2019 um 21:14 Uhr schrieb Eli Zaretskii <eliz@gnu.org>: > > > From: Philipp Stephani <p.stephani2@gmail.com> > > Date: Thu, 21 Mar 2019 21:01:43 +0100 > > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, "Basil L. Contovounesios" <contovob@tcd.ie>, 34655@debbugs.gnu.org, > > Daniel Colascione <dancol@dancol.org> > > > > Am Do., 21. März 2019 um 20:50 Uhr schrieb Eli Zaretskii <eliz@gnu.org>: > > > > > > > From: Philipp Stephani <p.stephani2@gmail.com> > > > > Date: Thu, 21 Mar 2019 20:37:24 +0100 > > > > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, "Basil L. Contovounesios" <contovob@tcd.ie>, 34655@debbugs.gnu.org > > > > > > > > Let's go back to the known good state first, and then discuss how to > > > > go from there. > > > > > > I don't see why that is better than discuss first and then go to where > > > we decide to go. It's not like Emacs 27 will be released any time > > > soon, so there's no rush. > > > > For one, it becomes harder and harder to revert commits the older they > > get. Also such discussions tend to turn into endless debates about the > > "perfect" solution until one side gives up, without improving > > anything. I strongly prefer fixing actual bugs that affect users in > > practice and then discussing (or not discussing) the gold-plating > > steps later. > > I also prefer fixing bugs (which is why I spent several hours looking > into Basil's crash, when no one else was replying to that bug report), > but this is a community project, so we should discuss first and act > later. Especially when controversial issues are involved. Well, as you can see, these discussions seem to lead nowhere, and both bug#34655 and bug#31238 remain unfixed. > > > > > We can't get stack marking to work, even theoretically. > > > > > > > > A module is free to do > > > > > > > > emacs_value x = ...; > > > > uintptr_t y = ((uintrptr_t) x) ^ 0x123456u; > > > > (garbage-collect) > > > > emacs_value z = (emacs_value) (y ^ 0x123456u); > > > > ... use z ... > > > > > > > > During the garbage collection, x isn't on the stack anywhere > > > > > > Why do you think x isn't on the stack in this case? > > > > Because the compiler reused the stack slot for something else? > > How can it? You are using the same pointer later. Assume I don't use x later, and only y is on the stack during GC. > Garbage collection > cannot happen unless you call an Emacs function, such as Ffuncall. > Calling a function means that even if the pointer to a Lisp object was > in a register, it will be put on the stack when calling Emacs. No matter whether y here is in a register or on the stack, it's not a Lisp_Value, so the GC can't find it. > > > Because the module is written in a language that doesn't use the stack > > in a way that the garbage collector expects? > > Which language is that, and how can it use the emacs-module machinery? Go, for example. It uses green threads with its own stack management and calling conventions. The GC couldn't ever find such a stack. > > > > Moreover, emacs_value is actually a pointer to a Lisp object, so this > > > object is also somewhere on the stack, right? > > No answer? An emacs_value in the current implementation *is* a Lisp_Object cast to emacs_value. If the emacs_value is not on the stack, then there's no way to find the Lisp_Object. > > > We do something very specific with the stack: we make sure that > > Lisp_Objects are never manipulated in a way similar to the above, and > > we use the C language. > > If worse comes to worst, we can request module writers to adhere to > the same discipline. We already request them to do/not to do quite a > few extraordinary things. No we can't. Modules can contain arbitrary code and call arbitrary libraries, which we can't ever control. We need to work with everything that provides a C-compatible interface. > > > All regression tests still pass after reverting the commit. > > Didn't they also pass before? Yes, but the reproduction steps in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31238 didn't. ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#34655: 26.1.92; Segfault in module with --module-assertions 2019-03-21 20:26 ` Philipp Stephani @ 2019-03-21 20:44 ` Eli Zaretskii 2019-03-21 20:48 ` Daniel Colascione 1 sibling, 0 replies; 32+ messages in thread From: Eli Zaretskii @ 2019-03-21 20:44 UTC (permalink / raw) To: Philipp Stephani; +Cc: contovob, 34655, monnier > From: Philipp Stephani <p.stephani2@gmail.com> > Date: Thu, 21 Mar 2019 21:26:25 +0100 > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, "Basil L. Contovounesios" <contovob@tcd.ie>, 34655@debbugs.gnu.org, > Daniel Colascione <dancol@dancol.org> > > > I also prefer fixing bugs (which is why I spent several hours looking > > into Basil's crash, when no one else was replying to that bug report), > > but this is a community project, so we should discuss first and act > > later. Especially when controversial issues are involved. > > Well, as you can see, these discussions seem to lead nowhere, and both > bug#34655 and bug#31238 remain unfixed. We have been talking about this just a few minutes, so please don't exaggerate. And bug#34655 could be fixed days ago, it isn't yet because I wanted to hear your opinion, and you asked me to hold off the changes. > > > > Why do you think x isn't on the stack in this case? > > > > > > Because the compiler reused the stack slot for something else? > > > > How can it? You are using the same pointer later. > > Assume I don't use x later, and only y is on the stack during GC. If you don't use x, it can be GC'ed. > > Garbage collection > > cannot happen unless you call an Emacs function, such as Ffuncall. > > Calling a function means that even if the pointer to a Lisp object was > > in a register, it will be put on the stack when calling Emacs. > > No matter whether y here is in a register or on the stack, it's not a > Lisp_Value, so the GC can't find it. But x is. And there's the original Lisp object too, somewhere on the stack. > > > Because the module is written in a language that doesn't use the stack > > > in a way that the garbage collector expects? > > > > Which language is that, and how can it use the emacs-module machinery? > > Go, for example. It uses green threads with its own stack management > and calling conventions. The GC couldn't ever find such a stack. So you are saying that Emacs modules cannot be written in Go? > > > > Moreover, emacs_value is actually a pointer to a Lisp object, so this > > > > object is also somewhere on the stack, right? > > > > No answer? > > An emacs_value in the current implementation *is* a Lisp_Object cast > to emacs_value. Under module-assertions, it's a pointer to a (copy of a) Lisp object. > > If worse comes to worst, we can request module writers to adhere to > > the same discipline. We already request them to do/not to do quite a > > few extraordinary things. > > No we can't. Modules can contain arbitrary code and call arbitrary > libraries, which we can't ever control. We need to work with > everything that provides a C-compatible interface. Emacs modules are written to work with Emacs, so surely we can request them to observe certain rules, especially if they don't want to crash Emacs. ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#34655: 26.1.92; Segfault in module with --module-assertions 2019-03-21 20:26 ` Philipp Stephani 2019-03-21 20:44 ` Eli Zaretskii @ 2019-03-21 20:48 ` Daniel Colascione 2019-03-22 8:17 ` Eli Zaretskii 1 sibling, 1 reply; 32+ messages in thread From: Daniel Colascione @ 2019-03-21 20:48 UTC (permalink / raw) To: Philipp Stephani; +Cc: Basil L. Contovounesios, 34655, Stefan Monnier > Am Do., 21. März 2019 um 21:14 Uhr schrieb Eli Zaretskii <eliz@gnu.org>: >> >> > From: Philipp Stephani <p.stephani2@gmail.com> >> > Date: Thu, 21 Mar 2019 21:01:43 +0100 >> > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, "Basil L. >> Contovounesios" <contovob@tcd.ie>, 34655@debbugs.gnu.org, >> > Daniel Colascione <dancol@dancol.org> >> > >> > Am Do., 21. März 2019 um 20:50 Uhr schrieb Eli Zaretskii >> <eliz@gnu.org>: >> > > >> > > > From: Philipp Stephani <p.stephani2@gmail.com> >> > > > Date: Thu, 21 Mar 2019 20:37:24 +0100 >> > > > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, "Basil L. >> Contovounesios" <contovob@tcd.ie>, 34655@debbugs.gnu.org >> > > > >> > > > Let's go back to the known good state first, and then discuss how >> to >> > > > go from there. >> > > >> > > I don't see why that is better than discuss first and then go to >> where >> > > we decide to go. It's not like Emacs 27 will be released any time >> > > soon, so there's no rush. >> > >> > For one, it becomes harder and harder to revert commits the older they >> > get. Also such discussions tend to turn into endless debates about the >> > "perfect" solution until one side gives up, without improving >> > anything. I strongly prefer fixing actual bugs that affect users in >> > practice and then discussing (or not discussing) the gold-plating >> > steps later. >> >> I also prefer fixing bugs (which is why I spent several hours looking >> into Basil's crash, when no one else was replying to that bug report), >> but this is a community project, so we should discuss first and act >> later. Especially when controversial issues are involved. > > Well, as you can see, these discussions seem to lead nowhere, and both > bug#34655 and bug#31238 remain unfixed. > >> >> > > > We can't get stack marking to work, even theoretically. >> > > > >> > > > A module is free to do >> > > > >> > > > emacs_value x = ...; >> > > > uintptr_t y = ((uintrptr_t) x) ^ 0x123456u; >> > > > (garbage-collect) >> > > > emacs_value z = (emacs_value) (y ^ 0x123456u); >> > > > ... use z ... >> > > > >> > > > During the garbage collection, x isn't on the stack anywhere >> > > >> > > Why do you think x isn't on the stack in this case? >> > >> > Because the compiler reused the stack slot for something else? >> >> How can it? You are using the same pointer later. > > Assume I don't use x later, and only y is on the stack during GC. > >> Garbage collection >> cannot happen unless you call an Emacs function, such as Ffuncall. >> Calling a function means that even if the pointer to a Lisp object was >> in a register, it will be put on the stack when calling Emacs. > > No matter whether y here is in a register or on the stack, it's not a > Lisp_Value, so the GC can't find it. > >> >> > Because the module is written in a language that doesn't use the stack >> > in a way that the garbage collector expects? >> >> Which language is that, and how can it use the emacs-module machinery? > > Go, for example. It uses green threads with its own stack management > and calling conventions. The GC couldn't ever find such a stack. > >> >> > > Moreover, emacs_value is actually a pointer to a Lisp object, so >> this >> > > object is also somewhere on the stack, right? >> >> No answer? > > An emacs_value in the current implementation *is* a Lisp_Object cast > to emacs_value. If the emacs_value is not on the stack, then there's > no way to find the Lisp_Object. > >> >> > We do something very specific with the stack: we make sure that >> > Lisp_Objects are never manipulated in a way similar to the above, and >> > we use the C language. >> >> If worse comes to worst, we can request module writers to adhere to >> the same discipline. We already request them to do/not to do quite a >> few extraordinary things. > > No we can't. Modules can contain arbitrary code and call arbitrary > libraries, which we can't ever control. We need to work with > everything that provides a C-compatible interface. Modules can contain arbitrary code, but they don't have to do arbitrary things with that code. Right now, the contract between modules and Emacs is something like "any value that, I, Emacs, can't find on an Emacs-findable thread is fair game for memory reclaimation." In practice, that works okay most of the time, but if we have to deal with environments that can't guarantee that Emacs values remain on the C stack, we can extend the contract with something like "I, module, am handing you, Emacs, an array of emacs_values, and in addition to my stack, you should check this array before considering a value dead" --- that is, we could just provide a way for a module to associate a bunch of additional GC roots with a given context. Then something like Go could stick any temporary Emacs values in this array. Or we could just have these environments create permanent references. ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#34655: 26.1.92; Segfault in module with --module-assertions 2019-03-21 20:48 ` Daniel Colascione @ 2019-03-22 8:17 ` Eli Zaretskii 0 siblings, 0 replies; 32+ messages in thread From: Eli Zaretskii @ 2019-03-22 8:17 UTC (permalink / raw) To: Daniel Colascione; +Cc: contovob, 34655, p.stephani2, monnier > Date: Thu, 21 Mar 2019 13:48:28 -0700 > From: "Daniel Colascione" <dancol@dancol.org> > Cc: "Eli Zaretskii" <eliz@gnu.org>, > "Stefan Monnier" <monnier@iro.umontreal.ca>, > "Basil L. Contovounesios" <contovob@tcd.ie>, > 34655@debbugs.gnu.org, > "Daniel Colascione" <dancol@dancol.org> > > > No we can't. Modules can contain arbitrary code and call arbitrary > > libraries, which we can't ever control. We need to work with > > everything that provides a C-compatible interface. > > Modules can contain arbitrary code, but they don't have to do arbitrary > things with that code. Right now, the contract between modules and Emacs > is something like "any value that, I, Emacs, can't find on an > Emacs-findable thread is fair game for memory reclaimation." In practice, > that works okay most of the time, but if we have to deal with environments > that can't guarantee that Emacs values remain on the C stack, we can > extend the contract with something like "I, module, am handing you, Emacs, > an array of emacs_values, and in addition to my stack, you should check > this array before considering a value dead" --- that is, we could just > provide a way for a module to associate a bunch of additional GC roots > with a given context. Then something like Go could stick any temporary > Emacs values in this array. > > Or we could just have these environments create permanent references. OK, thanks. What are your opinions regarding usability of stack marking for emacs_value variables used by modules? ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#34655: 26.1.92; Segfault in module with --module-assertions 2019-03-21 19:37 ` Philipp Stephani 2019-03-21 19:50 ` Eli Zaretskii @ 2019-03-21 21:31 ` Basil L. Contovounesios 1 sibling, 0 replies; 32+ messages in thread From: Basil L. Contovounesios @ 2019-03-21 21:31 UTC (permalink / raw) To: Philipp Stephani; +Cc: 34655, Stefan Monnier Philipp Stephani <p.stephani2@gmail.com> writes: > Am Do., 21. März 2019 um 20:27 Uhr schrieb Eli Zaretskii <eliz@gnu.org>: >> >> > I've already confirmed that reverting commit >> > 3eb93c07f7a60ac9ce8a16f10c3afd5a3a31243a fixes bug#31238, and I can >> > try it with this bug as well. >> >> Please do, it's important to know that, I think. > > Basil, could you check that with the revert your code now works? Thanks! The revert indeed makes bug#34655 go away. Thanks, -- Basil ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#34655: 26.1.92; Segfault in module with --module-assertions 2019-03-21 19:27 ` Eli Zaretskii 2019-03-21 19:37 ` Philipp Stephani @ 2019-03-22 0:56 ` Stefan Monnier 2019-03-22 8:16 ` Eli Zaretskii 1 sibling, 1 reply; 32+ messages in thread From: Stefan Monnier @ 2019-03-22 0:56 UTC (permalink / raw) To: Eli Zaretskii; +Cc: contovob, 34655, Philipp Stephani > OK, but I think Stefan's opinion is not less important. I think the module API is already so completely different from what I'd like it to be that it's OK to revert my change here. Stefan ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#34655: 26.1.92; Segfault in module with --module-assertions 2019-03-22 0:56 ` Stefan Monnier @ 2019-03-22 8:16 ` Eli Zaretskii 0 siblings, 0 replies; 32+ messages in thread From: Eli Zaretskii @ 2019-03-22 8:16 UTC (permalink / raw) To: Stefan Monnier; +Cc: contovob, 34655, p.stephani2 merge 31238 34655 close 34655 thanks > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: Philipp Stephani <p.stephani2@gmail.com>, contovob@tcd.ie, 34655@debbugs.gnu.org > Date: Thu, 21 Mar 2019 20:56:17 -0400 > > > OK, but I think Stefan's opinion is not less important. > > I think the module API is already so completely different from what I'd > like it to be that it's OK to revert my change here. OK, so I reverted my revert, and I'm marking this bug done. Thanks. ^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2019-03-22 8:17 UTC | newest] Thread overview: 32+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-02-25 21:00 bug#34655: 26.1.92; Segfault in module with --module-assertions Basil L. Contovounesios 2019-02-26 2:59 ` Richard Stallman 2019-02-26 11:16 ` Basil L. Contovounesios 2019-02-26 15:27 ` Eli Zaretskii 2019-02-26 18:42 ` Basil L. Contovounesios 2019-02-27 4:10 ` Richard Stallman 2019-02-26 15:45 ` Eli Zaretskii 2019-03-17 16:38 ` Basil L. Contovounesios 2019-03-17 17:08 ` Eli Zaretskii 2019-03-17 23:52 ` Basil L. Contovounesios 2019-03-18 16:21 ` Eli Zaretskii 2019-03-18 16:58 ` Basil L. Contovounesios 2019-03-18 17:53 ` Eli Zaretskii 2019-03-21 16:11 ` Philipp Stephani 2019-03-21 17:00 ` Eli Zaretskii 2019-03-21 18:28 ` Philipp Stephani 2019-03-21 19:23 ` Philipp Stephani 2019-03-21 19:34 ` Eli Zaretskii 2019-03-21 21:29 ` Basil L. Contovounesios 2019-03-22 7:11 ` Eli Zaretskii 2019-03-21 19:27 ` Eli Zaretskii 2019-03-21 19:37 ` Philipp Stephani 2019-03-21 19:50 ` Eli Zaretskii 2019-03-21 20:01 ` Philipp Stephani 2019-03-21 20:14 ` Eli Zaretskii 2019-03-21 20:26 ` Philipp Stephani 2019-03-21 20:44 ` Eli Zaretskii 2019-03-21 20:48 ` Daniel Colascione 2019-03-22 8:17 ` Eli Zaretskii 2019-03-21 21:31 ` Basil L. Contovounesios 2019-03-22 0:56 ` Stefan Monnier 2019-03-22 8:16 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).