Hirohito Higashi wrote:
> 2018-9-28(Fri) 20:59:50 UTC+9 Dominique Pelle: > > Philipp Gesang wrote: > > > > > Hello, > > > > > > with this minimal vimrc > > > > > > set nocompatible > > > syntax enable > > > " adjust redrawtime to match machine speed > > > "set redrawtime=100 > > > " mapping to repeat command quickly > > > nmap <silent> <F12> :syntax sync fromstart<CR>:syntax sync > > > fromstart<CR> > > > > > > I get a segfault by opening the reproducer file > > > https://www.phi-gamma.net/misc/reproducer.rst and then typing > > > <S-g><F12>. The cause appears to be a use-after-free that occurs > > > when redrawtime elapses before the syntax highlighting is done. > > > On my box (“Intel(R) Core(TM) i7-4771 CPU @ 3.50GHz”) it is > > > reproducible up to a limit of ~4250 ms; with larger values there > > > is no crash. > > > > I can confirm the bug with latest vim (8.1.1436, x86_64, Linux) > > using a asan build (same stack as bug submitter): > > > > ================================================================= > > ==8477==ERROR: AddressSanitizer: heap-use-after-free on address > > 0x7f17ac379808 at pc 0x00000084588b bp 0x7ffeb22bcae0 sp > > 0x7ffeb22bcad0 > > READ of size 8 at 0x7f17ac379808 thread T0 > > #0 0x84588a in syn_stack_find_entry /home/dope/sb/vim/src/syntax.c:1457 > > #1 0x8473e3 in syntax_end_parsing /home/dope/sb/vim/src/syntax.c:1716 > > #2 0x7987e9 in win_update /home/dope/sb/vim/src/screen.c:2241 > > #3 0x7913e7 in update_screen /home/dope/sb/vim/src/screen.c:783 > > #4 0x9b6ef2 in main_loop /home/dope/sb/vim/src/main.c:1251 > > #5 0x9b64c0 in vim_main2 /home/dope/sb/vim/src/main.c:919 > > #6 0x9b5a31 in main /home/dope/sb/vim/src/main.c:443 > > #7 0x7f17b297a82f in __libc_start_main > > (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) > > #8 0x4063f8 in _start (/home/dope/sb/vim/src/vim+0x4063f8) > > > > 0x7f17ac379808 is located 8 bytes inside of 210168-byte region > > [0x7f17ac379800,0x7f17ac3accf8) > > freed by thread T0 here: > > #0 0x7f17b44e832a in __interceptor_free > > (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x9832a) > > #1 0x64be5e in vim_free /home/dope/sb/vim/src/misc2.c:1837 > > #2 0x844095 in syn_stack_free_block /home/dope/sb/vim/src/syntax.c:1194 > > #3 0x844129 in syn_stack_free_all /home/dope/sb/vim/src/syntax.c:1209 > > #4 0x85fa5d in syn_cmd_sync /home/dope/sb/vim/src/syntax.c:5997 > > #5 0x861155 in ex_syntax /home/dope/sb/vim/src/syntax.c:6397 > > #6 0x51fbbe in do_one_cmd /home/dope/sb/vim/src/ex_docmd.c:2533 > > #7 0x519dda in do_cmdline /home/dope/sb/vim/src/ex_docmd.c:1041 > > #8 0x6955d7 in nv_colon /home/dope/sb/vim/src/normal.c:5401 > > #9 0x67c6ec in normal_cmd /home/dope/sb/vim/src/normal.c:1134 > > #10 0x9b72a2 in main_loop /home/dope/sb/vim/src/main.c:1372 > > #11 0x9b64c0 in vim_main2 /home/dope/sb/vim/src/main.c:919 > > #12 0x9b5a31 in main /home/dope/sb/vim/src/main.c:443 > > #13 0x7f17b297a82f in __libc_start_main > > (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) > > > > previously allocated by thread T0 here: > > #0 0x7f17b44e8662 in malloc > > (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98662) > > #1 0x649f1e in lalloc /home/dope/sb/vim/src/misc2.c:976 > > #2 0x649e11 in alloc_clear /home/dope/sb/vim/src/misc2.c:898 > > #3 0x8445ed in syn_stack_alloc /home/dope/sb/vim/src/syntax.c:1260 > > #4 0x841afe in syntax_start /home/dope/sb/vim/src/syntax.c:548 > > #5 0x79f854 in win_line /home/dope/sb/vim/src/screen.c:3286 > > #6 0x798031 in win_update /home/dope/sb/vim/src/screen.c:2144 > > #7 0x7913e7 in update_screen /home/dope/sb/vim/src/screen.c:783 > > #8 0x9b6ef2 in main_loop /home/dope/sb/vim/src/main.c:1251 > > #9 0x9b64c0 in vim_main2 /home/dope/sb/vim/src/main.c:919 > > #10 0x9b5a31 in main /home/dope/sb/vim/src/main.c:443 > > #11 0x7f17b297a82f in __libc_start_main > > (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) > > > > SUMMARY: AddressSanitizer: heap-use-after-free > > /home/dope/sb/vim/src/syntax.c:1457 syn_stack_find_entry > > Shadow bytes around the buggy address: > > 0x0fe3758672b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > > 0x0fe3758672c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > > 0x0fe3758672d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > > 0x0fe3758672e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > > 0x0fe3758672f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > > =>0x0fe375867300: fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd > > 0x0fe375867310: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > > 0x0fe375867320: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > > 0x0fe375867330: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > > 0x0fe375867340: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > > 0x0fe375867350: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > > Shadow byte legend (one shadow byte represents 8 application bytes): > > Addressable: 00 > > Partially addressable: 01 02 03 04 05 06 07 > > Heap left redzone: fa > > Heap right redzone: fb > > Freed heap region: fd > > Stack left redzone: f1 > > Stack mid redzone: f2 > > Stack right redzone: f3 > > Stack partial redzone: f4 > > Stack after return: f5 > > Stack use after scope: f8 > > Global redzone: f9 > > Global init order: f6 > > Poisoned by user: f7 > > Container overflow: fc > > Array cookie: ac > > Intra object redzone: bb > > ASan internal: fe > > ==8477==ABORTING > > > Please try an attached patch. > It seems for me that the problem has been resolved. Thanks for the patch. I think it's slightly better to set _first to NULL when clearing the array, so that we don't have to check two pointers to be NULL. It's a bit unexpected, which was part of the reason the problem was introduced. -- hundred-and-one symptoms of being an internet addict: 110. You actually volunteer to become your employer's webmaster. /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
