Open comicfans opened 5 years ago
#2 0x56284154d553 in win_update .../neovim-git/src/nvim/screen.c:1429
I wonder why syntax_present(wp)
is true at this point. Or how did update_screen
find that buffer, since it was closed by close_buffer
?
I've hit similar bug but with different alloc/free backtrace , with version v0.4.0-784-gc6cd6081b ,
==nvim==10474==ERROR: AddressSanitizer: heap-use-after-free on address 0x62f0000e0408 at pc 0x00000178eac2 bp 0x7ffc946a1900 sp 0x7ffc946a18f8 READ of size 8 at 0x62f0000e0408 thread T0 #0 0x178eac1 in syn_stack_find_entry /home/wangxinyu/neovim/build/../src/nvim/syntax.c:1228:12 #1 0x1792f34 in syntax_end_parsing /home/wangxinyu/neovim/build/../src/nvim/syntax.c:1460:8 #2 0x147faec in win_update /home/wangxinyu/neovim/build/../src/nvim/screen.c:1433:5 #3 0x14602ed in update_screen /home/wangxinyu/neovim/build/../src/nvim/screen.c:475:7 #4 0x1185b17 in normal_redraw /home/wangxinyu/neovim/build/../src/nvim/normal.c:1246:5 #5 0x11833fd in normal_check /home/wangxinyu/neovim/build/../src/nvim/normal.c:1323:5 #6 0x176d38a in state_enter /home/wangxinyu/neovim/build/../src/nvim/state.c:28:35 #7 0x10df0e6 in normal_enter /home/wangxinyu/neovim/build/../src/nvim/normal.c:462:3 #8 0xebce89 in main /home/wangxinyu/neovim/build/../src/nvim/main.c:598:3 #9 0x7fa534343ce2 in __libc_start_main (/usr/lib/libc.so.6+0x23ce2) #10 0x45745d in _start (/home/wangxinyu/.local/bin/nvim+0x45745d) 0x62f0000e0408 is located 8 bytes inside of 52920-byte region [0x62f0000e0400,0x62f0000ed2b8) freed by thread T0 here: #0 0x4e5b00 in free /home/wangxinyu/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cc:123:3 #1 0xfdb374 in xfree /home/wangxinyu/neovim/build/../src/nvim/memory.c:118:3 #2 0x1790fec in syn_stack_free_block /home/wangxinyu/neovim/build/../src/nvim/syntax.c:999:5 #3 0x17909d4 in syn_stack_free_all /home/wangxinyu/neovim/build/../src/nvim/syntax.c:1009:3 #4 0x179eaf4 in syntax_clear /home/wangxinyu/neovim/build/../src/nvim/syntax.c:3195:3 #5 0x6c5fd6 in buf_freeall /home/wangxinyu/neovim/build/../src/nvim/buffer.c:745:3 #6 0x6bdcf7 in close_buffer /home/wangxinyu/neovim/build/../src/nvim/buffer.c:560:3 #7 0x1aaaa18 in win_close /home/wangxinyu/neovim/build/../src/nvim/window.c:2396:5 #8 0xc0f491 in ex_quit /home/wangxinyu/neovim/build/../src/nvim/ex_docmd.c:6103:5 #9 0xba19b8 in do_one_cmd /home/wangxinyu/neovim/build/../src/nvim/ex_docmd.c:2240:5 #10 0xb844d2 in do_cmdline /home/wangxinyu/neovim/build/../src/nvim/ex_docmd.c:593:20 #11 0x113a0de in nv_colon /home/wangxinyu/neovim/build/../src/nvim/normal.c:4587:18 #12 0x1123ff5 in normal_execute /home/wangxinyu/neovim/build/../src/nvim/normal.c:1130:3 #13 0x176d718 in state_enter /home/wangxinyu/neovim/build/../src/nvim/state.c:73:26 #14 0x10df0e6 in normal_enter /home/wangxinyu/neovim/build/../src/nvim/normal.c:462:3 #15 0xebce89 in main /home/wangxinyu/neovim/build/../src/nvim/main.c:598:3 #16 0x7fa534343ce2 in __libc_start_main (/usr/lib/libc.so.6+0x23ce2) previously allocated by thread T0 here: #0 0x4e5fc0 in calloc /home/wangxinyu/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cc:154:3 #1 0xfdb416 in xcalloc /home/wangxinyu/neovim/build/../src/nvim/memory.c:132:15 #2 0x17839a1 in syn_stack_alloc /home/wangxinyu/neovim/build/../src/nvim/syntax.c:1056:12 #3 0x1780bcc in syntax_start /home/wangxinyu/neovim/build/../src/nvim/syntax.c:425:3 #4 0x14bd0e5 in win_line /home/wangxinyu/neovim/build/../src/nvim/screen.c:2204:7 #5 0x147db3f in win_update /home/wangxinyu/neovim/build/../src/nvim/screen.c:1372:15 #6 0x14602ed in update_screen /home/wangxinyu/neovim/build/../src/nvim/screen.c:475:7 #7 0x1185b17 in normal_redraw /home/wangxinyu/neovim/build/../src/nvim/normal.c:1246:5 #8 0x11833fd in normal_check /home/wangxinyu/neovim/build/../src/nvim/normal.c:1323:5 #9 0x176d38a in state_enter /home/wangxinyu/neovim/build/../src/nvim/state.c:28:35 #10 0x10df0e6 in normal_enter /home/wangxinyu/neovim/build/../src/nvim/normal.c:462:3 #11 0xebce89 in main /home/wangxinyu/neovim/build/../src/nvim/main.c:598:3 #12 0x7fa534343ce2 in __libc_start_main (/usr/lib/libc.so.6+0x23ce2) SUMMARY: AddressSanitizer: heap-use-after-free /home/wangxinyu/neovim/build/../src/nvim/syntax.c:1228:12 in syn_stack_find_entry Shadow bytes around the buggy address: 0x0c5e80014030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c5e80014040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c5e80014050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c5e80014060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c5e80014070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c5e80014080: fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c5e80014090: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c5e800140a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c5e800140b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c5e800140c0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c5e800140d0: 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 Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 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 Left alloca redzone: ca Right alloca redzone: cb Shadow gap: cc ==nvim==10474==ABORTING
@comicfans please use the latest version, that version is missing many patches. We have merged some Vim bug-fixes, so it's more helpful to test with those fixes :)
@justinmk I've built latest neovim , but build libluv dependency is very annoying :
@comicfants, @justinmk it is IMHO a mistake of neovim to require luv.h file: luv is a Lua extension module, and so it should not use C header file.
luv is a Lua extension module, and so it should not use C header file.
It is a extension module implemented as a C library. How would we register the event loop and add it to the lua interpreter without using the C API?
Yes, sorry, it is probably nonsense. Ignore me.
How can I try to reproduce this myself?
@ngortheone:
I'm not the author, but I believe he was using Clang's AddressSanitizer, in a nutshell, compile nvim using latest clang with flags -g -fsanitize=address -fno-omit-frame-pointer
, read more at https://clang.llvm.org/docs/AddressSanitizer.html.
If you're going to build on OSX, you may need export below variables and ensure makefile will receive them correctly (ex: CCFLAGS := $(CCFLAGS)
then CCFLAGS += ...
):
export CCFLAGS="-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/"
export CXXFLAGS="-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/"
export OBJCFLAGS="-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/"
export LDFLAGS="-L/usr/local/opt/llvm/lib -Wl,-rpath,/usr/local/opt/llvm/lib"
@thenewvu thanks, I will try to reproduce the issue.
I'm on linux , using clang as compiler and turn neovim CMake option CLANG_ASAN_UBSAN=ON. neovim default build Debug version so I think there is no need to add -fno-omit-frame-pointer
CC=clang CXX=clang++ make CMAKE_FLAGS="-DCLANG_ASAN_UBSAN=ON"
@comicfans I am on archlinux too. I compiled with options you specified successfully without any errors or warnings.
CC=clang CXX=clang++ make CMAKE_FLAGS="-DCLANG_ASAN_UBSAN=ON"
Do I need to take any extra steps to reproduce the problem?
I was able to get a different error. I used debug build for a while and when I exited nvim I got a leak
==17503==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 147 byte(s) in 2 object(s) allocated from:
#0 0x55fe68bb0f9a (/home/ngor/dev/github.com/neovim/neovim/build/bin/nvim+0x2fbf9a)
#1 0x55fe69116d52 (/home/ngor/dev/github.com/neovim/neovim/build/bin/nvim+0x861d52)
#2 0x55fe69116f04 (/home/ngor/dev/github.com/neovim/neovim/build/bin/nvim+0x861f04)
#3 0x55fe69117301 (/home/ngor/dev/github.com/neovim/neovim/build/bin/nvim+0x862301)
#4 0x55fe69117378 (/home/ngor/dev/github.com/neovim/neovim/build/bin/nvim+0x862378)
#5 0x55fe693fa314 (/home/ngor/dev/github.com/neovim/neovim/build/bin/nvim+0xb45314)
#6 0x55fe693e6a33 (/home/ngor/dev/github.com/neovim/neovim/build/bin/nvim+0xb31a33)
#7 0x55fe693d79fc (/home/ngor/dev/github.com/neovim/neovim/build/bin/nvim+0xb229fc)
#8 0x55fe693cfeae (/home/ngor/dev/github.com/neovim/neovim/build/bin/nvim+0xb1aeae)
#9 0x55fe690abf9a (/home/ngor/dev/github.com/neovim/neovim/build/bin/nvim+0x7f6f9a)
#10 0x55fe68f5520a (/home/ngor/dev/github.com/neovim/neovim/build/bin/nvim+0x6a020a)
#11 0x55fe68f23a8d (/home/ngor/dev/github.com/neovim/neovim/build/bin/nvim+0x66ea8d)
#12 0x55fe68f128bb (/home/ngor/dev/github.com/neovim/neovim/build/bin/nvim+0x65d8bb)
#13 0x55fe68f16033 (/home/ngor/dev/github.com/neovim/neovim/build/bin/nvim+0x661033)
#14 0x55fe691c6807 (/home/ngor/dev/github.com/neovim/neovim/build/bin/nvim+0x911807)
#15 0x55fe691b6f23 (/home/ngor/dev/github.com/neovim/neovim/build/bin/nvim+0x901f23)
#16 0x55fe6948a241 (/home/ngor/dev/github.com/neovim/neovim/build/bin/nvim+0xbd5241)
#17 0x55fe69193362 (/home/ngor/dev/github.com/neovim/neovim/build/bin/nvim+0x8de362)
#18 0x55fe690a3430 (/home/ngor/dev/github.com/neovim/neovim/build/bin/nvim+0x7ee430)
#19 0x7fb3f17f2ee2 (/usr/lib/libc.so.6+0x26ee2)
SUMMARY: AddressSanitizer: 147 byte(s) leaked in 2 allocation(s).
@justinmk please advice on the next steps. Should I create a different issue for this? And how can I can symbols attached to this trace?
@ngortheone
I was able to get a different error.
Likely unrelated / known issue during exit (could not find the issue, but there's one - low prio since it is small and happens on exit only IIRC).
In general you just need to have llvm-symbolizer
in the PATH. The README (src/nvim/README.md) might be a bit too verbose in this regard.
@ngortheone
Do I need to take any extra steps to reproduce the problem?
Yeah.. those do not show up when compiling, but only when running into the issue - we do not have repro steps. Typically you would use an ASAN enabled build, and watch out for any issue popping up there.
@comicfans
I've built latest neovim , but build libluv dependency is very annoying :
Normally it should work out of the box when using the bundled versions, doesn't it? (there have been fixes in this regard, so it might work better for you) I am typically not using the bundled versions, since it is slower to build from scratch, but as a fallback it should work (and is also used on CI).
@blueyed @comicfans
Typically you would use an ASAN enabled build, and watch out for any issue popping up there.
I will use ASAN enabled build instead of release build for a couple of days..
@comicfans @blueyed @justinmk I've been using master ASAN enabled build for over a week as a daily driver . I was not able to reproduce this issue. Only memory leak mentioned above that happens on exit.
I'm not sure if this is same bug, but I can confirm similar crash still exists in latest code (version shows dirty because I have some additional lines in .asan-blacklist to avoid other asan crash, no other src modification)
NVIM v0.5.0-729-gf7aeac726-dirty
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: /home/wangxinyu/.local/bin/clang -O2 -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=always -fno-sanitize-recover=all -fno-omit-frame-pointer -fno-optimize-sibling-calls -fsanitize=address -fsanitize=undefined -fsanitize-blacklist=/home/wangxinyu/neovim/src/.asan-blacklist -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -DEXITFREE -I/home/wangxinyu/neovim/build/config -I/home/wangxinyu/neovim/src -I/usr/include -I/home/wangxinyu/neovim/.deps/usr/include -I/home/wangxinyu/neovim/build/src/nvim/auto -I/home/wangxinyu/neovim/build/include
Compiled by wangxinyu@RESEARCH
Features: +acl +iconv +tui
See ":help feature-compile"
system vimrc file: "$VIM/sysinit.vim"
fall-back for $VIM: "/home/wangxinyu/.local/share/nvim"
Run :checkhealth for more info
similar crash backtrace:
=================================================================
==nvim==7710==ERROR: AddressSanitizer: heap-use-after-free on address 0x62700158edf8 at pc 0x000000b8907e bp 0x7ffc7b828360 sp 0x7ffc7b828358
READ of size 8 at 0x62700158edf8 thread T0
#0 0xb8907d in syn_stack_find_entry /home/wangxinyu/neovim/build/../src/nvim/syntax.c
#1 0xb89e3d in syntax_end_parsing /home/wangxinyu/neovim/build/../src/nvim/syntax.c:1464:8
#2 0xa9bab0 in win_update /home/wangxinyu/neovim/build/../src/nvim/screen.c:1548:5
#3 0xa91a14 in update_screen /home/wangxinyu/neovim/build/../src/nvim/screen.c:544:7
#4 0x9951e4 in normal_redraw /home/wangxinyu/neovim/build/../src/nvim/normal.c:1254:5
#5 0x9951e4 in normal_check /home/wangxinyu/neovim/build/../src/nvim/normal.c:1338:5
#6 0xb7da6d in state_enter /home/wangxinyu/neovim/build/../src/nvim/state.c:28:35
#7 0x95b8a8 in normal_enter /home/wangxinyu/neovim/build/../src/nvim/normal.c:463:3
#8 0x8a5730 in main /home/wangxinyu/neovim/build/../src/nvim/main.c:557:3
#9 0x7f2ec4c2c152 in __libc_start_main (/usr/lib/libc.so.6+0x27152)
#10 0x46573d in _start (/home/wangxinyu/.local/bin/nvim+0x46573d)
0x62700158edf8 is located 11512 bytes inside of 12120-byte region [0x62700158c100,0x62700158f058)
freed by thread T0 here:
#0 0x5067df in free /home/wangxinyu/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:123:3
#1 0x909968 in xfree /home/wangxinyu/neovim/build/../src/nvim/memory.c:119:3
#2 0x5c5182 in free_buffer /home/wangxinyu/neovim/build/../src/nvim/buffer.c:789:5
#3 0x5c1f77 in close_buffer /home/wangxinyu/neovim/build/../src/nvim/buffer.c:622:5
#4 0x5c6988 in do_buffer /home/wangxinyu/neovim/build/../src/nvim/buffer.c:1292:9
#5 0x5c99da in do_bufdel /home/wangxinyu/neovim/build/../src/nvim/buffer.c:975:11
#6 0x79e042 in ex_bunload /home/wangxinyu/neovim/build/../src/nvim/ex_docmd.c:4787:17
#7 0x77eca7 in do_one_cmd /home/wangxinyu/neovim/build/../src/nvim/ex_docmd.c:1961:5
#8 0x7769a8 in do_cmdline /home/wangxinyu/neovim/build/../src/nvim/ex_docmd.c:601:20
#9 0x77a581 in do_cmdline_cmd /home/wangxinyu/neovim/build/../src/nvim/ex_docmd.c:287:10
#10 0xbcd30c in terminal_enter /home/wangxinyu/neovim/build/../src/nvim/terminal.c:392:7
#11 0x626c21 in edit /home/wangxinyu/neovim/build/../src/nvim/edit.c:1382:7
#12 0x991caa in invoke_edit /home/wangxinyu/neovim/build/../src/nvim/normal.c:7666:7
#13 0x97e1c3 in nv_edit /home/wangxinyu/neovim/build/../src/nvim/normal.c:7638:5
#14 0x972795 in normal_execute /home/wangxinyu/neovim/build/../src/nvim/normal.c:1138:3
#15 0xb7db3d in state_enter /home/wangxinyu/neovim/build/../src/nvim/state.c:69:26
#16 0x95b8a8 in normal_enter /home/wangxinyu/neovim/build/../src/nvim/normal.c:463:3
#17 0x8a5730 in main /home/wangxinyu/neovim/build/../src/nvim/main.c:557:3
#18 0x7f2ec4c2c152 in __libc_start_main (/usr/lib/libc.so.6+0x27152)
previously allocated by thread T0 here:
#0 0x506c97 in calloc /home/wangxinyu/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:154:3
#1 0x9099a2 in xcalloc /home/wangxinyu/neovim/build/../src/nvim/memory.c:133:15
#2 0x5c8748 in buflist_new /home/wangxinyu/neovim/build/../src/nvim/buffer.c:1767:11
#3 0x742037 in do_ecmd /home/wangxinyu/neovim/build/../src/nvim/ex_cmds.c:2307:13
#4 0x797234 in do_exedit /home/wangxinyu/neovim/build/../src/nvim/ex_docmd.c:7242:11
#5 0x79660f in ex_splitview /home/wangxinyu/neovim/build/../src/nvim/ex_docmd.c:6977:5
#6 0x77eca7 in do_one_cmd /home/wangxinyu/neovim/build/../src/nvim/ex_docmd.c:1961:5
#7 0x7769a8 in do_cmdline /home/wangxinyu/neovim/build/../src/nvim/ex_docmd.c:601:20
#8 0x687735 in ex_execute /home/wangxinyu/neovim/build/../src/nvim/eval.c:9438:7
#9 0x77eca7 in do_one_cmd /home/wangxinyu/neovim/build/../src/nvim/ex_docmd.c:1961:5
#10 0x7769a8 in do_cmdline /home/wangxinyu/neovim/build/../src/nvim/ex_docmd.c:601:20
#11 0x7161a3 in call_user_func /home/wangxinyu/neovim/build/../src/nvim/eval/userfunc.c:1059:5
#12 0x714580 in call_func /home/wangxinyu/neovim/build/../src/nvim/eval/userfunc.c:1501:11
#13 0x7135e5 in get_func_tv /home/wangxinyu/neovim/build/../src/nvim/eval/userfunc.c:430:11
#14 0x7238f8 in ex_call /home/wangxinyu/neovim/build/../src/nvim/eval/userfunc.c:2891:9
#15 0x77eca7 in do_one_cmd /home/wangxinyu/neovim/build/../src/nvim/ex_docmd.c:1961:5
#16 0x7769a8 in do_cmdline /home/wangxinyu/neovim/build/../src/nvim/ex_docmd.c:601:20
#17 0x7161a3 in call_user_func /home/wangxinyu/neovim/build/../src/nvim/eval/userfunc.c:1059:5
#18 0x714580 in call_func /home/wangxinyu/neovim/build/../src/nvim/eval/userfunc.c:1501:11
#19 0x7135e5 in get_func_tv /home/wangxinyu/neovim/build/../src/nvim/eval/userfunc.c:430:11
#20 0x7238f8 in ex_call /home/wangxinyu/neovim/build/../src/nvim/eval/userfunc.c:2891:9
#21 0x77eca7 in do_one_cmd /home/wangxinyu/neovim/build/../src/nvim/ex_docmd.c:1961:5
#22 0x7769a8 in do_cmdline /home/wangxinyu/neovim/build/../src/nvim/ex_docmd.c:601:20
#23 0x7161a3 in call_user_func /home/wangxinyu/neovim/build/../src/nvim/eval/userfunc.c:1059:5
#24 0x714580 in call_func /home/wangxinyu/neovim/build/../src/nvim/eval/userfunc.c:1501:11
#25 0x7135e5 in get_func_tv /home/wangxinyu/neovim/build/../src/nvim/eval/userfunc.c:430:11
#26 0x7238f8 in ex_call /home/wangxinyu/neovim/build/../src/nvim/eval/userfunc.c:2891:9
#27 0x77eca7 in do_one_cmd /home/wangxinyu/neovim/build/../src/nvim/ex_docmd.c:1961:5
#28 0x7769a8 in do_cmdline /home/wangxinyu/neovim/build/../src/nvim/ex_docmd.c:601:20
#29 0x7161a3 in call_user_func /home/wangxinyu/neovim/build/../src/nvim/eval/userfunc.c:1059:5
SUMMARY: AddressSanitizer: heap-use-after-free /home/wangxinyu/neovim/build/../src/nvim/syntax.c in syn_stack_find_entry
Shadow bytes around the buggy address:
0x0c4e802a9d60: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c4e802a9d70: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c4e802a9d80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c4e802a9d90: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c4e802a9da0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x0c4e802a9db0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd[fd]
0x0c4e802a9dc0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c4e802a9dd0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c4e802a9de0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c4e802a9df0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c4e802a9e00: fd fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa
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
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
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
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==nvim==7710==ABORTING
nvim -version
Steps to reproduce using
nvim -u NORC
not tried
asan.error.5794.txt