Skip to content

Conversation

mqudsi
Copy link

@mqudsi mqudsi commented Jul 15, 2017

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

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 justinmk merged commit 16b5d43 into justinmk:win-wsl-cwd-clipboard Jul 15, 2017
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 #1neovim#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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants