Package: emacs;
Reported by: Valentin Gatien-Baron <vgatien-baron <at> janestreet.com>
Date: Mon, 30 Oct 2017 15:34:01 UTC
Severity: normal
Found in version 26.0.90
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 29066 in the body.
You can then email your comments to 29066 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-gnu-emacs <at> gnu.org:bug#29066; Package emacs.
(Mon, 30 Oct 2017 15:34:01 GMT) Full text and rfc822 format available.Valentin Gatien-Baron <vgatien-baron <at> janestreet.com>:bug-gnu-emacs <at> gnu.org.
(Mon, 30 Oct 2017 15:34:02 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Valentin Gatien-Baron <vgatien-baron <at> janestreet.com> To: bug-gnu-emacs <at> gnu.org Cc: Mark Shinwell <mshinwell <at> janestreet.com> Subject: 26.0.90; crash in gc involving buffer local symbols Date: Mon, 30 Oct 2017 10:36:41 -0400
[Message part 1 (text/plain, inline)]
The following invocation of emacs aborts with double-free:
$ installed/bin/emacs -Q -L . -batch --eval '(progn (message "before")
(make-local-variable (make-symbol "\
s")) (kill-buffer) (garbage-collect) (garbage-collect) (message "after"))'
before
*** Error in `installed/bin/emacs': double free or corruption (!prev):
0x00000000014bff10 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x7c619)[0x7efd02c32619]
installed/bin/emacs[0x4e3fa1]
installed/bin/emacs[0x4e917a]
installed/bin/emacs[0x5006bc]
installed/bin/emacs[0x500780]
installed/bin/emacs[0x500439]
installed/bin/emacs[0x503d30]
installed/bin/emacs[0x500de6]
installed/bin/emacs[0x538e31]
installed/bin/emacs[0x500d63]
installed/bin/emacs[0x538e31]
installed/bin/emacs[0x500d63]
installed/bin/emacs[0x538e31]
installed/bin/emacs[0x4ffe73]
installed/bin/emacs[0x5001a7]
installed/bin/emacs[0x503d30]
installed/bin/emacs[0x4ff454]
installed/bin/emacs[0x49093c]
installed/bin/emacs[0x4ff404]
installed/bin/emacs[0x48e446]
installed/bin/emacs[0x4928fe]
installed/bin/emacs[0x492c15]
installed/bin/emacs[0x406df3]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7efd02bd7c05]
installed/bin/emacs[0x4079de]
In emacs-26, running this in gdb prevents the error so I don't have a
backtrace (though I have seen such a backtrace on a different machine
with different build options for emacs). In emacs 25.2, though, the
same error happens and there the backtrace is:
(gdb) bt full
#0 0x00007ffff20a11f7 in raise () from /lib64/libc.so.6
No symbol table info available.
#1 0x00007ffff20a28e8 in abort () from /lib64/libc.so.6
No symbol table info available.
#2 0x00007ffff20e0f47 in __libc_message () from /lib64/libc.so.6
No symbol table info available.
#3 0x00007ffff20e8619 in _int_free () from /lib64/libc.so.6
No symbol table info available.
#4 0x00000000005358d1 in sweep_symbols () at alloc.c:6839
this_free = <optimized out>
sym = 0xd667b0
end = 0xd667e0
sblk = 0xd66720
sprev = <optimized out>
lim = <optimized out>
num_free = <optimized out>
num_used = 1087
#5 0x000000000053b76a in gc_sweep () at alloc.c:6982
No locals.
#6 garbage_collect_1 (end=<optimized out>) at alloc.c:5799
nextb = <optimized out>
stack_top_variable = 0 '\000'
i = <optimized out>
message_p = false
count = <optimized out>
start = {tv_sec = 1509372540, tv_nsec = 974388982}
retval = 0
tot_before = 0
total = {12342819, 12341875, 12341619, 12341299, 12340147,
12340035, 12339907, 12339715,
12339571, 12337939, 12337091}
#7 0x000000000053c0d9 in Fgarbage_collect () at alloc.c:5983
end = 0x7fffffffd348
#8 0x0000000000551c2b in eval_sub (form=<optimized out>) at eval.c:2169
i = <optimized out>
maxargs = 0
args_left = 0
numargs = <optimized out>
fun = 11669013
val = <optimized out>
original_fun = <optimized out>
original_args = 0
funcar = <optimized out>
count = 13
argvals = {0, 0, 12067264, 0, 14009168, 176093659181, 0, 40}
#9 0x0000000000551ead in Fprogn (body=16724163) at eval.c:431
val = <optimized out>
#10 0x0000000000551b11 in eval_sub (form=<optimized out>) at eval.c:2125
args_left = 16725811
numargs = <optimized out>
fun = 11695045
val = <optimized out>
original_fun = 37680
original_args = 16725811
funcar = <optimized out>
count = 12
argvals = {0, 0, 12274656, 4611686019484352512, 1, 4599230,
20285716, 5508133}
#11 0x0000000000553712 in Feval (form=16725891, lexical=<optimized out>) at
eval.c:1994
count = 11
#12 0x0000000000552648 in Ffuncall (nargs=<optimized out>,
args=0x7fffffffd588) at eval.c:2702
internal_argbuf = {16725891, 0, 0, 4599230, 9895560, 5508133, 22,
9893584}
fun = 11696197
original_fun = <optimized out>
funcar = <optimized out>
numargs = <optimized out>
lisp_numargs = 6
val = <optimized out>
internal_args = 0x7fffffffd590
count = 10
#13 0x000000000058941d in exec_byte_code (bytestr=<optimized out>,
vector=9893581,
maxdepth=<optimized out>, args_template=<optimized out>,
nargs=<optimized out>, args=<optimized out>)
at bytecode.c:880
targets = {0x5894ba <exec_byte_code+874>, 0x58b452
<exec_byte_code+8962>,
0x58b457 <exec_byte_code+8967>, 0x58b45c <exec_byte_code+8972>,
0x589282 <exec_byte_code+306>,
0x589288 <exec_byte_code+312>, 0x58952e <exec_byte_code+990>,
0x5895ad <exec_byte_code+1117>,
0x5895a3 <exec_byte_code+1107>, 0x5895a8 <exec_byte_code+1112>,
0x589573 <exec_byte_code+1059>,
0x589578 <exec_byte_code+1064>, 0x5892c1 <exec_byte_code+369>,
0x5892c8 <exec_byte_code+376>,
0x5896e9 <exec_byte_code+1433>, 0x58957d <exec_byte_code+1069>,
0x589908 <exec_byte_code+1976>,
0x58990d <exec_byte_code+1981>, 0x589879 <exec_byte_code+1833>,
0x58987e <exec_byte_code+1838>,
0x589334 <exec_byte_code+484>, 0x589338 <exec_byte_code+488>,
0x589820 <exec_byte_code+1744>,
0x5897fa <exec_byte_code+1706>, 0x5896ae <exec_byte_code+1374>,
0x5896b3 <exec_byte_code+1379>,
0x5896b8 <exec_byte_code+1384>, 0x5896c5 <exec_byte_code+1397>,
0x5893b4 <exec_byte_code+612>,
0x5893b8 <exec_byte_code+616>, 0x589865 <exec_byte_code+1813>,
0x589688 <exec_byte_code+1336>,
0x589679 <exec_byte_code+1321>, 0x58967e <exec_byte_code+1326>,
0x589683 <exec_byte_code+1331>,
0x58964e <exec_byte_code+1278>, 0x5893f9 <exec_byte_code+681>,
0x589400 <exec_byte_code+688>,
0x5896d5 <exec_byte_code+1413>, 0x589653 <exec_byte_code+1283>,
0x58a53f <exec_byte_code+5103>,
---Type <return> to continue, or q <return> to quit---
0x58a544 <exec_byte_code+5108>, 0x58a549 <exec_byte_code+5113>,
0x58a514 <exec_byte_code+5060>,
0x589443 <exec_byte_code+755>, 0x589448 <exec_byte_code+760>,
0x58a4d6 <exec_byte_code+4998>,
0x58a519 <exec_byte_code+5065>, 0x58a944 <exec_byte_code+6132>,
0x58a77d <exec_byte_code+5677>,
0x58a70b <exec_byte_code+5563>, 0x5894ba <exec_byte_code+874>,
0x5894ba <exec_byte_code+874>,
0x5894ba <exec_byte_code+874>, 0x5894ba <exec_byte_code+874>,
0x5894ba <exec_byte_code+874>,
0x589d04 <exec_byte_code+2996>, 0x589d90 <exec_byte_code+3136>,
0x589dc7 <exec_byte_code+3191>,
0x589e01 <exec_byte_code+3249>, 0x589e3b <exec_byte_code+3307>,
0x5897bb <exec_byte_code+1643>,
0x589883 <exec_byte_code+1843>, 0x589e81 <exec_byte_code+3377>,
0x589773 <exec_byte_code+1571>,
0x5898c0 <exec_byte_code+1904>, 0x589eb3 <exec_byte_code+3427>,
0x589ef0 <exec_byte_code+3488>,
0x589f22 <exec_byte_code+3538>, 0x589f5f <exec_byte_code+3599>,
0x589f98 <exec_byte_code+3656>,
0x58a022 <exec_byte_code+3794>, 0x58a054 <exec_byte_code+3844>,
0x58a091 <exec_byte_code+3905>,
0x58a0dc <exec_byte_code+3980>, 0x58a10e <exec_byte_code+4030>,
0x58a140 <exec_byte_code+4080>,
0x58a17d <exec_byte_code+4141>, 0x58a1ba <exec_byte_code+4202>,
0x58a1f7 <exec_byte_code+4263>,
0x58a23e <exec_byte_code+4334>, 0x58a277 <exec_byte_code+4391>,
0x58a2b0 <exec_byte_code+4448>,
0x58a33d <exec_byte_code+4589>, 0x58a380 <exec_byte_code+4656>,
0x58a3c7 <exec_byte_code+4727>,
0x58a494 <exec_byte_code+4932>, 0x58a410 <exec_byte_code+4800>,
0x58a452 <exec_byte_code+4866>,
0x589bb4 <exec_byte_code+2660>, 0x589bf6 <exec_byte_code+2726>,
0x589c2f <exec_byte_code+2783>,
0x589c71 <exec_byte_code+2849>, 0x58b195 <exec_byte_code+8261>,
0x58b1ce <exec_byte_code+8318>,
0x58b207 <exec_byte_code+8375>, 0x58afea <exec_byte_code+7834>,
0x589489 <exec_byte_code+825>,
0x58b02b <exec_byte_code+7899>, 0x58b059 <exec_byte_code+7945>,
0x58b0e1 <exec_byte_code+8081>,
0x58b122 <exec_byte_code+8146>, 0x58b163 <exec_byte_code+8211>,
0x58ac6d <exec_byte_code+6941>,
0x58ac9d <exec_byte_code+6989>, 0x58accd <exec_byte_code+7037>,
0x58ad05 <exec_byte_code+7093>,
0x5894ba <exec_byte_code+874>, 0x58ad39 <exec_byte_code+7145>,
0x58ad69 <exec_byte_code+7193>,
0x58ad99 <exec_byte_code+7241>, 0x58adc9 <exec_byte_code+7289>,
0x58adf9 <exec_byte_code+7337>,
0x58ae29 <exec_byte_code+7385>, 0x589489 <exec_byte_code+825>,
0x5894ba <exec_byte_code+874>,
0x58ae5b <exec_byte_code+7435>, 0x58ae9d <exec_byte_code+7501>,
0x58aecf <exec_byte_code+7551>,
0x58af01 <exec_byte_code+7601>, 0x58af3e <exec_byte_code+7662>,
0x58af7b <exec_byte_code+7723>,
0x58ac0e <exec_byte_code+6846>, 0x58ac30 <exec_byte_code+6880>,
0x58b63e <exec_byte_code+9454>,
0x58b67b <exec_byte_code+9515>, 0x58b60e <exec_byte_code+9406>,
0x58b735 <exec_byte_code+9701>,
0x5894ba <exec_byte_code+874>, 0x58aada <exec_byte_code+6538>,
0x58a555 <exec_byte_code+5125>,
0x5896fd <exec_byte_code+1453>, 0x58a5e4 <exec_byte_code+5268>,
0x58a825 <exec_byte_code+5845>,
0x58a896 <exec_byte_code+5958>, 0x589b72 <exec_byte_code+2594>,
0x58a801 <exec_byte_code+5809>,
0x589834 <exec_byte_code+1764>, 0x5894fd <exec_byte_code+941>,
0x589912 <exec_byte_code+1986>,
0x58a698 <exec_byte_code+5448>, 0x58a6c9 <exec_byte_code+5497>,
0x58abbf <exec_byte_code+6767>,
0x58ab2d <exec_byte_code+6621>, 0x58ab74 <exec_byte_code+6692>,
0x589caa <exec_byte_code+2906>,
0x58a4ea <exec_byte_code+5018>, 0x58b6b8 <exec_byte_code+9576>,
0x58b703 <exec_byte_code+9651>,
0x58b465 <exec_byte_code+8981>, 0x58b497 <exec_byte_code+9031>,
0x58b4c9 <exec_byte_code+9081>,
0x58b4fb <exec_byte_code+9131>, 0x58b538 <exec_byte_code+9192>,
0x58b575 <exec_byte_code+9253>,
0x58b5b2 <exec_byte_code+9314>, 0x58b5ef <exec_byte_code+9375>,
0x58b279 <exec_byte_code+8489>,
0x58b2b6 <exec_byte_code+8550>, 0x58b2f3 <exec_byte_code+8611>,
0x58b325 <exec_byte_code+8661>,
0x58b362 <exec_byte_code+8722>, 0x58b39f <exec_byte_code+8783>,
0x58b3dc <exec_byte_code+8844>,
0x58b419 <exec_byte_code+8905>, 0x58b240 <exec_byte_code+8432>,
0x58afad <exec_byte_code+7773>,
0x589975 <exec_byte_code+2085>, 0x5899be <exec_byte_code+2158>,
0x5894ba <exec_byte_code+874>,
0x58a784 <exec_byte_code+5684>, 0x58aa0f <exec_byte_code+6335>,
0x58a975 <exec_byte_code+6181>,
0x58aa76 <exec_byte_code+6438>, 0x589adc <exec_byte_code+2444>,
0x589fd1 <exec_byte_code+3713>,
0x58a2e9 <exec_byte_code+4505>, 0x58b08d <exec_byte_code+7997>,
0x589606 <exec_byte_code+1206>,
0x5899f8 <exec_byte_code+2216>, 0x5894ba <exec_byte_code+874>,
0x5894ba <exec_byte_code+874>,
0x589a54 <exec_byte_code+2308>, 0x5894ba <exec_byte_code+874>,
0x5894ba <exec_byte_code+874>,
0x5894ba <exec_byte_code+874>, 0x5894ba <exec_byte_code+874>,
0x5894ba <exec_byte_code+874>,
0x5894ba <exec_byte_code+874>, 0x5894ba <exec_byte_code+874>,
0x5894ba <exec_byte_code+874>,
0x5894ba <exec_byte_code+874>, 0x589aa2 <exec_byte_code+2386>
<repeats 64 times>}
count = 8
op = 1
vectorp = 0x96f6d0 <pure+1225200>
stack = {
pc = 0xaaa4a8 <pure+2514888>
"\210\202L\003\016A权\317\001\313\347\350\016C\"\003\206m\001\n\211A\022\242\211\262\r\313\332\036D\322\003\003\003#)\266\203\203\211\001\006\n\327\313O\262\vڲ\001\351\352\006\f!!\262\v\211\203\252\001\314\016E\006\fC\"\026E\006\t\203\313\001\016E\262\n\202\313\001\006\t\203\301\001\006\t\006\v\006\vAB\241\210\006\tA\262\n\202\313\001\006\n\016EB\211\026E\262\n\210\202L\003\016A띃\367\001\352\002\206\340\001\n\211A\022\242!\351\001!\354\001!\203\355\001\211\262\002\355\002\313\332#\266\003\202L\003\016A\027\002\352\002\206\b\002\n\211A\022\242!\351\001!\355\001\313ډ$\266\003\202L\003\016",
<incomplete sequence \357\232>..., byte_string = 9893548,
byte_string_start = 0xaaa355 <pure+2514549> "\306
\210\b\203\021", next = 0x7fffffffd900}
top = 0x7fffffffd680
result = <optimized out>
type = <optimized out>
#14 0x00000000005523c3 in Ffuncall (nargs=<optimized out>,
args=0x7fffffffd818) at eval.c:2760
fun = <optimized out>
original_fun = 8587296
funcar = <optimized out>
numargs = <optimized out>
lisp_numargs = 6
val = <optimized out>
internal_args = <optimized out>
count = 7
#15 0x000000000058941d in exec_byte_code (bytestr=<optimized out>,
vector=9870557,
maxdepth=<optimized out>, args_template=<optimized out>,
nargs=<optimized out>, args=<optimized out>)
at bytecode.c:880
targets = {0x5894ba <exec_byte_code+874>, 0x58b452
<exec_byte_code+8962>,
0x58b457 <exec_byte_code+8967>, 0x58b45c <exec_byte_code+8972>,
0x589282 <exec_byte_code+306>,
0x589288 <exec_byte_code+312>, 0x58952e <exec_byte_code+990>,
0x5895ad <exec_byte_code+1117>,
0x5895a3 <exec_byte_code+1107>, 0x5895a8 <exec_byte_code+1112>,
0x589573 <exec_byte_code+1059>,
0x589578 <exec_byte_code+1064>, 0x5892c1 <exec_byte_code+369>,
0x5892c8 <exec_byte_code+376>,
0x5896e9 <exec_byte_code+1433>, 0x58957d <exec_byte_code+1069>,
0x589908 <exec_byte_code+1976>,
0x58990d <exec_byte_code+1981>, 0x589879 <exec_byte_code+1833>,
0x58987e <exec_byte_code+1838>,
---Type <return> to continue, or q <return> to quit---
0x589334 <exec_byte_code+484>, 0x589338 <exec_byte_code+488>,
0x589820 <exec_byte_code+1744>,
0x5897fa <exec_byte_code+1706>, 0x5896ae <exec_byte_code+1374>,
0x5896b3 <exec_byte_code+1379>,
0x5896b8 <exec_byte_code+1384>, 0x5896c5 <exec_byte_code+1397>,
0x5893b4 <exec_byte_code+612>,
0x5893b8 <exec_byte_code+616>, 0x589865 <exec_byte_code+1813>,
0x589688 <exec_byte_code+1336>,
0x589679 <exec_byte_code+1321>, 0x58967e <exec_byte_code+1326>,
0x589683 <exec_byte_code+1331>,
0x58964e <exec_byte_code+1278>, 0x5893f9 <exec_byte_code+681>,
0x589400 <exec_byte_code+688>,
0x5896d5 <exec_byte_code+1413>, 0x589653 <exec_byte_code+1283>,
0x58a53f <exec_byte_code+5103>,
0x58a544 <exec_byte_code+5108>, 0x58a549 <exec_byte_code+5113>,
0x58a514 <exec_byte_code+5060>,
0x589443 <exec_byte_code+755>, 0x589448 <exec_byte_code+760>,
0x58a4d6 <exec_byte_code+4998>,
0x58a519 <exec_byte_code+5065>, 0x58a944 <exec_byte_code+6132>,
0x58a77d <exec_byte_code+5677>,
0x58a70b <exec_byte_code+5563>, 0x5894ba <exec_byte_code+874>,
0x5894ba <exec_byte_code+874>,
0x5894ba <exec_byte_code+874>, 0x5894ba <exec_byte_code+874>,
0x5894ba <exec_byte_code+874>,
0x589d04 <exec_byte_code+2996>, 0x589d90 <exec_byte_code+3136>,
0x589dc7 <exec_byte_code+3191>,
0x589e01 <exec_byte_code+3249>, 0x589e3b <exec_byte_code+3307>,
0x5897bb <exec_byte_code+1643>,
0x589883 <exec_byte_code+1843>, 0x589e81 <exec_byte_code+3377>,
0x589773 <exec_byte_code+1571>,
0x5898c0 <exec_byte_code+1904>, 0x589eb3 <exec_byte_code+3427>,
0x589ef0 <exec_byte_code+3488>,
0x589f22 <exec_byte_code+3538>, 0x589f5f <exec_byte_code+3599>,
0x589f98 <exec_byte_code+3656>,
0x58a022 <exec_byte_code+3794>, 0x58a054 <exec_byte_code+3844>,
0x58a091 <exec_byte_code+3905>,
0x58a0dc <exec_byte_code+3980>, 0x58a10e <exec_byte_code+4030>,
0x58a140 <exec_byte_code+4080>,
0x58a17d <exec_byte_code+4141>, 0x58a1ba <exec_byte_code+4202>,
0x58a1f7 <exec_byte_code+4263>,
0x58a23e <exec_byte_code+4334>, 0x58a277 <exec_byte_code+4391>,
0x58a2b0 <exec_byte_code+4448>,
0x58a33d <exec_byte_code+4589>, 0x58a380 <exec_byte_code+4656>,
0x58a3c7 <exec_byte_code+4727>,
0x58a494 <exec_byte_code+4932>, 0x58a410 <exec_byte_code+4800>,
0x58a452 <exec_byte_code+4866>,
0x589bb4 <exec_byte_code+2660>, 0x589bf6 <exec_byte_code+2726>,
0x589c2f <exec_byte_code+2783>,
0x589c71 <exec_byte_code+2849>, 0x58b195 <exec_byte_code+8261>,
0x58b1ce <exec_byte_code+8318>,
0x58b207 <exec_byte_code+8375>, 0x58afea <exec_byte_code+7834>,
0x589489 <exec_byte_code+825>,
0x58b02b <exec_byte_code+7899>, 0x58b059 <exec_byte_code+7945>,
0x58b0e1 <exec_byte_code+8081>,
0x58b122 <exec_byte_code+8146>, 0x58b163 <exec_byte_code+8211>,
0x58ac6d <exec_byte_code+6941>,
0x58ac9d <exec_byte_code+6989>, 0x58accd <exec_byte_code+7037>,
0x58ad05 <exec_byte_code+7093>,
0x5894ba <exec_byte_code+874>, 0x58ad39 <exec_byte_code+7145>,
0x58ad69 <exec_byte_code+7193>,
0x58ad99 <exec_byte_code+7241>, 0x58adc9 <exec_byte_code+7289>,
0x58adf9 <exec_byte_code+7337>,
0x58ae29 <exec_byte_code+7385>, 0x589489 <exec_byte_code+825>,
0x5894ba <exec_byte_code+874>,
0x58ae5b <exec_byte_code+7435>, 0x58ae9d <exec_byte_code+7501>,
0x58aecf <exec_byte_code+7551>,
0x58af01 <exec_byte_code+7601>, 0x58af3e <exec_byte_code+7662>,
0x58af7b <exec_byte_code+7723>,
0x58ac0e <exec_byte_code+6846>, 0x58ac30 <exec_byte_code+6880>,
0x58b63e <exec_byte_code+9454>,
0x58b67b <exec_byte_code+9515>, 0x58b60e <exec_byte_code+9406>,
0x58b735 <exec_byte_code+9701>,
0x5894ba <exec_byte_code+874>, 0x58aada <exec_byte_code+6538>,
0x58a555 <exec_byte_code+5125>,
0x5896fd <exec_byte_code+1453>, 0x58a5e4 <exec_byte_code+5268>,
0x58a825 <exec_byte_code+5845>,
0x58a896 <exec_byte_code+5958>, 0x589b72 <exec_byte_code+2594>,
0x58a801 <exec_byte_code+5809>,
0x589834 <exec_byte_code+1764>, 0x5894fd <exec_byte_code+941>,
0x589912 <exec_byte_code+1986>,
0x58a698 <exec_byte_code+5448>, 0x58a6c9 <exec_byte_code+5497>,
0x58abbf <exec_byte_code+6767>,
0x58ab2d <exec_byte_code+6621>, 0x58ab74 <exec_byte_code+6692>,
0x589caa <exec_byte_code+2906>,
0x58a4ea <exec_byte_code+5018>, 0x58b6b8 <exec_byte_code+9576>,
0x58b703 <exec_byte_code+9651>,
0x58b465 <exec_byte_code+8981>, 0x58b497 <exec_byte_code+9031>,
0x58b4c9 <exec_byte_code+9081>,
0x58b4fb <exec_byte_code+9131>, 0x58b538 <exec_byte_code+9192>,
0x58b575 <exec_byte_code+9253>,
0x58b5b2 <exec_byte_code+9314>, 0x58b5ef <exec_byte_code+9375>,
0x58b279 <exec_byte_code+8489>,
0x58b2b6 <exec_byte_code+8550>, 0x58b2f3 <exec_byte_code+8611>,
0x58b325 <exec_byte_code+8661>,
0x58b362 <exec_byte_code+8722>, 0x58b39f <exec_byte_code+8783>,
0x58b3dc <exec_byte_code+8844>,
0x58b419 <exec_byte_code+8905>, 0x58b240 <exec_byte_code+8432>,
0x58afad <exec_byte_code+7773>,
0x589975 <exec_byte_code+2085>, 0x5899be <exec_byte_code+2158>,
0x5894ba <exec_byte_code+874>,
0x58a784 <exec_byte_code+5684>, 0x58aa0f <exec_byte_code+6335>,
0x58a975 <exec_byte_code+6181>,
0x58aa76 <exec_byte_code+6438>, 0x589adc <exec_byte_code+2444>,
0x589fd1 <exec_byte_code+3713>,
0x58a2e9 <exec_byte_code+4505>, 0x58b08d <exec_byte_code+7997>,
0x589606 <exec_byte_code+1206>,
0x5899f8 <exec_byte_code+2216>, 0x5894ba <exec_byte_code+874>,
0x5894ba <exec_byte_code+874>,
0x589a54 <exec_byte_code+2308>, 0x5894ba <exec_byte_code+874>,
0x5894ba <exec_byte_code+874>,
0x5894ba <exec_byte_code+874>, 0x5894ba <exec_byte_code+874>,
0x5894ba <exec_byte_code+874>,
0x5894ba <exec_byte_code+874>, 0x5894ba <exec_byte_code+874>,
0x5894ba <exec_byte_code+874>,
0x5894ba <exec_byte_code+874>, 0x589aa2 <exec_byte_code+2386>
<repeats 64 times>}
count = 7
op = 1
vectorp = 0x969ce0 <pure+1202176>
stack = {
pc = 0xaacef4 <pure+2525716>
"\210\307\016@\211\203k\006\211@\002\204d\006\211;\203d\006\201",
<incomplete sequence \316>, byte_string = 9870524,
byte_string_start = 0xaac8d3 <pure+2524147> "\306
\020\307\021\n\023\307\024\310\311!\211\307=\204\060", next =
0x7fffffffdab0}
top = 0x7fffffffd818
result = <optimized out>
type = <optimized out>
#16 0x00000000005523c3 in Ffuncall (nargs=<optimized out>,
args=0x7fffffffda10) at eval.c:2760
fun = <optimized out>
original_fun = 8586560
funcar = <optimized out>
numargs = <optimized out>
lisp_numargs = 2
val = <optimized out>
internal_args = <optimized out>
count = 6
#17 0x000000000058941d in exec_byte_code (bytestr=<optimized out>,
vector=9866565,
maxdepth=<optimized out>, args_template=<optimized out>,
nargs=<optimized out>, args=<optimized out>)
at bytecode.c:880
targets = {0x5894ba <exec_byte_code+874>, 0x58b452
<exec_byte_code+8962>,
0x58b457 <exec_byte_code+8967>, 0x58b45c <exec_byte_code+8972>,
0x589282 <exec_byte_code+306>,
0x589288 <exec_byte_code+312>, 0x58952e <exec_byte_code+990>,
0x5895ad <exec_byte_code+1117>,
0x5895a3 <exec_byte_code+1107>, 0x5895a8 <exec_byte_code+1112>,
0x589573 <exec_byte_code+1059>,
---Type <return> to continue, or q <return> to quit---
0x589578 <exec_byte_code+1064>, 0x5892c1 <exec_byte_code+369>,
0x5892c8 <exec_byte_code+376>,
0x5896e9 <exec_byte_code+1433>, 0x58957d <exec_byte_code+1069>,
0x589908 <exec_byte_code+1976>,
0x58990d <exec_byte_code+1981>, 0x589879 <exec_byte_code+1833>,
0x58987e <exec_byte_code+1838>,
0x589334 <exec_byte_code+484>, 0x589338 <exec_byte_code+488>,
0x589820 <exec_byte_code+1744>,
0x5897fa <exec_byte_code+1706>, 0x5896ae <exec_byte_code+1374>,
0x5896b3 <exec_byte_code+1379>,
0x5896b8 <exec_byte_code+1384>, 0x5896c5 <exec_byte_code+1397>,
0x5893b4 <exec_byte_code+612>,
0x5893b8 <exec_byte_code+616>, 0x589865 <exec_byte_code+1813>,
0x589688 <exec_byte_code+1336>,
0x589679 <exec_byte_code+1321>, 0x58967e <exec_byte_code+1326>,
0x589683 <exec_byte_code+1331>,
0x58964e <exec_byte_code+1278>, 0x5893f9 <exec_byte_code+681>,
0x589400 <exec_byte_code+688>,
0x5896d5 <exec_byte_code+1413>, 0x589653 <exec_byte_code+1283>,
0x58a53f <exec_byte_code+5103>,
0x58a544 <exec_byte_code+5108>, 0x58a549 <exec_byte_code+5113>,
0x58a514 <exec_byte_code+5060>,
0x589443 <exec_byte_code+755>, 0x589448 <exec_byte_code+760>,
0x58a4d6 <exec_byte_code+4998>,
0x58a519 <exec_byte_code+5065>, 0x58a944 <exec_byte_code+6132>,
0x58a77d <exec_byte_code+5677>,
0x58a70b <exec_byte_code+5563>, 0x5894ba <exec_byte_code+874>,
0x5894ba <exec_byte_code+874>,
0x5894ba <exec_byte_code+874>, 0x5894ba <exec_byte_code+874>,
0x5894ba <exec_byte_code+874>,
0x589d04 <exec_byte_code+2996>, 0x589d90 <exec_byte_code+3136>,
0x589dc7 <exec_byte_code+3191>,
0x589e01 <exec_byte_code+3249>, 0x589e3b <exec_byte_code+3307>,
0x5897bb <exec_byte_code+1643>,
0x589883 <exec_byte_code+1843>, 0x589e81 <exec_byte_code+3377>,
0x589773 <exec_byte_code+1571>,
0x5898c0 <exec_byte_code+1904>, 0x589eb3 <exec_byte_code+3427>,
0x589ef0 <exec_byte_code+3488>,
0x589f22 <exec_byte_code+3538>, 0x589f5f <exec_byte_code+3599>,
0x589f98 <exec_byte_code+3656>,
0x58a022 <exec_byte_code+3794>, 0x58a054 <exec_byte_code+3844>,
0x58a091 <exec_byte_code+3905>,
0x58a0dc <exec_byte_code+3980>, 0x58a10e <exec_byte_code+4030>,
0x58a140 <exec_byte_code+4080>,
0x58a17d <exec_byte_code+4141>, 0x58a1ba <exec_byte_code+4202>,
0x58a1f7 <exec_byte_code+4263>,
0x58a23e <exec_byte_code+4334>, 0x58a277 <exec_byte_code+4391>,
0x58a2b0 <exec_byte_code+4448>,
0x58a33d <exec_byte_code+4589>, 0x58a380 <exec_byte_code+4656>,
0x58a3c7 <exec_byte_code+4727>,
0x58a494 <exec_byte_code+4932>, 0x58a410 <exec_byte_code+4800>,
0x58a452 <exec_byte_code+4866>,
0x589bb4 <exec_byte_code+2660>, 0x589bf6 <exec_byte_code+2726>,
0x589c2f <exec_byte_code+2783>,
0x589c71 <exec_byte_code+2849>, 0x58b195 <exec_byte_code+8261>,
0x58b1ce <exec_byte_code+8318>,
0x58b207 <exec_byte_code+8375>, 0x58afea <exec_byte_code+7834>,
0x589489 <exec_byte_code+825>,
0x58b02b <exec_byte_code+7899>, 0x58b059 <exec_byte_code+7945>,
0x58b0e1 <exec_byte_code+8081>,
0x58b122 <exec_byte_code+8146>, 0x58b163 <exec_byte_code+8211>,
0x58ac6d <exec_byte_code+6941>,
0x58ac9d <exec_byte_code+6989>, 0x58accd <exec_byte_code+7037>,
0x58ad05 <exec_byte_code+7093>,
0x5894ba <exec_byte_code+874>, 0x58ad39 <exec_byte_code+7145>,
0x58ad69 <exec_byte_code+7193>,
0x58ad99 <exec_byte_code+7241>, 0x58adc9 <exec_byte_code+7289>,
0x58adf9 <exec_byte_code+7337>,
0x58ae29 <exec_byte_code+7385>, 0x589489 <exec_byte_code+825>,
0x5894ba <exec_byte_code+874>,
0x58ae5b <exec_byte_code+7435>, 0x58ae9d <exec_byte_code+7501>,
0x58aecf <exec_byte_code+7551>,
0x58af01 <exec_byte_code+7601>, 0x58af3e <exec_byte_code+7662>,
0x58af7b <exec_byte_code+7723>,
0x58ac0e <exec_byte_code+6846>, 0x58ac30 <exec_byte_code+6880>,
0x58b63e <exec_byte_code+9454>,
0x58b67b <exec_byte_code+9515>, 0x58b60e <exec_byte_code+9406>,
0x58b735 <exec_byte_code+9701>,
0x5894ba <exec_byte_code+874>, 0x58aada <exec_byte_code+6538>,
0x58a555 <exec_byte_code+5125>,
0x5896fd <exec_byte_code+1453>, 0x58a5e4 <exec_byte_code+5268>,
0x58a825 <exec_byte_code+5845>,
0x58a896 <exec_byte_code+5958>, 0x589b72 <exec_byte_code+2594>,
0x58a801 <exec_byte_code+5809>,
0x589834 <exec_byte_code+1764>, 0x5894fd <exec_byte_code+941>,
0x589912 <exec_byte_code+1986>,
0x58a698 <exec_byte_code+5448>, 0x58a6c9 <exec_byte_code+5497>,
0x58abbf <exec_byte_code+6767>,
0x58ab2d <exec_byte_code+6621>, 0x58ab74 <exec_byte_code+6692>,
0x589caa <exec_byte_code+2906>,
0x58a4ea <exec_byte_code+5018>, 0x58b6b8 <exec_byte_code+9576>,
0x58b703 <exec_byte_code+9651>,
0x58b465 <exec_byte_code+8981>, 0x58b497 <exec_byte_code+9031>,
0x58b4c9 <exec_byte_code+9081>,
0x58b4fb <exec_byte_code+9131>, 0x58b538 <exec_byte_code+9192>,
0x58b575 <exec_byte_code+9253>,
0x58b5b2 <exec_byte_code+9314>, 0x58b5ef <exec_byte_code+9375>,
0x58b279 <exec_byte_code+8489>,
0x58b2b6 <exec_byte_code+8550>, 0x58b2f3 <exec_byte_code+8611>,
0x58b325 <exec_byte_code+8661>,
0x58b362 <exec_byte_code+8722>, 0x58b39f <exec_byte_code+8783>,
0x58b3dc <exec_byte_code+8844>,
0x58b419 <exec_byte_code+8905>, 0x58b240 <exec_byte_code+8432>,
0x58afad <exec_byte_code+7773>,
0x589975 <exec_byte_code+2085>, 0x5899be <exec_byte_code+2158>,
0x5894ba <exec_byte_code+874>,
0x58a784 <exec_byte_code+5684>, 0x58aa0f <exec_byte_code+6335>,
0x58a975 <exec_byte_code+6181>,
0x58aa76 <exec_byte_code+6438>, 0x589adc <exec_byte_code+2444>,
0x589fd1 <exec_byte_code+3713>,
0x58a2e9 <exec_byte_code+4505>, 0x58b08d <exec_byte_code+7997>,
0x589606 <exec_byte_code+1206>,
0x5899f8 <exec_byte_code+2216>, 0x5894ba <exec_byte_code+874>,
0x5894ba <exec_byte_code+874>,
0x589a54 <exec_byte_code+2308>, 0x5894ba <exec_byte_code+874>,
0x5894ba <exec_byte_code+874>,
0x5894ba <exec_byte_code+874>, 0x5894ba <exec_byte_code+874>,
0x5894ba <exec_byte_code+874>,
0x5894ba <exec_byte_code+874>, 0x5894ba <exec_byte_code+874>,
0x5894ba <exec_byte_code+874>,
0x5894ba <exec_byte_code+874>, 0x589aa2 <exec_byte_code+2386>
<repeats 64 times>}
count = 5
op = 0
vectorp = 0x968d48 <pure+1198184>
stack = {pc = 0xaad5d8 <pure+2527480>
"\210)\210\375\376\377\"\210\201H", byte_string = 9866532,
byte_string_start = 0xaad464 <pure+2527108> "\b\203\b", next =
0x0}
top = 0x7fffffffda10
result = <optimized out>
type = <optimized out>
#18 0x000000000055166b in apply_lambda (fun=9866485, args=0, count=4) at
eval.c:2800
args_left = 0
i = <optimized out>
numargs = 0
arg_vector = 0x7fffffffdb00
tem = <optimized out>
sa_avail = <optimized out>
sa_count = 5
sa_must_free = false
#19 0x0000000000551936 in eval_sub (form=<optimized out>) at eval.c:2247
fun = <optimized out>
val = <optimized out>
original_fun = 8584864
original_args = 0
funcar = <optimized out>
count = 4
---Type <return> to continue, or q <return> to quit---
argvals = {0, 0, 12274656, 3840, 1, 4599230, 140737488346536,
5508133}
#20 0x0000000000553712 in Feval (form=17463347, lexical=<optimized out>) at
eval.c:1994
count = 3
#21 0x00000000005512aa in internal_condition_case (bfun=0x4e2ae0
<top_level_2>, handlers=<optimized out>,
hfun=0x4eb100 <cmd_error>) at eval.c:1315
val = <optimized out>
c = 0x104c
#22 0x00000000004eb0bc in top_level_1 (ignore=<optimized out>) at
keyboard.c:1129
No locals.
#23 0x0000000000551338 in internal_catch (tag=<optimized out>,
func=0x4eb060 <top_level_1>, arg=0)
at eval.c:1080
val = 0
c = 0x104c
#24 0x00000000004eae56 in command_loop () at keyboard.c:1090
No locals.
#25 0x00000000004eaef5 in recursive_edit_1 () at keyboard.c:697
count = 1
val = <optimized out>
#26 0x00000000004eb035 in Frecursive_edit () at keyboard.c:768
count = 0
buffer = <optimized out>
#27 0x00000000004dc82e in main (argc=<optimized out>, argv=<optimized out>)
at emacs.c:1629
dummy = 4251459
stack_bottom_variable = 0 '\000'
do_initial_setlocale = <optimized out>
dumping = <optimized out>
skip_args = 1
rlim = {rlim_cur = 20480000, rlim_max = 18446744073709551615}
no_loadup = false
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x0
original_pwd = 0x7 <Address 0x7 out of bounds>
What a colleague (CC'ed) thinks happens is:
This looks like it might be a bug in the emacs GC. Since the symbol is
buffer-local, it has an auxiliary "SYMBOL_BLV" structure, allocated
using [malloc], attached to it. The first garbage collection can be seen
to be freeing this structure and changing the name (stored in the
"function" member) to [Vdead] (in sweep_symbols in alloc.c).
The symbols are stored in some kind of list of blocks. If any given
block becomes full of free symbols as a result of the sweeping, it may
be freed by the next garbage-collect call (see [sweep_symbols] again in
alloc.c). However this clearly does not always happen as seen by the
comments in the code. As such surely something has to be done, after
freeing a symbol's blv structure and marking it dead, to make sure that
a subsequent sweeping phase on the same block of symbols doesn't try to
free the symbol's blv structure a second time.
There seems to be no protection against this at the moment which is why
we suspect a bug. The attached patch adds such protection and we
confirm it stops the issue, both in the example above and in the
original unreduced code.
In GNU Emacs 26.0.90 (build 1, x86_64-pc-linux-gnu)
of 2017-10-30 built on igm-qws-u12051a
Repository revision: 46540a1c7adb1b89b6c2f6c9150fe8680c3a5fba
System Description: CentOS Linux release 7.4.1708 (Core)
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...
apropos-read-pattern: Command attempted to use minibuffer while in
minibuffer
Configured using:
'configure --with-gnutls=no --without-x --without-gsettings
--without-gpm --without-dbus --without-gconf --without-selinux
--without-imagemagick --with-gif=no --with-modules --disable-acl
-prefix /home/vgatien-baron/local/clones/emacs/installed'
Configured features:
JPEG SOUND NOTIFY LIBXML2 ZLIB MODULES
Important settings:
value of $LANG: en_US.utf8
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
electric-indent-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr apropos emacsbug message rmc puny dired
dired-loaddefs format-spec rfc822 mml mml-sec epa derived epg gnus-util
rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail regexp-opt rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils term/xterm xterm time-date
elec-pair warnings finder-inf info tool-bar zenburn-theme-autoloads
package easymenu epg-config url-handlers url-parse auth-source cl-seq
eieio eieio-core cl-macs eieio-loaddefs password-cache url-vars seq
byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib mule-util
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select mouse
jit-lock font-lock syntax facemenu font-core term/tty-colors frame
cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian
slovak czech european ethiopic indian cyrillic chinese composite
charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev
obarray minibuffer cl-preloaded nadvice loaddefs button faces cus-face
macroexp files text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote inotify
multi-tty make-network-process emacs)
Memory information:
((conses 16 179056 9590)
(symbols 48 24756 1)
(miscs 40 36 144)
(strings 32 53443 1520)
(string-bytes 1 1383070)
(vectors 16 18475)
(vector-slots 8 545400 4472)
(floats 8 51 765)
(intervals 56 225 0)
(buffers 992 14)
(heap 1024 24122 1231))
[Message part 2 (text/html, inline)]
[ecaml_bug.diff (text/plain, attachment)]
bug-gnu-emacs <at> gnu.org:bug#29066; Package emacs.
(Mon, 30 Oct 2017 20:39:02 GMT) Full text and rfc822 format available.Message #8 received at 29066 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Valentin Gatien-Baron <vgatien-baron <at> janestreet.com> Cc: 29066 <at> debbugs.gnu.org, mshinwell <at> janestreet.com Subject: Re: bug#29066: 26.0.90; crash in gc involving buffer local symbols Date: Mon, 30 Oct 2017 22:38:06 +0200
> From: Valentin Gatien-Baron <vgatien-baron <at> janestreet.com>
> Date: Mon, 30 Oct 2017 10:36:41 -0400
> Cc: Mark Shinwell <mshinwell <at> janestreet.com>
>
> $ installed/bin/emacs -Q -L . -batch --eval '(progn (message "before") (make-local-variable (make-symbol "\
> s")) (kill-buffer) (garbage-collect) (garbage-collect) (message "after"))'
> before
> *** Error in `installed/bin/emacs': double free or corruption (!prev): 0x00000000014bff10 ***
Thanks.
Does the below fix the problem?
diff --git a/src/alloc.c b/src/alloc.c
index d9d7485..11afdfd 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -7024,7 +7024,9 @@ sweep_symbols (void)
{
if (!sym->s.gcmarkbit)
{
- if (sym->s.redirect == SYMBOL_LOCALIZED)
+ if (sym->s.redirect == SYMBOL_LOCALIZED
+ /* Already freed? */
+ && !EQ (sym->s.function, Vdead))
xfree (SYMBOL_BLV (&sym->s));
sym->s.next = symbol_free_list;
symbol_free_list = &sym->s;
bug-gnu-emacs <at> gnu.org:bug#29066; Package emacs.
(Mon, 30 Oct 2017 22:12:02 GMT) Full text and rfc822 format available.Message #11 received at 29066 <at> debbugs.gnu.org (full text, mbox):
From: Valentin Gatien-Baron <vgatien-baron <at> janestreet.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 29066 <at> debbugs.gnu.org, Mark Shinwell <mshinwell <at> janestreet.com> Subject: Re: bug#29066: 26.0.90; crash in gc involving buffer local symbols Date: Mon, 30 Oct 2017 18:04:14 -0400
[Message part 1 (text/plain, inline)]
Yes, it fixes the problem.
I also checked the following works, and seems better to me (stop having
dangling pointers, instead of being careful with them):
diff --git a/src/alloc.c b/src/alloc.c
index da0c3ad4b3..44dfa95cf5 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -7030,8 +7030,10 @@ sweep_symbols (void)
{
if (!sym->s.gcmarkbit)
{
- if (sym->s.redirect == SYMBOL_LOCALIZED)
+ if (sym->s.redirect == SYMBOL_LOCALIZED) {
xfree (SYMBOL_BLV (&sym->s));
+ sym->s.val.blv = NULL;
+ }
sym->s.next = symbol_free_list;
symbol_free_list = &sym->s;
symbol_free_list->function = Vdead;
On Mon, Oct 30, 2017 at 4:38 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Valentin Gatien-Baron <vgatien-baron <at> janestreet.com>
> > Date: Mon, 30 Oct 2017 10:36:41 -0400
> > Cc: Mark Shinwell <mshinwell <at> janestreet.com>
> >
> > $ installed/bin/emacs -Q -L . -batch --eval '(progn (message "before")
> (make-local-variable (make-symbol "\
> > s")) (kill-buffer) (garbage-collect) (garbage-collect) (message
> "after"))'
> > before
> > *** Error in `installed/bin/emacs': double free or corruption (!prev):
> 0x00000000014bff10 ***
>
> Thanks.
>
> Does the below fix the problem?
>
> diff --git a/src/alloc.c b/src/alloc.c
> index d9d7485..11afdfd 100644
> --- a/src/alloc.c
> +++ b/src/alloc.c
> @@ -7024,7 +7024,9 @@ sweep_symbols (void)
> {
> if (!sym->s.gcmarkbit)
> {
> - if (sym->s.redirect == SYMBOL_LOCALIZED)
> + if (sym->s.redirect == SYMBOL_LOCALIZED
> + /* Already freed? */
> + && !EQ (sym->s.function, Vdead))
> xfree (SYMBOL_BLV (&sym->s));
> sym->s.next = symbol_free_list;
> symbol_free_list = &sym->s;
>
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#29066; Package emacs.
(Tue, 31 Oct 2017 03:41:01 GMT) Full text and rfc822 format available.Message #14 received at 29066 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Valentin Gatien-Baron <vgatien-baron <at> janestreet.com> Cc: 29066 <at> debbugs.gnu.org, mshinwell <at> janestreet.com Subject: Re: bug#29066: 26.0.90; crash in gc involving buffer local symbols Date: Tue, 31 Oct 2017 05:39:56 +0200
> From: Valentin Gatien-Baron <vgatien-baron <at> janestreet.com>
> Date: Mon, 30 Oct 2017 18:04:14 -0400
> Cc: 29066 <at> debbugs.gnu.org,
> Mark Shinwell <mshinwell <at> janestreet.com>
>
> Yes, it fixes the problem.
Thanks.
> I also checked the following works, and seems better to me (stop having dangling pointers, instead of being
> careful with them):
>
> diff --git a/src/alloc.c b/src/alloc.c
> index da0c3ad4b3..44dfa95cf5 100644
> --- a/src/alloc.c
> +++ b/src/alloc.c
> @@ -7030,8 +7030,10 @@ sweep_symbols (void)
> {
> if (!sym->s.gcmarkbit)
> {
> - if (sym->s.redirect == SYMBOL_LOCALIZED)
> + if (sym->s.redirect == SYMBOL_LOCALIZED) {
> xfree (SYMBOL_BLV (&sym->s));
> + sym->s.val.blv = NULL;
> + }
That was my first attempt, but various macros like SYMBOL_BLV and
SET_SYMBOL_BLV insist on val.blv being non-NULL. I guess you've built
Emacs without --enable-checking, so you don't see the effect of that,
but if you do, you will have assertion violations with your patch.
bug-gnu-emacs <at> gnu.org:bug#29066; Package emacs.
(Tue, 31 Oct 2017 06:33:02 GMT) Full text and rfc822 format available.Message #17 received at 29066 <at> debbugs.gnu.org (full text, mbox):
From: Andreas Schwab <schwab <at> linux-m68k.org> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 29066 <at> debbugs.gnu.org, mshinwell <at> janestreet.com, Valentin Gatien-Baron <vgatien-baron <at> janestreet.com> Subject: Re: bug#29066: 26.0.90; crash in gc involving buffer local symbols Date: Tue, 31 Oct 2017 07:32:14 +0100
On Okt 31 2017, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> I also checked the following works, and seems better to me (stop having dangling pointers, instead of being
>> careful with them):
>>
>> diff --git a/src/alloc.c b/src/alloc.c
>> index da0c3ad4b3..44dfa95cf5 100644
>> --- a/src/alloc.c
>> +++ b/src/alloc.c
>> @@ -7030,8 +7030,10 @@ sweep_symbols (void)
>> {
>> if (!sym->s.gcmarkbit)
>> {
>> - if (sym->s.redirect == SYMBOL_LOCALIZED)
>> + if (sym->s.redirect == SYMBOL_LOCALIZED) {
>> xfree (SYMBOL_BLV (&sym->s));
>> + sym->s.val.blv = NULL;
>> + }
>
> That was my first attempt, but various macros like SYMBOL_BLV and
> SET_SYMBOL_BLV insist on val.blv being non-NULL.
SET_SYMBOL_BLV doesn't. And calling SYMBOL_BLV with a freed symbol is a
bug anyway.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
bug-gnu-emacs <at> gnu.org:bug#29066; Package emacs.
(Tue, 31 Oct 2017 14:53:01 GMT) Full text and rfc822 format available.Message #20 received at 29066 <at> debbugs.gnu.org (full text, mbox):
From: Valentin Gatien-Baron <vgatien-baron <at> janestreet.com> To: Andreas Schwab <schwab <at> linux-m68k.org> Cc: Eli Zaretskii <eliz <at> gnu.org>, 29066 <at> debbugs.gnu.org, Mark Shinwell <mshinwell <at> janestreet.com> Subject: Re: bug#29066: 26.0.90; crash in gc involving buffer local symbols Date: Tue, 31 Oct 2017 10:52:44 -0400
[Message part 1 (text/plain, inline)]
On Tue, Oct 31, 2017 at 2:32 AM, Andreas Schwab <schwab <at> linux-m68k.org>
wrote:
> On Okt 31 2017, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> >> I also checked the following works, and seems better to me (stop having
> dangling pointers, instead of being
> >> careful with them):
> >>
> >> diff --git a/src/alloc.c b/src/alloc.c
> >> index da0c3ad4b3..44dfa95cf5 100644
> >> --- a/src/alloc.c
> >> +++ b/src/alloc.c
> >> @@ -7030,8 +7030,10 @@ sweep_symbols (void)
> >> {
> >> if (!sym->s.gcmarkbit)
> >> {
> >> - if (sym->s.redirect == SYMBOL_LOCALIZED)
> >> + if (sym->s.redirect == SYMBOL_LOCALIZED) {
> >> xfree (SYMBOL_BLV (&sym->s));
> >> + sym->s.val.blv = NULL;
> >> + }
> >
> > That was my first attempt, but various macros like SYMBOL_BLV and
> > SET_SYMBOL_BLV insist on val.blv being non-NULL.
>
> SET_SYMBOL_BLV doesn't. And calling SYMBOL_BLV with a freed symbol is a
> bug anyway.
>
SET_SYMBOL_BLV insists that the new value is not NULL, even if it asserts
nothing about the current value.
We do call SYMBOL_BLV after freeing, when we re-sweep the symbol, which is
fine because free does nothing when given NULL, but triggers the assertion.
I would do this, to avoid the assertion failure:
diff --git a/src/alloc.c b/src/alloc.c
index da0c3ad4b3..72550e812b 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -7030,8 +7030,10 @@ sweep_symbols (void)
{
if (!sym->s.gcmarkbit)
{
- if (sym->s.redirect == SYMBOL_LOCALIZED)
+ if (sym->s.redirect == SYMBOL_LOCALIZED && sym->s.val.blv) {
xfree (SYMBOL_BLV (&sym->s));
+ sym->s.val.blv = NULL;
+ }
sym->s.next = symbol_free_list;
symbol_free_list = &sym->s;
symbol_free_list->function = Vdead;
Or changing the redirect type:
diff --git a/src/alloc.c b/src/alloc.c
index da0c3ad4b3..6966d96c6d 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -7030,8 +7030,11 @@ sweep_symbols (void)
{
if (!sym->s.gcmarkbit)
{
- if (sym->s.redirect == SYMBOL_LOCALIZED)
+ if (sym->s.redirect == SYMBOL_LOCALIZED) {
xfree (SYMBOL_BLV (&sym->s));
+ sym->s.redirect = SYMBOL_PLAINVAL;
+ SET_SYMBOL_VAL (&sym->s, Qunbound);
+ }
sym->s.next = symbol_free_list;
symbol_free_list = &sym->s;
symbol_free_list->function = Vdead;
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#29066; Package emacs.
(Tue, 31 Oct 2017 19:01:02 GMT) Full text and rfc822 format available.Message #23 received at 29066 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Andreas Schwab <schwab <at> linux-m68k.org> Cc: 29066 <at> debbugs.gnu.org, mshinwell <at> janestreet.com, vgatien-baron <at> janestreet.com Subject: Re: bug#29066: 26.0.90; crash in gc involving buffer local symbols Date: Tue, 31 Oct 2017 20:59:11 +0200
> From: Andreas Schwab <schwab <at> linux-m68k.org>
> Cc: Valentin Gatien-Baron <vgatien-baron <at> janestreet.com>, 29066 <at> debbugs.gnu.org, mshinwell <at> janestreet.com
> Date: Tue, 31 Oct 2017 07:32:14 +0100
>
> On Okt 31 2017, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> >> if (!sym->s.gcmarkbit)
> >> {
> >> - if (sym->s.redirect == SYMBOL_LOCALIZED)
> >> + if (sym->s.redirect == SYMBOL_LOCALIZED) {
> >> xfree (SYMBOL_BLV (&sym->s));
> >> + sym->s.val.blv = NULL;
> >> + }
> >
> > That was my first attempt, but various macros like SYMBOL_BLV and
> > SET_SYMBOL_BLV insist on val.blv being non-NULL.
>
> SET_SYMBOL_BLV doesn't.
Maybe I'm blind, or misunderstand what you mean, but if the intent was
to do this:
SET_SYMBOL_BLV (&sym->s, NULL);
then it does:
INLINE void
SET_SYMBOL_BLV (struct Lisp_Symbol *sym, struct Lisp_Buffer_Local_Value *v)
{
eassume (sym->redirect == SYMBOL_LOCALIZED && v); <<<<<<<<<<<<<<<<
sym->val.blv = v;
}
> And calling SYMBOL_BLV with a freed symbol is a bug anyway.
It isn't freed, it's on the symbol_free_list. Only its buffer-local
value is freed.
bug-gnu-emacs <at> gnu.org:bug#29066; Package emacs.
(Tue, 31 Oct 2017 19:12:02 GMT) Full text and rfc822 format available.Message #26 received at 29066 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Valentin Gatien-Baron <vgatien-baron <at> janestreet.com> Cc: 29066 <at> debbugs.gnu.org, schwab <at> linux-m68k.org, mshinwell <at> janestreet.com Subject: Re: bug#29066: 26.0.90; crash in gc involving buffer local symbols Date: Tue, 31 Oct 2017 21:10:39 +0200
> From: Valentin Gatien-Baron <vgatien-baron <at> janestreet.com>
> Date: Tue, 31 Oct 2017 10:52:44 -0400
> Cc: Eli Zaretskii <eliz <at> gnu.org>,
> 29066 <at> debbugs.gnu.org,
> Mark Shinwell <mshinwell <at> janestreet.com>
>
> > That was my first attempt, but various macros like SYMBOL_BLV and
> > SET_SYMBOL_BLV insist on val.blv being non-NULL.
>
> SET_SYMBOL_BLV doesn't. And calling SYMBOL_BLV with a freed symbol is a
> bug anyway.
>
> SET_SYMBOL_BLV insists that the new value is not NULL, even if it asserts nothing about the current value.
>
> We do call SYMBOL_BLV after freeing, when we re-sweep the symbol, which is fine because free does
> nothing when given NULL, but triggers the assertion.
>
> I would do this, to avoid the assertion failure:
>
> diff --git a/src/alloc.c b/src/alloc.c
> index da0c3ad4b3..72550e812b 100644
> --- a/src/alloc.c
> +++ b/src/alloc.c
> @@ -7030,8 +7030,10 @@ sweep_symbols (void)
> {
> if (!sym->s.gcmarkbit)
> {
> - if (sym->s.redirect == SYMBOL_LOCALIZED)
> + if (sym->s.redirect == SYMBOL_LOCALIZED && sym->s.val.blv) {
> xfree (SYMBOL_BLV (&sym->s));
> + sym->s.val.blv = NULL;
> + }
> sym->s.next = symbol_free_list;
> symbol_free_list = &sym->s;
> symbol_free_list->function = Vdead;
Thanks, but it makes little sense to me to work around our own
assertions this way. Why do we have these macros if we sometimes
don't use them? And why do we have the assertions if they sometimes
get in the way?
> Or changing the redirect type:
>
> diff --git a/src/alloc.c b/src/alloc.c
> index da0c3ad4b3..6966d96c6d 100644
> --- a/src/alloc.c
> +++ b/src/alloc.c
> @@ -7030,8 +7030,11 @@ sweep_symbols (void)
> {
> if (!sym->s.gcmarkbit)
> {
> - if (sym->s.redirect == SYMBOL_LOCALIZED)
> + if (sym->s.redirect == SYMBOL_LOCALIZED) {
> xfree (SYMBOL_BLV (&sym->s));
> + sym->s.redirect = SYMBOL_PLAINVAL;
> + SET_SYMBOL_VAL (&sym->s, Qunbound);
> + }
We could do several things, but I still didn't hear even a single
reason why my suggestion isn't OK. IMO, it's simpler, and the test
for Vdead is already in at least one other place.
So I went ahead and pushed my change.
Is there anything else we need to do before closing this bug?
Thanks.
bug-gnu-emacs <at> gnu.org:bug#29066; Package emacs.
(Tue, 31 Oct 2017 19:59:02 GMT) Full text and rfc822 format available.Message #29 received at 29066 <at> debbugs.gnu.org (full text, mbox):
From: Valentin Gatien-Baron <vgatien-baron <at> janestreet.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 29066 <at> debbugs.gnu.org, Andreas Schwab <schwab <at> linux-m68k.org>, Mark Shinwell <mshinwell <at> janestreet.com> Subject: Re: bug#29066: 26.0.90; crash in gc involving buffer local symbols Date: Tue, 31 Oct 2017 15:58:45 -0400
[Message part 1 (text/plain, inline)]
On Tue, Oct 31, 2017 at 3:10 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Valentin Gatien-Baron <vgatien-baron <at> janestreet.com>
> > Date: Tue, 31 Oct 2017 10:52:44 -0400
> > Cc: Eli Zaretskii <eliz <at> gnu.org>,
> > 29066 <at> debbugs.gnu.org,
> > Mark Shinwell <mshinwell <at> janestreet.com>
> >
> > > That was my first attempt, but various macros like SYMBOL_BLV and
> > > SET_SYMBOL_BLV insist on val.blv being non-NULL.
> >
> > SET_SYMBOL_BLV doesn't. And calling SYMBOL_BLV with a freed symbol is a
> > bug anyway.
> >
> > SET_SYMBOL_BLV insists that the new value is not NULL, even if it
> asserts nothing about the current value.
> >
> > We do call SYMBOL_BLV after freeing, when we re-sweep the symbol, which
> is fine because free does
> > nothing when given NULL, but triggers the assertion.
> >
> > I would do this, to avoid the assertion failure:
> >
> > diff --git a/src/alloc.c b/src/alloc.c
> > index da0c3ad4b3..72550e812b 100644
> > --- a/src/alloc.c
> > +++ b/src/alloc.c
> > @@ -7030,8 +7030,10 @@ sweep_symbols (void)
> > {
> > if (!sym->s.gcmarkbit)
> > {
> > -
>
> if (sym->s.redirect == SYMBOL_LOCALIZED)
> > + if (sym->s.redirect == SYMBOL_LOCALIZED &&
> sym->s.val.blv) {
> > xfree (SYMBOL_BLV (
>
> &sym->s));
> > + sym->s.val.blv = NULL;
> > + }
> > sym->s.next = symbol_free_list;
> > symbol_free_list = &sym->s;
> > symbol_free_list->function = Vdead;
>
> Thanks, but it makes little sense to me to work around our own
> assertions this way. Why do we have these macros if we sometimes
> don't use them? And why do we have the assertions if they sometimes
> get in the way?
> > Or changing the redirect type:
> >
> > diff --git a/src/alloc.c b/src/alloc.c
> > index da0c3ad4b3..6966d96c6d 100644
> > --- a/src/alloc.c
> > +++ b/src/alloc.c
> > @@ -7030,8 +7030,11 @@ sweep_symbols (void)
> > {
> > if (!sym->s.gcmarkbit)
> > {
> > - if (sym->s.redirect == SYMBOL_LOCALIZED)
> > + if (sym->s.redirect == SYMBOL_LOCALIZED) {
> > xfree (SYMBOL_BLV (&sym->s));
> > + sym->s.redirect = SYMBOL_PLAINVAL;
> > + SET_SYMBOL_VAL (&sym->s, Qunbound);
> > + }
>
> We could do several things, but I still didn't hear even a single
> reason why my suggestion isn't OK. IMO, it's simpler, and the test
> for Vdead is already in at least one other place.
>
> So I went ahead and pushed my change.
>
> Is there anything else we need to do before closing this bug?
>
The slight downside of your fix is that there are dangling pointers that
point to valid-looking things in the debugger. It's runtime behavior looks
fine otherwise.
But I am not going to insist. There's nothing else to do, you can close
the bug. Thanks!
>
> Thanks.
>
[Message part 2 (text/html, inline)]
Eli Zaretskii <eliz <at> gnu.org>:Valentin Gatien-Baron <vgatien-baron <at> janestreet.com>:Message #34 received at 29066-done <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Valentin Gatien-Baron <vgatien-baron <at> janestreet.com> Cc: 29066-done <at> debbugs.gnu.org, schwab <at> linux-m68k.org, mshinwell <at> janestreet.com Subject: Re: bug#29066: 26.0.90; crash in gc involving buffer local symbols Date: Tue, 31 Oct 2017 22:09:34 +0200
> From: Valentin Gatien-Baron <vgatien-baron <at> janestreet.com> > Date: Tue, 31 Oct 2017 15:58:45 -0400 > Cc: Andreas Schwab <schwab <at> linux-m68k.org>, > 29066 <at> debbugs.gnu.org, > Mark Shinwell <mshinwell <at> janestreet.com> > > The slight downside of your fix is that there are dangling pointers that point to valid-looking things in the > debugger. How is that different from any other symbol on symbol_free_list? > But I am not going to insist. There's nothing else to do, you can close the bug. Thanks! Thanks, done.
bug-gnu-emacs <at> gnu.org:bug#29066; Package emacs.
(Tue, 31 Oct 2017 20:14:01 GMT) Full text and rfc822 format available.Message #37 received at 29066-done <at> debbugs.gnu.org (full text, mbox):
From: Valentin Gatien-Baron <vgatien-baron <at> janestreet.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 29066-done <at> debbugs.gnu.org, Andreas Schwab <schwab <at> linux-m68k.org>, Mark Shinwell <mshinwell <at> janestreet.com> Subject: Re: bug#29066: 26.0.90; crash in gc involving buffer local symbols Date: Tue, 31 Oct 2017 16:13:10 -0400
[Message part 1 (text/plain, inline)]
On Tue, Oct 31, 2017 at 4:09 PM, Eli Zaretskii <eliz <at> gnu.org> wrote: > > From: Valentin Gatien-Baron <vgatien-baron <at> janestreet.com> > > Date: Tue, 31 Oct 2017 15:58:45 -0400 > > Cc: Andreas Schwab <schwab <at> linux-m68k.org>, > > 29066 <at> debbugs.gnu.org, > > Mark Shinwell <mshinwell <at> janestreet.com> > > > > The slight downside of your fix is that there are dangling pointers > that point to valid-looking things in the > > debugger. > > How is that different from any other symbol on symbol_free_list? > Ok, maybe it's no different. > > > But I am not going to insist. There's nothing else to do, you can close > the bug. Thanks! > > Thanks, done. >
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#29066; Package emacs.
(Tue, 31 Oct 2017 20:24:02 GMT) Full text and rfc822 format available.Message #40 received at 29066 <at> debbugs.gnu.org (full text, mbox):
From: Andreas Schwab <schwab <at> linux-m68k.org> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 29066 <at> debbugs.gnu.org, mshinwell <at> janestreet.com, vgatien-baron <at> janestreet.com Subject: Re: bug#29066: 26.0.90; crash in gc involving buffer local symbols Date: Tue, 31 Oct 2017 21:23:09 +0100
On Okt 31 2017, Eli Zaretskii <eliz <at> gnu.org> wrote: > It isn't freed, it's on the symbol_free_list. A symbol on the symbol_free_list is a freed symbol, not available for use. Andreas. -- Andreas Schwab, schwab <at> linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
bug-gnu-emacs <at> gnu.org:bug#29066; Package emacs.
(Tue, 31 Oct 2017 20:36:02 GMT) Full text and rfc822 format available.Message #43 received at 29066 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Andreas Schwab <schwab <at> linux-m68k.org> Cc: 29066 <at> debbugs.gnu.org, mshinwell <at> janestreet.com, vgatien-baron <at> janestreet.com Subject: Re: bug#29066: 26.0.90; crash in gc involving buffer local symbols Date: Tue, 31 Oct 2017 22:34:17 +0200
> From: Andreas Schwab <schwab <at> linux-m68k.org> > Cc: vgatien-baron <at> janestreet.com, 29066 <at> debbugs.gnu.org, mshinwell <at> janestreet.com > Date: Tue, 31 Oct 2017 21:23:09 +0100 > > On Okt 31 2017, Eli Zaretskii <eliz <at> gnu.org> wrote: > > > It isn't freed, it's on the symbol_free_list. > > A symbol on the symbol_free_list is a freed symbol, not available for > use. I guess you are saying that sweep_symbols has a bug? Because it hits this "freed" symbol every GC, AFAICT.
bug-gnu-emacs <at> gnu.org:bug#29066; Package emacs.
(Tue, 31 Oct 2017 21:04:01 GMT) Full text and rfc822 format available.Message #46 received at 29066 <at> debbugs.gnu.org (full text, mbox):
From: Andreas Schwab <schwab <at> linux-m68k.org> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 29066 <at> debbugs.gnu.org, mshinwell <at> janestreet.com, vgatien-baron <at> janestreet.com Subject: Re: bug#29066: 26.0.90; crash in gc involving buffer local symbols Date: Tue, 31 Oct 2017 22:03:26 +0100
On Okt 31 2017, Eli Zaretskii <eliz <at> gnu.org> wrote: >> From: Andreas Schwab <schwab <at> linux-m68k.org> >> Cc: vgatien-baron <at> janestreet.com, 29066 <at> debbugs.gnu.org, mshinwell <at> janestreet.com >> Date: Tue, 31 Oct 2017 21:23:09 +0100 >> >> On Okt 31 2017, Eli Zaretskii <eliz <at> gnu.org> wrote: >> >> > It isn't freed, it's on the symbol_free_list. >> >> A symbol on the symbol_free_list is a freed symbol, not available for >> use. > > I guess you are saying that sweep_symbols has a bug? Because it hits > this "freed" symbol every GC, AFAICT. Since GC is special, it needs to do special things. Andreas. -- Andreas Schwab, schwab <at> linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
bug-gnu-emacs <at> gnu.org:bug#29066; Package emacs.
(Tue, 31 Oct 2017 21:10:01 GMT) Full text and rfc822 format available.Message #49 received at 29066 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Andreas Schwab <schwab <at> linux-m68k.org> Cc: 29066 <at> debbugs.gnu.org, mshinwell <at> janestreet.com, vgatien-baron <at> janestreet.com Subject: Re: bug#29066: 26.0.90; crash in gc involving buffer local symbols Date: Tue, 31 Oct 2017 23:08:58 +0200
> From: Andreas Schwab <schwab <at> linux-m68k.org> > Cc: vgatien-baron <at> janestreet.com, 29066 <at> debbugs.gnu.org, mshinwell <at> janestreet.com > Date: Tue, 31 Oct 2017 22:03:26 +0100 > > >> A symbol on the symbol_free_list is a freed symbol, not available for > >> use. > > > > I guess you are saying that sweep_symbols has a bug? Because it hits > > this "freed" symbol every GC, AFAICT. > > Since GC is special, it needs to do special things. But the crash due to double-free did happen as part of GC doing those "special things". So we are talking about those special things, not something else.
bug-gnu-emacs <at> gnu.org:bug#29066; Package emacs.
(Tue, 31 Oct 2017 22:01:03 GMT) Full text and rfc822 format available.Message #52 received at 29066 <at> debbugs.gnu.org (full text, mbox):
From: Andreas Schwab <schwab <at> linux-m68k.org> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 29066 <at> debbugs.gnu.org, mshinwell <at> janestreet.com, vgatien-baron <at> janestreet.com Subject: Re: bug#29066: 26.0.90; crash in gc involving buffer local symbols Date: Tue, 31 Oct 2017 23:00:10 +0100
On Okt 31 2017, Eli Zaretskii <eliz <at> gnu.org> wrote: >> From: Andreas Schwab <schwab <at> linux-m68k.org> >> Cc: vgatien-baron <at> janestreet.com, 29066 <at> debbugs.gnu.org, mshinwell <at> janestreet.com >> Date: Tue, 31 Oct 2017 22:03:26 +0100 >> >> >> A symbol on the symbol_free_list is a freed symbol, not available for >> >> use. >> > >> > I guess you are saying that sweep_symbols has a bug? Because it hits >> > this "freed" symbol every GC, AFAICT. >> >> Since GC is special, it needs to do special things. > > But the crash due to double-free did happen as part of GC doing those > "special things". That's why it helps to clear the pointer to the freed memory, instead of leaving it dangling. Andreas. -- Andreas Schwab, schwab <at> linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org.
(Wed, 29 Nov 2017 12:24:04 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.