* 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-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: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-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 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: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: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 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 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-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-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
* 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
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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.