forked from neovim/neovim
-
Notifications
You must be signed in to change notification settings - Fork 1
uname -a
on WSL includes "Microsoft", not "Windows"
#1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
justinmk
merged 1 commit into
justinmk:win-wsl-cwd-clipboard
from
mqudsi:mqudsi/wsl-pwd-fix
Jul 15, 2017
Merged
uname -a
on WSL includes "Microsoft", not "Windows"
#1
justinmk
merged 1 commit into
justinmk:win-wsl-cwd-clipboard
from
mqudsi:mqudsi/wsl-pwd-fix
Jul 15, 2017
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Full uname for reference: Linux ZBook 4.4.0-43-Microsoft neovim#1-Microsoft Wed Dec 31 14:42:53 PST 2014 x86_64 x86_64 x86_64 GNU/Linux
justinmk
added a commit
that referenced
this pull request
Jul 29, 2017
term_input_start should be called only once. This fixes a leak introduced by af2e629. Closes neovim#6780 Steps to demonstrate memory leak: CC=clang CFLAGS=" -O0 -g -DEXITFREE " cmake .. -DMIN_LOG_LEVEL=0 -DCMAKE_BUILD_TYPE=Debug -DBUSTED_OUTPUT_TYPE=nvim -DCMAKE_INSTALL_PREFIX=$PWD/root -DCLANG_ASAN_UBSAN=ON -DPREFER_LUAJIT=false nvim -u NONE -i NONE --cmd $'function S()\nsuspend\nendfunction' --cmd 'inoremap <expr> X S()' --cmd 'call feedkeys("iX", "t")' fg<CR><Esc>:cq<CR> ``` ================================================================= ==25050==ERROR: LeakSanitizer: detected memory leaks Direct leak of 4159 byte(s) in 1 object(s) allocated from: #0 0x4f6a30 in calloc /var/tmp/portage/sys-devel/llvm-3.9.1-r1/work/llvm-3.9.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:72 #1 0xf8d222 in xcalloc /home/zyx/a.a/Proj/c/neovim/src/nvim/memory.c:147:15 #2 0x1349d28 in rbuffer_new /home/zyx/a.a/Proj/c/neovim/src/nvim/rbuffer.c:24:17 #3 0xa6867b in rstream_init /home/zyx/a.a/Proj/c/neovim/src/nvim/event/rstream.c:42:20 #4 0xa68651 in rstream_init_fd /home/zyx/a.a/Proj/c/neovim/src/nvim/event/rstream.c:28:3 #5 0x1866451 in term_input_init /home/zyx/a.a/Proj/c/neovim/src/nvim/tui/input.c:55:3 #6 0x187f049 in tui_terminal_start /home/zyx/a.a/Proj/c/neovim/src/nvim/tui/tui.c:223:3 neovim#7 0x187b491 in tui_main /home/zyx/a.a/Proj/c/neovim/src/nvim/tui/tui.c:258:3 neovim#8 0x18b3171 in ui_thread_run /home/zyx/a.a/Proj/c/neovim/src/nvim/ui_bridge.c:124:3 neovim#9 0x7f54c2d5f39b (/lib64/libpthread.so.0+0x739b) Direct leak of 4159 byte(s) in 1 object(s) allocated from: #0 0x4f6a30 in calloc /var/tmp/portage/sys-devel/llvm-3.9.1-r1/work/llvm-3.9.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:72 #1 0xf8d222 in xcalloc /home/zyx/a.a/Proj/c/neovim/src/nvim/memory.c:147:15 #2 0x1349d28 in rbuffer_new /home/zyx/a.a/Proj/c/neovim/src/nvim/rbuffer.c:24:17 #3 0x1865a4a in term_input_init /home/zyx/a.a/Proj/c/neovim/src/nvim/tui/input.c:29:23 #4 0x187f049 in tui_terminal_start /home/zyx/a.a/Proj/c/neovim/src/nvim/tui/tui.c:223:3 #5 0x187b491 in tui_main /home/zyx/a.a/Proj/c/neovim/src/nvim/tui/tui.c:258:3 #6 0x18b3171 in ui_thread_run /home/zyx/a.a/Proj/c/neovim/src/nvim/ui_bridge.c:124:3 neovim#7 0x7f54c2d5f39b (/lib64/libpthread.so.0+0x739b) Indirect leak of 7144 byte(s) in 62 object(s) allocated from: #0 0x4f6840 in malloc /var/tmp/portage/sys-devel/llvm-3.9.1-r1/work/llvm-3.9.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64 #1 0x7f54c231636c (/usr/lib64/libtermkey.so.1+0x636c) Indirect leak of 1500 byte(s) in 75 object(s) allocated from: #0 0x4f6840 in malloc /var/tmp/portage/sys-devel/llvm-3.9.1-r1/work/llvm-3.9.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64 #1 0x7f54c2316b34 (/usr/lib64/libtermkey.so.1+0x6b34) Indirect leak of 704 byte(s) in 1 object(s) allocated from: #0 0x4f6840 in malloc /var/tmp/portage/sys-devel/llvm-3.9.1-r1/work/llvm-3.9.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64 #1 0x7f54c23129dd in _init (/usr/lib64/libtermkey.so.1+0x29dd) Indirect leak of 520 byte(s) in 1 object(s) allocated from: #0 0x4f6c40 in realloc /var/tmp/portage/sys-devel/llvm-3.9.1-r1/work/llvm-3.9.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:77 #1 0x7f54c2313b7c in termkey_register_keyname (/usr/lib64/libtermkey.so.1+0x3b7c) Indirect leak of 256 byte(s) in 1 object(s) allocated from: #0 0x4f6840 in malloc /var/tmp/portage/sys-devel/llvm-3.9.1-r1/work/llvm-3.9.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64 #1 0x7f54c2313c3c (/usr/lib64/libtermkey.so.1+0x3c3c) Indirect leak of 48 byte(s) in 2 object(s) allocated from: #0 0x4f6840 in malloc /var/tmp/portage/sys-devel/llvm-3.9.1-r1/work/llvm-3.9.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64 #1 0x7f54c2313d9e (/usr/lib64/libtermkey.so.1+0x3d9e) Indirect leak of 40 byte(s) in 1 object(s) allocated from: #0 0x4f6840 in malloc /var/tmp/portage/sys-devel/llvm-3.9.1-r1/work/llvm-3.9.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64 #1 0x7f54c2316553 (/usr/lib64/libtermkey.so.1+0x6553) Indirect leak of 24 byte(s) in 1 object(s) allocated from: #0 0x4f6840 in malloc /var/tmp/portage/sys-devel/llvm-3.9.1-r1/work/llvm-3.9.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64 #1 0x7f54c2315a2f (/usr/lib64/libtermkey.so.1+0x5a2f) Indirect leak of 8 byte(s) in 1 object(s) allocated from: #0 0x485ca8 in __interceptor_strdup /var/tmp/portage/sys-devel/llvm-3.9.1-r1/work/llvm-3.9.1.src/projects/compiler-rt/lib/asan/asan_interceptors.cc:562 #1 0x7f54c2316bef (/usr/lib64/libtermkey.so.1+0x6bef) Indirect leak of 8 byte(s) in 1 object(s) allocated from: #0 0x485ca8 in __interceptor_strdup /var/tmp/portage/sys-devel/llvm-3.9.1-r1/work/llvm-3.9.1.src/projects/compiler-rt/lib/asan/asan_interceptors.cc:562 #1 0x7f54c2316c0f (/usr/lib64/libtermkey.so.1+0x6c0f) Indirect leak of 4 byte(s) in 1 object(s) allocated from: #0 0x4f6840 in malloc /var/tmp/portage/sys-devel/llvm-3.9.1-r1/work/llvm-3.9.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64 #1 0x7f54c2316a26 (/usr/lib64/libtermkey.so.1+0x6a26) SUMMARY: AddressSanitizer: 18574 byte(s) leaked in 149 allocation(s). ```
justinmk
pushed a commit
that referenced
this pull request
Jul 29, 2017
The clear_screen capability moves the cursor position. This needs to be accounted for.
justinmk
pushed a commit
that referenced
this pull request
Jul 29, 2017
Apparently on travis OS X systems it crashes when cleaning up streams with stdout closed: (lldb) bt all * thread #1: tid = 0x0000, 0x00007fff8703df06 libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGSTOP * frame #0: 0x00007fff8703df06 libsystem_kernel.dylib`__pthread_kill + 10 frame #1: 0x00007fff93a764ec libsystem_pthread.dylib`pthread_kill + 90 frame #2: 0x00007fff97c056df libsystem_c.dylib`abort + 129 frame #3: 0x00007fff97bccdd8 libsystem_c.dylib`__assert_rtn + 321 frame #4: 0x0000000107a4e106 nvim`uv__close(fd=<unavailable>) + 102 at core.c:521 frame #5: 0x0000000107a5307d nvim`uv__loop_close(loop=0x00007fff5847c018) + 77 at loop.c:118 frame #6: 0x0000000107a4d149 nvim`uv_loop_close(loop=0x00007fff5847c018) + 57 at uv-common.c:626 frame neovim#7: 0x000000010783e5bc nvim`stream_set_blocking(fd=0, blocking=true) + 204 at stream.c:34 frame neovim#8: 0x000000010795d66b nvim`mch_exit(r=0) + 91 at os_unix.c:147 frame neovim#9: 0x00000001078d5663 nvim`command_line_scan(parmp=0x00007fff5847c760) + 1779 at main.c:787 frame neovim#10: 0x00000001078d4393 nvim`main(argc=2, argv=0x00007fff5847c898) + 163 at main.c:249 frame neovim#11: 0x00007fff8cdd65ad libdyld.dylib`start + 1 frame neovim#12: 0x00007fff8cdd65ad libdyld.dylib`start + 1
justinmk
added a commit
that referenced
this pull request
Aug 18, 2017
[----------] 1 test from /home/travis/build/neovim/neovim/test/functional/api/rpc_spec.lua (233.78 ms total) [----------] Running tests from /home/travis/build/neovim/neovim/test/functional/api/server_notifications_spec.lua [ RUN ] notify passing a valid channel id sends the notification/args to the corresponding channel: 2.00 ms OK ==================== File /home/travis/build/neovim/neovim/build/log/ubsan.11959 ==================== = = ================================================================= = ==11959==ERROR: LeakSanitizer: detected memory leaks = = Direct leak of 64 byte(s) in 1 object(s) allocated from: = #0 0x510e9d in calloc (/home/travis/build/neovim/neovim/build/bin/nvim+0x510e9d) = #1 0xfc58d2 in xcalloc /home/travis/build/neovim/neovim/src/nvim/memory.c:147:15 = #2 0x10b3f70 in msgpack_rpc_to_object /home/travis/build/neovim/neovim/src/nvim/msgpack_rpc/helpers.c:161:23 = #3 0x10a7816 in complete_call /home/travis/build/neovim/neovim/src/nvim/msgpack_rpc/channel.c:859:5 = #4 0x10a533a in parse_msgpack /home/travis/build/neovim/neovim/src/nvim/msgpack_rpc/channel.c:430:9 = #5 0x1098282 in receive_msgpack /home/travis/build/neovim/neovim/src/nvim/msgpack_rpc/channel.c:410:3 = #6 0xa9e83b in read_event /home/travis/build/neovim/neovim/src/nvim/event/rstream.c:190:5 = neovim#7 0xa9d9b5 in invoke_read_cb /home/travis/build/neovim/neovim/src/nvim/event/rstream.c:203:3 = neovim#8 0xa9c146 in read_cb /home/travis/build/neovim/neovim/src/nvim/event/rstream.c:136:3 = neovim#9 0x19e5783 in uv__read /home/travis/nvim-deps/build/src/libuv/src/unix/stream.c:1231 = = Indirect leak of 48720 byte(s) in 202 object(s) allocated from: = #0 0x510e9d in calloc (/home/travis/build/neovim/neovim/build/bin/nvim+0x510e9d) = #1 0xfc58d2 in xcalloc /home/travis/build/neovim/neovim/src/nvim/memory.c:147:15 = #2 0x10b7ae9 in msgpack_rpc_to_object /home/travis/build/neovim/neovim/src/nvim/msgpack_rpc/helpers.c:216:23 = #3 0x10a7816 in complete_call /home/travis/build/neovim/neovim/src/nvim/msgpack_rpc/channel.c:859:5 = #4 0x10a533a in parse_msgpack /home/travis/build/neovim/neovim/src/nvim/msgpack_rpc/channel.c:430:9 = #5 0x1098282 in receive_msgpack /home/travis/build/neovim/neovim/src/nvim/msgpack_rpc/channel.c:410:3 = #6 0xa9e83b in read_event /home/travis/build/neovim/neovim/src/nvim/event/rstream.c:190:5 = neovim#7 0xa9d9b5 in invoke_read_cb /home/travis/build/neovim/neovim/src/nvim/event/rstream.c:203:3 = neovim#8 0xa9c146 in read_cb /home/travis/build/neovim/neovim/src/nvim/event/rstream.c:136:3 = neovim#9 0x19e5783 in uv__read /home/travis/nvim-deps/build/src/libuv/src/unix/stream.c:1231 = = Indirect leak of 33344 byte(s) in 441 object(s) allocated from: = #0 0x510e9d in calloc (/home/travis/build/neovim/neovim/build/bin/nvim+0x510e9d) = #1 0xfc58d2 in xcalloc /home/travis/build/neovim/neovim/src/nvim/memory.c:147:15 = #2 0x10b3f70 in msgpack_rpc_to_object /home/travis/build/neovim/neovim/src/nvim/msgpack_rpc/helpers.c:161:23 = #3 0x10a7816 in complete_call /home/travis/build/neovim/neovim/src/nvim/msgpack_rpc/channel.c:859:5 = #4 0x10a533a in parse_msgpack /home/travis/build/neovim/neovim/src/nvim/msgpack_rpc/channel.c:430:9 = #5 0x1098282 in receive_msgpack /home/travis/build/neovim/neovim/src/nvim/msgpack_rpc/channel.c:410:3 = #6 0xa9e83b in read_event /home/travis/build/neovim/neovim/src/nvim/event/rstream.c:190:5 = neovim#7 0xa9d9b5 in invoke_read_cb /home/travis/build/neovim/neovim/src/nvim/event/rstream.c:203:3 = neovim#8 0xa9c146 in read_cb /home/travis/build/neovim/neovim/src/nvim/event/rstream.c:136:3 = neovim#9 0x19e5783 in uv__read /home/travis/nvim-deps/build/src/libuv/src/unix/stream.c:1231 = = Indirect leak of 8958 byte(s) in 1015 object(s) allocated from: = #0 0x510ce6 in malloc (/home/travis/build/neovim/neovim/build/bin/nvim+0x510ce6) = #1 0xfc5574 in try_malloc /home/travis/build/neovim/neovim/src/nvim/memory.c:87:15 = #2 0xfc5734 in xmalloc /home/travis/build/neovim/neovim/src/nvim/memory.c:121:15 = #3 0xfc5bd3 in xmallocz /home/travis/build/neovim/neovim/src/nvim/memory.c:196:15 = #4 0xfc5cc8 in xmemdupz /home/travis/build/neovim/neovim/src/nvim/memory.c:214:17 = #5 0x10b59f8 in msgpack_rpc_to_object /home/travis/build/neovim/neovim/src/nvim/msgpack_rpc/helpers.c:185:15 = #6 0x10a7816 in complete_call /home/travis/build/neovim/neovim/src/nvim/msgpack_rpc/channel.c:859:5 = neovim#7 0x10a533a in parse_msgpack /home/travis/build/neovim/neovim/src/nvim/msgpack_rpc/channel.c:430:9 = neovim#8 0x1098282 in receive_msgpack /home/travis/build/neovim/neovim/src/nvim/msgpack_rpc/channel.c:410:3 = neovim#9 0xa9e83b in read_event /home/travis/build/neovim/neovim/src/nvim/event/rstream.c:190:5 = neovim#10 0xa9d9b5 in invoke_read_cb /home/travis/build/neovim/neovim/src/nvim/event/rstream.c:203:3 = neovim#11 0xa9c146 in read_cb /home/travis/build/neovim/neovim/src/nvim/event/rstream.c:136:3 = neovim#12 0x19e5783 in uv__read /home/travis/nvim-deps/build/src/libuv/src/unix/stream.c:1231 = = Indirect leak of 8561 byte(s) in 927 object(s) allocated from: = #0 0x510ce6 in malloc (/home/travis/build/neovim/neovim/build/bin/nvim+0x510ce6) = #1 0xfc5574 in try_malloc /home/travis/build/neovim/neovim/src/nvim/memory.c:87:15 = #2 0xfc5734 in xmalloc /home/travis/build/neovim/neovim/src/nvim/memory.c:121:15 = #3 0xfc5bd3 in xmallocz /home/travis/build/neovim/neovim/src/nvim/memory.c:196:15 = #4 0xfc5cc8 in xmemdupz /home/travis/build/neovim/neovim/src/nvim/memory.c:214:17 = #5 0x10b15f6 in msgpack_rpc_to_object /home/travis/build/neovim/neovim/src/nvim/msgpack_rpc/helpers.c:143:7 = #6 0x10a7816 in complete_call /home/travis/build/neovim/neovim/src/nvim/msgpack_rpc/channel.c:859:5 = neovim#7 0x10a533a in parse_msgpack /home/travis/build/neovim/neovim/src/nvim/msgpack_rpc/channel.c:430:9 = neovim#8 0x1098282 in receive_msgpack /home/travis/build/neovim/neovim/src/nvim/msgpack_rpc/channel.c:410:3 = neovim#9 0xa9e83b in read_event /home/travis/build/neovim/neovim/src/nvim/event/rstream.c:190:5 = neovim#10 0xa9d9b5 in invoke_read_cb /home/travis/build/neovim/neovim/src/nvim/event/rstream.c:203:3 = neovim#11 0xa9c146 in read_cb /home/travis/build/neovim/neovim/src/nvim/event/rstream.c:136:3 = neovim#12 0x19e5783 in uv__read /home/travis/nvim-deps/build/src/libuv/src/unix/stream.c:1231 = = SUMMARY: AddressSanitizer: 99647 byte(s) leaked in 2586 allocation(s). =====================================================================================================
justinmk
pushed a commit
that referenced
this pull request
Sep 27, 2018
When building with -DEXITFREE, the ILOG call would result in a crash trying to access VV_PROGPATH, which had already been released: (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x00007f8f761082f1 in __GI_abort () at abort.c:79 #2 0x00007f8f760ffa8a in __assert_fail_base (fmt=0x7f8f76253ec8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x1c74280 <.str.8> " ,\t\n", file=file@entry=0x1c73fe2 "256]'", line=line@entry=610, function=function@entry=0x1c742e0 <.str.9+32> "") at assert.c:92 #3 0x00007f8f760ffb02 in __GI___assert_fail (assertion=0x1c74280 <.str.8> " ,\t\n", file=0x1c73fe2 "256]'", line=610, function=0x1c742e0 <.str.9+32> "") at assert.c:101 #4 0x00000000012d87c1 in vim_getenv (name=0x2f5a460 <get_special_key_name.string+64> "NVIM_LOG_FILE") at ../src/nvim/os/env.c:608 #5 0x00000000012d6538 in expand_env_esc (srcp=0x1c2f4e0 <.str.10+32> "", dst=0x2f5a460 <get_special_key_name.string+64> "NVIM_LOG_FILE", dstlen=4095, esc=false, one=false, prefix=0x0) at ../src/nvim/os/env.c:351 #6 0x00000000012d85af in expand_env_esc (srcp=0x625000000100 "\004", dst=0x7ffeed88cf40 "", dstlen=32766, esc=237, one=136, prefix=0x60200401c8b4 <error: Cannot access memory at address 0x60200401c8b4>) at ../src/nvim/os/env.c:472 neovim#7 0x0000000000eb4274 in do_log_to_file (log_file=0x0, log_level=0, context=0x0, func_name=0x0, line_num=0, eol=false, fmt=0x0) at ../src/nvim/log.c:254 neovim#8 0x0000000000eb305b in open_log_file () at ../src/nvim/log.c:164 neovim#9 0x0000000000eb2cc6 in logmsg (log_level=<error reading variable: Cannot access memory at address 0x268>, context=<error reading variable: Cannot access memory at address 0x260>, func_name=<error reading variable: Cannot access memory at address 0x258>, line_num=<error reading variable: Cannot access memory at address 0x254>, eol=<error reading variable: Cannot access memory at address 0x253>, fmt=<error reading variable: Cannot access memory at address 0x248>) at ../src/nvim/log.c:109 neovim#10 0x00000000013022c7 in mch_free_acl (aclent=0x4f59100) at ../src/nvim/os_unix.c:132 neovim#11 0x0000000000efddac in getout (exitval=0) at ../src/nvim/main.c:681 neovim#12 0x0000000000c1bb3e in ex_quit (eap=0x7ffeed88cd00) at ../src/nvim/ex_docmd.c:6067 neovim#13 0x0000000000bab781 in do_one_cmd (cmdlinep=0x7ffeed88f180, flags=10, cstack=0x7ffeed88f1a0, fgetline=0x0, cookie=0x0) at ../src/nvim/ex_docmd.c:2228 neovim#14 0x0000000000b8de6d in do_cmdline (cmdline=0x7ffeed891ae2 "quit", fgetline=0x0, cookie=0x0, flags=10) at ../src/nvim/ex_docmd.c:592 neovim#15 0x0000000000b94036 in do_cmdline_cmd (cmd=0x7ffeed891ae2 "quit") at ../src/nvim/ex_docmd.c:268 neovim#16 0x0000000000efb900 in exe_commands (parmp=0x7ffeed890900) at ../src/nvim/main.c:1699 neovim#17 0x0000000000ee96b2 in main (argc=11, argv=0x7ffeed890fa8) at ../src/nvim/main.c:524
justinmk
added a commit
that referenced
this pull request
May 21, 2019
==27323==ERROR: AddressSanitizer: SEGV on unknown address 0xfffffffffffffff1 (pc 0x000000455aa1 bp 0x7ffc3872f860 sp 0x7ffc3872f7f0 T0) ==27323==The signal is caused by a WRITE memory access. #0 0x455aa0 in __asan::asan_free(void*, __sanitizer::BufferedStackTrace*, __asan::AllocType) (/home/travis/build/neovim/neovim/build/bin/nvim+0x455aa0) #1 0x508f5c in __interceptor_cfree.localalias.0 (/home/travis/build/neovim/neovim/build/bin/nvim+0x508f5c) #2 0x11a1d34 in xfree_ /home/travis/build/neovim/neovim/build/../src/nvim/memory.c:117:3 #3 0xf7c3d1 in hash_clear /home/travis/build/neovim/neovim/build/../src/nvim/hashtab.c:60:5 #4 0xf7c991 in hash_clear_all /home/travis/build/neovim/neovim/build/../src/nvim/hashtab.c:76:3 #5 0x19034f8 in slang_clear /home/travis/build/neovim/neovim/build/../src/nvim/spell.c:1768:3 #6 0x19db5b6 in spell_reload_one /home/travis/build/neovim/neovim/build/../src/nvim/spellfile.c:1791:7 neovim#7 0x19a5c25 in mkspell /home/travis/build/neovim/neovim/build/../src/nvim/spellfile.c:5245:9 neovim#8 0x19a8b9a in spell_add_word /home/travis/build/neovim/neovim/build/../src/nvim/spellfile.c:5439:5 neovim#9 0x13729d2 in nv_zet /home/travis/build/neovim/neovim/build/../src/nvim/normal.c:4506:5 neovim#10 0x1318bab in normal_execute /home/travis/build/neovim/neovim/build/../src/nvim/normal.c:1128:3 neovim#11 0x130eefc in normal_cmd /home/travis/build/neovim/neovim/build/../src/nvim/normal.c:8031:9 neovim#12 0xd057a8 in exec_normal /home/travis/build/neovim/neovim/build/../src/nvim/ex_docmd.c:8319:5 neovim#13 0xd054ab in exec_normal_cmd /home/travis/build/neovim/neovim/build/../src/nvim/ex_docmd.c:8302:3 neovim#14 0xd46d7c in ex_normal /home/travis/build/neovim/neovim/build/../src/nvim/ex_docmd.c:8212:7 neovim#15 0xccca79 in do_one_cmd /home/travis/build/neovim/neovim/build/../src/nvim/ex_docmd.c:2243:5 neovim#16 0xcaa13c in do_cmdline /home/travis/build/neovim/neovim/build/../src/nvim/ex_docmd.c:593:20
justinmk
added a commit
that referenced
this pull request
Sep 2, 2019
For debugging failures like: test/functional/helpers.lua:240: test/functional/ui/screen.lua:898: bad argument #1 to 'unpack' (table expected, got number) test/functional/helpers.lua:240: test/functional/ui/screen.lua:708: attempt to index local 'item' (a number value) ref neovim#10804
justinmk
added a commit
that referenced
this pull request
May 28, 2022
Problem: 22b52dd (neovim#11501) regressed 6f27f5e (neovim#10172), because set_init_1..process_spawn tries to log (see backtrace below), but the mutex isn't initalized yet. Even if the mutex were valid, we don't want early logging to fallback to stderr because that can break embedders when stdio is used as an RPC channel. Solution: - Skip logging if log_init wasn't called yet. - FUTURE: when "remote TUI" is merged, can we remove log_lock()? frame #1: 0x00000001001d54f4 nvim`open_log_file at log.c:205:7 frame #2: 0x00000001001d5390 nvim`logmsg(log_level=1, context="UI: ", func_name=0x0000000000000000, line_num=-1, eol=true, fmt="win_viewport") at log.c:150:20 frame #3: 0x000000010039aea2 nvim`ui_call_win_viewport(grid=2, win=1000, topline=0, botline=1, curline=0, curcol=0, line_count=1) at ui_events_call.generated.h:321:3 frame #4: 0x00000001003dfefc nvim`ui_ext_win_viewport(wp=0x0000000101816400) at window.c:939:5 frame #5: 0x00000001003ec5b4 nvim`win_ui_flush at window.c:7303:7 frame #6: 0x00000001003a04c0 nvim`ui_flush at ui.c:508:3 frame neovim#7: 0x00000001002966ba nvim`do_os_system(argv=0x0000600000c0c000, input=0x0000000000000000, len=0, output=0x0000000000000000, nread=0x00007ff7bfefe830, silent=false, forward_output=false) at shell.c:894:3 frame neovim#8: 0x0000000100295f68 nvim`os_call_shell(cmd="unset nonomatch; vimglob() { while [ $# -ge 1 ]; do echo \"$1\"; shift; done }; vimglob >/var/folders/gk/3tttv_md06987tlwpyp62jrw0000gn/T/nvimwwvwfD/0 ~foo", opts=kShellOptExpand | kShellOptSilent | kShellOptHideMess, extra_args=0x0000000000000000) at shell.c:663:18 frame neovim#9: 0x0000000100295845 nvim`call_shell(cmd="unset nonomatch; vimglob() { while [ $# -ge 1 ]; do echo \"$1\"; shift; done }; vimglob >/var/folders/gk/3tttv_md06987tlwpyp62jrw0000gn/T/nvimwwvwfD/0 ~foo", opts=kShellOptExpand | kShellOptSilent | kShellOptHideMess, extra_shell_arg=0x0000000000000000) at shell.c:712:14 frame neovim#10: 0x0000000100294c6f nvim`os_expand_wildcards(num_pat=1, pat=0x00007ff7bfefeb20, num_file=0x00007ff7bfefee58, file=0x00007ff7bfefee60, flags=43) at shell.c:328:7 ... frame neovim#23: 0x000000010028ccef nvim`expand_env_esc(srcp=",~foo", dst="~foo", dstlen=4094, esc=false, one=false, prefix=0x0000000000000000) at env.c:673:17 frame neovim#24: 0x000000010026fdd5 nvim`option_expand(opt_idx=29, val=",~foo") at option.c:1950:3 frame neovim#25: 0x000000010026f129 nvim`set_init_1(clean_arg=false) at option.c:558:19 frame neovim#26: 0x00000001001ea25e nvim`early_init(paramp=0x00007ff7bfeff5f0) at main.c:198:3 frame neovim#27: 0x00000001001ea6bf nvim`main(argc=1, argv=0x00007ff7bfeff848) at main.c:255:3
justinmk
added a commit
that referenced
this pull request
May 28, 2022
Problem: 22b52dd (neovim#11501) regressed 6f27f5e (neovim#10172), because set_init_1..process_spawn tries to log (see backtrace below), but the mutex isn't initalized yet. Even if the mutex were valid, we don't want early logging to fallback to stderr because that can break embedders when stdio is used as an RPC channel. Solution: - Skip logging if log_init wasn't called yet. - FUTURE: when "remote TUI" is merged, can we remove log_lock()? frame #1: 0x00000001001d54f4 nvim`open_log_file at log.c:205:7 frame #2: 0x00000001001d5390 nvim`logmsg(log_level=1, context="UI: ", func_name=0x0000000000000000, line_num=-1, eol=true, fmt="win_viewport") at log.c:150:20 frame #3: 0x000000010039aea2 nvim`ui_call_win_viewport(grid=2, win=1000, topline=0, botline=1, curline=0, curcol=0, line_count=1) at ui_events_call.generated.h:321:3 frame #4: 0x00000001003dfefc nvim`ui_ext_win_viewport(wp=0x0000000101816400) at window.c:939:5 frame #5: 0x00000001003ec5b4 nvim`win_ui_flush at window.c:7303:7 frame #6: 0x00000001003a04c0 nvim`ui_flush at ui.c:508:3 frame neovim#7: 0x00000001002966ba nvim`do_os_system(argv=0x0000600000c0c000, input=0x0000000000000000, len=0, output=0x0000000000000000, nread=0x00007ff7bfefe830, silent=false, forward_output=false) at shell.c:894:3 frame neovim#8: 0x0000000100295f68 nvim`os_call_shell(cmd="unset nonomatch; vimglob() { while [ $# -ge 1 ]; do echo \"$1\"; shift; done }; vimglob >/var/folders/gk/3tttv_md06987tlwpyp62jrw0000gn/T/nvimwwvwfD/0 ~foo", opts=kShellOptExpand | kShellOptSilent | kShellOptHideMess, extra_args=0x0000000000000000) at shell.c:663:18 frame neovim#9: 0x0000000100295845 nvim`call_shell(cmd="unset nonomatch; vimglob() { while [ $# -ge 1 ]; do echo \"$1\"; shift; done }; vimglob >/var/folders/gk/3tttv_md06987tlwpyp62jrw0000gn/T/nvimwwvwfD/0 ~foo", opts=kShellOptExpand | kShellOptSilent | kShellOptHideMess, extra_shell_arg=0x0000000000000000) at shell.c:712:14 frame neovim#10: 0x0000000100294c6f nvim`os_expand_wildcards(num_pat=1, pat=0x00007ff7bfefeb20, num_file=0x00007ff7bfefee58, file=0x00007ff7bfefee60, flags=43) at shell.c:328:7 ... frame neovim#23: 0x000000010028ccef nvim`expand_env_esc(srcp=",~foo", dst="~foo", dstlen=4094, esc=false, one=false, prefix=0x0000000000000000) at env.c:673:17 frame neovim#24: 0x000000010026fdd5 nvim`option_expand(opt_idx=29, val=",~foo") at option.c:1950:3 frame neovim#25: 0x000000010026f129 nvim`set_init_1(clean_arg=false) at option.c:558:19 frame neovim#26: 0x00000001001ea25e nvim`early_init(paramp=0x00007ff7bfeff5f0) at main.c:198:3 frame neovim#27: 0x00000001001ea6bf nvim`main(argc=1, argv=0x00007ff7bfeff848) at main.c:255:3
justinmk
added a commit
that referenced
this pull request
May 28, 2022
Problem: 22b52dd (neovim#11501) regressed 6f27f5e (neovim#10172), because set_init_1..process_spawn tries to log (see backtrace below), but the mutex isn't initalized yet. Even if the mutex were valid, we don't want early logging to fallback to stderr because that can break embedders when stdio is used as an RPC channel. Solution: - Skip logging if log_init wasn't called yet. - FUTURE: when "remote TUI" is merged, can we remove log_lock()? frame #1: 0x00000001001d54f4 nvim`open_log_file at log.c:205:7 frame #2: 0x00000001001d5390 nvim`logmsg(log_level=1, context="UI: ", func_name=0x0000000000000000, line_num=-1, eol=true, fmt="win_viewport") at log.c:150:20 frame #3: 0x000000010039aea2 nvim`ui_call_win_viewport(grid=2, win=1000, topline=0, botline=1, curline=0, curcol=0, line_count=1) at ui_events_call.generated.h:321:3 frame #4: 0x00000001003dfefc nvim`ui_ext_win_viewport(wp=0x0000000101816400) at window.c:939:5 frame #5: 0x00000001003ec5b4 nvim`win_ui_flush at window.c:7303:7 frame #6: 0x00000001003a04c0 nvim`ui_flush at ui.c:508:3 frame neovim#7: 0x00000001002966ba nvim`do_os_system(argv=0x0000600000c0c000, input=0x0000000000000000, len=0, output=0x0000000000000000, nread=0x00007ff7bfefe830, silent=false, forward_output=false) at shell.c:894:3 frame neovim#8: 0x0000000100295f68 nvim`os_call_shell(cmd="unset nonomatch; vimglob() { while [ $# -ge 1 ]; do echo \"$1\"; shift; done }; vimglob >/var/folders/gk/3tttv_md06987tlwpyp62jrw0000gn/T/nvimwwvwfD/0 ~foo", opts=kShellOptExpand | kShellOptSilent | kShellOptHideMess, extra_args=0x0000000000000000) at shell.c:663:18 frame neovim#9: 0x0000000100295845 nvim`call_shell(cmd="unset nonomatch; vimglob() { while [ $# -ge 1 ]; do echo \"$1\"; shift; done }; vimglob >/var/folders/gk/3tttv_md06987tlwpyp62jrw0000gn/T/nvimwwvwfD/0 ~foo", opts=kShellOptExpand | kShellOptSilent | kShellOptHideMess, extra_shell_arg=0x0000000000000000) at shell.c:712:14 frame neovim#10: 0x0000000100294c6f nvim`os_expand_wildcards(num_pat=1, pat=0x00007ff7bfefeb20, num_file=0x00007ff7bfefee58, file=0x00007ff7bfefee60, flags=43) at shell.c:328:7 ... frame neovim#23: 0x000000010028ccef nvim`expand_env_esc(srcp=",~foo", dst="~foo", dstlen=4094, esc=false, one=false, prefix=0x0000000000000000) at env.c:673:17 frame neovim#24: 0x000000010026fdd5 nvim`option_expand(opt_idx=29, val=",~foo") at option.c:1950:3 frame neovim#25: 0x000000010026f129 nvim`set_init_1(clean_arg=false) at option.c:558:19 frame neovim#26: 0x00000001001ea25e nvim`early_init(paramp=0x00007ff7bfeff5f0) at main.c:198:3 frame neovim#27: 0x00000001001ea6bf nvim`main(argc=1, argv=0x00007ff7bfeff848) at main.c:255:3
justinmk
added a commit
that referenced
this pull request
May 29, 2022
Problem: 1. The main log routine does not protect itself against recursion. log_lock() doesn't guard against recursion, it would deadlock... 2. 22b52dd (neovim#11501) regressed 6f27f5e (neovim#10172), because set_init_1..process_spawn tries to log (see backtrace below), but the mutex isn't initalized yet. Even if the mutex were valid, we don't want early logging to fallback to stderr because that can break embedders when stdio is used as an RPC channel. frame #1: 0x00000001001d54f4 nvim`open_log_file at log.c:205:7 frame #2: 0x00000001001d5390 nvim`logmsg(log_level=1, context="UI: ", func_name=0x0000000000000000, line_num=-1, eol=true, fmt="win_viewport") at log.c:150:20 frame #3: 0x000000010039aea2 nvim`ui_call_win_viewport(grid=2, win=1000, topline=0, botline=1, curline=0, curcol=0, line_count=1) at ui_events_call.generated.h:321:3 frame #4: 0x00000001003dfefc nvim`ui_ext_win_viewport(wp=0x0000000101816400) at window.c:939:5 frame #5: 0x00000001003ec5b4 nvim`win_ui_flush at window.c:7303:7 frame #6: 0x00000001003a04c0 nvim`ui_flush at ui.c:508:3 frame neovim#7: 0x00000001002966ba nvim`do_os_system(argv=0x0000600000c0c000, input=0x0000000000000000, len=0, output=0x0000000000000000, nread=0x00007ff7bfefe830, silent=false, forward_output=false) at shell.c:894:3 frame neovim#8: 0x0000000100295f68 nvim`os_call_shell(cmd="unset nonomatch; vimglob() { while [ $# -ge 1 ]; do echo \"$1\"; shift; done }; vimglob >/var/folders/gk/3tttv_md06987tlwpyp62jrw0000gn/T/nvimwwvwfD/0 ~foo", opts=kShellOptExpand | kShellOptSilent | kShellOptHideMess, extra_args=0x0000000000000000) at shell.c:663:18 frame neovim#9: 0x0000000100295845 nvim`call_shell(cmd="unset nonomatch; vimglob() { while [ $# -ge 1 ]; do echo \"$1\"; shift; done }; vimglob >/var/folders/gk/3tttv_md06987tlwpyp62jrw0000gn/T/nvimwwvwfD/0 ~foo", opts=kShellOptExpand | kShellOptSilent | kShellOptHideMess, extra_shell_arg=0x0000000000000000) at shell.c:712:14 frame neovim#10: 0x0000000100294c6f nvim`os_expand_wildcards(num_pat=1, pat=0x00007ff7bfefeb20, num_file=0x00007ff7bfefee58, file=0x00007ff7bfefee60, flags=43) at shell.c:328:7 ... frame neovim#23: 0x000000010028ccef nvim`expand_env_esc(srcp=",~foo", dst="~foo", dstlen=4094, esc=false, one=false, prefix=0x0000000000000000) at env.c:673:17 frame neovim#24: 0x000000010026fdd5 nvim`option_expand(opt_idx=29, val=",~foo") at option.c:1950:3 frame neovim#25: 0x000000010026f129 nvim`set_init_1(clean_arg=false) at option.c:558:19 frame neovim#26: 0x00000001001ea25e nvim`early_init(paramp=0x00007ff7bfeff5f0) at main.c:198:3 frame neovim#27: 0x00000001001ea6bf nvim`main(argc=1, argv=0x00007ff7bfeff848) at main.c:255:3 Solution: 1. Check for recursion and log to stderr. - FUTURE: when "remote TUI" is merged, can we remove log_lock()? 2. Skip logging if log_init wasn't called yet.
justinmk
pushed a commit
that referenced
this pull request
Jul 15, 2022
Problem ------- In neovim#19040, I reported two things that started happening somewhen in the last three months when using neovim in hterm (the Chrome Secure Shell terminal): 1. Under certain circumstances, the window title (set by nvim [i0]) would appear over the line I was typing, corrupting the screen. 2. If I changed my $TERM from xterm-256color to the new hterm-256color (available since ncurses >=20210320), the window title corruption was gone, but pane scrolling was broken. Both problems are due to changes in the termcap files, their source of truth being the ncurses project. See "Timeline of ncurses changes" below for details. Cause: title corruption ----------------------- The title corruption when using hterm + TERM=xterm-256color can be explained by event #4 (ncurses 2022-03-12) in the ncurses timeline: The xterm-256color termcap file gained status line termcodes in ncurses 2022-03-12. These termcodes are used by Neovim to set the title when. hterm does not have a status line. Due to ncurses versions earlier than 2022-03-12 missing the xterm status line capability, Neovim manually fixed up [t0] the terminfo file if $TERM was xterm-256color. So if before Neovim manually added fsl/tsl capabilties, and after they were in the termcap file, why did hterm suddenly start getting corruption? The answer is that the termcodes for these capabilties are different when Neovim fixes them up, versus the one in the new termcap database: fsl=\E[0$} // from xterm-256color tsl=\E[2$~\E[1$}\E[%i%p1%d` // from xterm-256color fsl=\x07 // patched by Neovim tsl=\x1b]0; // patched by Neovim hterm ignores the latter, but corrupts the screen with the former. Solution: Make hterm users set hterm-256color, which lacks the new fsl/tsl codes. Also, to reduce superfluous work, stop patching in this capability when hterm is detected (even if hterm would ignore the patched version). Cause: pane corruption ---------------------- The pane corruption when using hterm + TERM=hterm-256color, but NOT when using hterm + TERM=xterm-256color can be explained by: - Neovim uses DECSLRM when available [p1] for performant scrolling. - Both the hterm-256color and xterm-256color termcap databases advertise support for DECSLRM (ncurses timeline #1, #2 and #3). - hterm does not support DESCLRM [p2] (note: it does support DESCTBM for top/bottom scrolling, but it's broken [p3] and not used by Neovim) - xterm-alikes that are not real xterm generally don't support DECSLRM either, so Neovim patches it out [p4]. When using hterm-256color, hterm is no longer considered an xterm-alike by Neovim. As a result, DECSLRM is not cleared. hterm does not support it, so corruption ensues. This is a problem with the hterm-256color termcap file, but we're stuck with it so the best we can do is patch over it. Timeline of ncurses changes --------------------------- 1. 2019-05-19: Part of the DECSLRM capability (smglr AKA set_lr_margin) added to vt420+lrmm, which xterm-256color inherits [n1] 2. 2021-03-20: hterm-256color added, inheriting xterm-256colors. [n2] 3. 2021-09-25: The *parm versions of smglr (AKA set_lr_margin) were added to vt420+lrmm [n3]. Namely: 1. smglp AKA set_left_margin_parm, and 2. smgrp AKA set_right_margin_parm 4. 2022-03-12: (new) codes for fsl, bsl and tsl added to xterm (add dec+sl to xterm-new, per patch neovim#371 -TD) [n4] Fixes neovim#19040. [i0]: https://github.com/neovim/neovim/blob/3a4fa22badc5595afc0a994ead965ff32ccf6c76/src/nvim/tui/tui.c#L1377 [t0]: https://github.com/neovim/neovim/blob/3a4fa22badc5595afc0a994ead965ff32ccf6c76/src/nvim/tui/tui.c#L1728,L1729 [p1]: https://github.com/neovim/neovim/blob/3a4fa22badc5595afc0a994ead965ff32ccf6c76/src/nvim/tui/tui.c#L1196 [p2]: https://bugs.chromium.org/p/chromium/issues/detail?id=1175065&q=component%3APlatform%3EApps%3EDefault%3EHterm [p3]: https://bugs.chromium.org/p/chromium/issues/detail?id=1298796&q=component%3APlatform%3EApps%3EDefault%3EHterm [p4]: https://github.com/neovim/neovim/blob/3a4fa22badc5595afc0a994ead965ff32ccf6c76/src/nvim/tui/tui.c#L1740-L1752 [n1]: mirror/ncurses@8f6d94b#diff-01544c577762d3308a1d232aa7afc79acf64b9a5057f88a004df82fda89549b7R2742 [n2]: mirror/ncurses@c265010#diff-01544c577762d3308a1d232aa7afc79acf64b9a5057f88a004df82fda89549b7R5907 [n3]: mirror/ncurses@f6b436c#diff-01544c577762d3308a1d232aa7afc79acf64b9a5057f88a004df82fda89549b7R2842 [n4]: mirror/ncurses@8bf8c83#diff-01544c577762d3308a1d232aa7afc79acf64b9a5057f88a004df82fda89549b7R4828 Signed-off-by: Nicolas Hillegeer <nicolas@hillegeer.com>
justinmk
pushed a commit
that referenced
this pull request
Mar 5, 2023
Fixes: Error SERVER_REQUEST_HANDLER_ERROR: "...di/dev/neovim/neovim/runtime/lua/vim/lsp/_watchfiles.lua :200: bad argument #1 to 'ipairs' (table expected, got nil)" Language servers can be started without root_dir or workspace_folders.
justinmk
pushed a commit
that referenced
this pull request
Apr 21, 2023
fix(usercmd): fix buffer overflow in uc_list() Build with: -Wp,-D_FORTIFY_SOURCE=3 -O1 and gcc 13. *** buffer overflow detected ***: terminated (gdb) bt #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x00007f3eb8b93c03 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78 #2 0x00007f3eb8b42aee in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007f3eb8b2b87f in __GI_abort () at abort.c:79 #4 0x00007f3eb8b2c60f in __libc_message (fmt=fmt@entry=0x7f3eb8ca72e6 "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:150 #5 0x00007f3eb8c27b29 in __GI___fortify_fail (msg=msg@entry=0x7f3eb8ca728c "buffer overflow detected") at fortify_fail.c:24 #6 0x00007f3eb8c26364 in __GI___chk_fail () at chk_fail.c:28 neovim#7 0x00007f3eb8c25f45 in ___snprintf_chk (s=s@entry=0x55b8c7c096a5 <IObuff+5> "t' item", maxlen=maxlen@entry=1025, flag=flag@entry=2, slen=slen@entry=1020, format=format@entry=0x55b8c7b872a6 "%ldc") at snprintf_chk.c:29 neovim#8 0x000055b8c7aea59f in snprintf (__fmt=0x55b8c7b872a6 "%ldc", __n=1025, __s=0x55b8c7c096a5 <IObuff+5> "t' item") at /usr/include/bits/stdio2.h:54 neovim#9 uc_list (name=name@entry=0x55b8c8351788 "Explore", name_len=name_len@entry=7) at /usr/src/debug/neovim-0.9.0-1.fc38.x86_64/src/nvim/usercmd.c:534 neovim#10 0x000055b8c7aeb8a0 in ex_command (eap=0x7fffdc350e60) at /usr/src/debug/neovim-0.9.0-1.fc38.x86_64/src/nvim/usercmd.c:1009 neovim#11 0x000055b8c7972537 in execute_cmd0 (retv=retv@entry=0x7fffdc350e54, eap=eap@entry=0x7fffdc350e60, errormsg=errormsg@entry=0x7fffdc350e58, preview=preview@entry=false) at /usr/src/debug/neovim-0.9.0-1.fc38.x86_64/src/nvim/ex_docmd.c:1620 neovim#12 0x000055b8c7975c55 in do_one_cmd (cmdlinep=cmdlinep@entry=0x7fffdc3510b8, flags=flags@entry=0, cstack=cstack@entry=0x7fffdc351140, fgetline=fgetline@entry=0x55b8c79882b8 <getexline>, cookie=cookie@entry=0x0) at /usr/src/debug/neovim-0.9.0-1.fc38.x86_64/src/nvim/ex_docmd.c:2279 neovim#13 0x000055b8c79767fe in do_cmdline (cmdline=<optimized out>, fgetline=0x55b8c79882b8 <getexline>, cookie=0x0, flags=0) at /usr/src/debug/neovim-0.9.0-1.fc38.x86_64/src/nvim/ex_docmd.c:578 neovim#14 0x000055b8c7a17463 in nv_colon (cap=0x7fffdc351780) at /usr/src/debug/neovim-0.9.0-1.fc38.x86_64/src/nvim/normal.c:3228 neovim#15 0x000055b8c7a11b35 in normal_execute (state=0x7fffdc351700, key=<optimized out>) at /usr/src/debug/neovim-0.9.0-1.fc38.x86_64/src/nvim/normal.c:1196 neovim#16 0x000055b8c7ab0994 in state_enter (s=0x7fffdc351700) at /usr/src/debug/neovim-0.9.0-1.fc38.x86_64/src/nvim/state.c:99 neovim#17 0x000055b8c7a0ef68 in normal_enter (cmdwin=false, noexmode=false) at /usr/src/debug/neovim-0.9.0-1.fc38.x86_64/src/nvim/normal.c:497 neovim#18 0x000055b8c78a0640 in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/neovim-0.9.0-1.fc38.x86_64/src/nvim/main.c:641
justinmk
pushed a commit
that referenced
this pull request
Jun 22, 2023
Problem: Since neovim#23925, Version.build may be vim.NIL, which causes tostring() to fail: E5108: Error executing lua E5114: Error while converting print argument #1: …/version.lua:129: attempt to concatenate field 'build' (a userdata value) stack traceback: [C]: in function 'print' [string ":lua"]:1: in main chunk Solution: Handle vim.NIL in Version:__tostring().
justinmk
pushed a commit
that referenced
this pull request
Nov 14, 2023
Build with: -Wp,-D_FORTIFY_SOURCE=3 -O1 and gcc 13. *** buffer overflow detected ***: terminated (gdb) bt #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x00007f3eb8b93c03 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78 #2 0x00007f3eb8b42aee in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007f3eb8b2b87f in __GI_abort () at abort.c:79 #4 0x00007f3eb8b2c60f in __libc_message (fmt=fmt@entry=0x7f3eb8ca72e6 "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:150 #5 0x00007f3eb8c27b29 in __GI___fortify_fail (msg=msg@entry=0x7f3eb8ca728c "buffer overflow detected") at fortify_fail.c:24 #6 0x00007f3eb8c26364 in __GI___chk_fail () at chk_fail.c:28 neovim#7 0x00007f3eb8c25f45 in ___snprintf_chk (s=s@entry=0x55b8c7c096a5 <IObuff+5> "t' item", maxlen=maxlen@entry=1025, flag=flag@entry=2, slen=slen@entry=1020, format=format@entry=0x55b8c7b872a6 "%ldc") at snprintf_chk.c:29 neovim#8 0x000055b8c7aea59f in snprintf (__fmt=0x55b8c7b872a6 "%ldc", __n=1025, __s=0x55b8c7c096a5 <IObuff+5> "t' item") at /usr/include/bits/stdio2.h:54 neovim#9 uc_list (name=name@entry=0x55b8c8351788 "Explore", name_len=name_len@entry=7) at /usr/src/debug/neovim-0.9.0-1.fc38.x86_64/src/nvim/usercmd.c:534 neovim#10 0x000055b8c7aeb8a0 in ex_command (eap=0x7fffdc350e60) at /usr/src/debug/neovim-0.9.0-1.fc38.x86_64/src/nvim/usercmd.c:1009 neovim#11 0x000055b8c7972537 in execute_cmd0 (retv=retv@entry=0x7fffdc350e54, eap=eap@entry=0x7fffdc350e60, errormsg=errormsg@entry=0x7fffdc350e58, preview=preview@entry=false) at /usr/src/debug/neovim-0.9.0-1.fc38.x86_64/src/nvim/ex_docmd.c:1620 neovim#12 0x000055b8c7975c55 in do_one_cmd (cmdlinep=cmdlinep@entry=0x7fffdc3510b8, flags=flags@entry=0, cstack=cstack@entry=0x7fffdc351140, fgetline=fgetline@entry=0x55b8c79882b8 <getexline>, cookie=cookie@entry=0x0) at /usr/src/debug/neovim-0.9.0-1.fc38.x86_64/src/nvim/ex_docmd.c:2279 neovim#13 0x000055b8c79767fe in do_cmdline (cmdline=<optimized out>, fgetline=0x55b8c79882b8 <getexline>, cookie=0x0, flags=0) at /usr/src/debug/neovim-0.9.0-1.fc38.x86_64/src/nvim/ex_docmd.c:578 neovim#14 0x000055b8c7a17463 in nv_colon (cap=0x7fffdc351780) at /usr/src/debug/neovim-0.9.0-1.fc38.x86_64/src/nvim/normal.c:3228 neovim#15 0x000055b8c7a11b35 in normal_execute (state=0x7fffdc351700, key=<optimized out>) at /usr/src/debug/neovim-0.9.0-1.fc38.x86_64/src/nvim/normal.c:1196 neovim#16 0x000055b8c7ab0994 in state_enter (s=0x7fffdc351700) at /usr/src/debug/neovim-0.9.0-1.fc38.x86_64/src/nvim/state.c:99 neovim#17 0x000055b8c7a0ef68 in normal_enter (cmdwin=false, noexmode=false) at /usr/src/debug/neovim-0.9.0-1.fc38.x86_64/src/nvim/normal.c:497 neovim#18 0x000055b8c78a0640 in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/neovim-0.9.0-1.fc38.x86_64/src/nvim/main.c:641
justinmk
pushed a commit
that referenced
this pull request
Sep 14, 2024
setup: Remove duplicate busted install
justinmk
pushed a commit
that referenced
this pull request
Dec 19, 2024
…ders neovim#31608 Problem: regression since neovim#31340 `nvim -l repro.lua`: ```lua vim.lsp.start { cmd = { 'lua-language-server' }, name = 'lua_ls' } vim.lsp.start { cmd = { 'lua-language-server' }, name = 'lua_ls', root_dir = 'foo' } -- swapped case will be ok: -- vim.lsp.start { cmd = { 'lua-language-server' }, name = 'lua_ls', root_dir = 'foo' } -- vim.lsp.start { cmd = { 'lua-language-server' }, name = 'lua_ls' } ``` Failure: ``` E5113: Error while calling lua chunk: /…/lua/vim/lsp.lua:214: bad argument #1 to 'ipairs' (table expected, got nil) stack traceback: [C]: in function 'ipairs' /…/lua/vim/lsp.lua:214: in function 'reuse_client' /…/lua/vim/lsp.lua:629: in function 'start' repro.lua:34: in main chunk ```
justinmk
pushed a commit
that referenced
this pull request
Feb 9, 2025
…32370) this change includes the following changes: - a macro option must be #1–neovim#9 - add \providecommand - add starred versions of \newcommand, \newenvironment, and their variants - add number of arguments to \(re)newenvironment vim/vim@a35040f Co-authored-by: Eisuke Kawashima <e-kwsm@users.noreply.github.com>
justinmk
added a commit
that referenced
this pull request
Jul 12, 2025
Problem: Bad format() call on PUC Lua neovim#34901 Error: Failed to run healthcheck for "vim.health" plugin. Exception: runtime/lua/vim/health/health.lua:89: bad argument #1 to 'format' (string expected, got nil) Solution: Avoid passing nil.
justinmk
added a commit
that referenced
this pull request
Jul 12, 2025
Problem: Bad format() call on PUC Lua Error: Failed to run healthcheck for "vim.health" plugin. Exception: runtime/lua/vim/health/health.lua:89: bad argument #1 to 'format' (string expected, got nil) Solution: Avoid passing nil. (cherry picked from commit 2422fbd) Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
justinmk
added a commit
that referenced
this pull request
Jul 12, 2025
Problem: Bad format() call on PUC Lua neovim#34901 Error: Failed to run healthcheck for "vim.health" plugin. Exception: runtime/lua/vim/health/health.lua:89: bad argument #1 to 'format' (string expected, got nil) Solution: Avoid passing nil.
justinmk
added a commit
that referenced
this pull request
Jul 13, 2025
Problem: The "gitsigns" plugin runs `vim.diff` in a thread (`uv.new_work`), but `vim.diff` is nil in that context: Lua callback: …/gitsigns.nvim/lua/gitsigns/diff_int.lua:30: bad argument #1 to 'decode' (string expected, got nil) stack traceback: [C]: in function 'decode' …/gitsigns.nvim/lua/gitsigns/diff_int.lua:30: in function <…/gitsigns.nvim/lua/gitsigns/diff_int.lua:29> Luv thread: …/gitsigns.nvim/lua/gitsigns/diff_int.lua:63: attempt to call field 'diff' (a nil value) Solution: Revert the `stdlib.c` change (set `vim.diff` instead of `vim._diff`).
justinmk
added a commit
that referenced
this pull request
Jul 13, 2025
Problem: The "gitsigns" plugin runs `vim.diff` in a thread (`uv.new_work`), but `vim.diff` is nil in that context: Lua callback: …/gitsigns.nvim/lua/gitsigns/diff_int.lua:30: bad argument #1 to 'decode' (string expected, got nil) stack traceback: [C]: in function 'decode' …/gitsigns.nvim/lua/gitsigns/diff_int.lua:30: in function <…/gitsigns.nvim/lua/gitsigns/diff_int.lua:29> Luv thread: …/gitsigns.nvim/lua/gitsigns/diff_int.lua:63: attempt to call field 'diff' (a nil value) Solution: Revert the `stdlib.c` change (set `vim.diff` instead of `vim._diff`).
justinmk
added a commit
that referenced
this pull request
Jul 13, 2025
Problem: The "gitsigns" plugin runs `vim.diff` in a thread (`uv.new_work`), but `vim.diff` is nil in that context: Lua callback: …/gitsigns.nvim/lua/gitsigns/diff_int.lua:30: bad argument #1 to 'decode' (string expected, got nil) stack traceback: [C]: in function 'decode' …/gitsigns.nvim/lua/gitsigns/diff_int.lua:30: in function <…/gitsigns.nvim/lua/gitsigns/diff_int.lua:29> Luv thread: …/gitsigns.nvim/lua/gitsigns/diff_int.lua:63: attempt to call field 'diff' (a nil value) Solution: Revert the `stdlib.c` change (set `vim.diff` instead of `vim._diff`).
justinmk
added a commit
that referenced
this pull request
Jul 13, 2025
Problem: The "gitsigns" plugin runs `vim.diff` in a thread (`uv.new_work`), but `vim.diff` is nil in that context: Lua callback: …/gitsigns.nvim/lua/gitsigns/diff_int.lua:30: bad argument #1 to 'decode' (string expected, got nil) stack traceback: [C]: in function 'decode' …/gitsigns.nvim/lua/gitsigns/diff_int.lua:30: in function <…/gitsigns.nvim/lua/gitsigns/diff_int.lua:29> Luv thread: …/gitsigns.nvim/lua/gitsigns/diff_int.lua:63: attempt to call field 'diff' (a nil value) Solution: Revert the `stdlib.c` change (set `vim.diff` instead of `vim._diff`).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Full uname for reference:
Linux ZBook 4.4.0-43-Microsoft #1-Microsoft Wed Dec 31 14:42:53 PST 2014
x86_64 x86_64 x86_64 GNU/Linux