Vim crashes on omni completion (SIGTRAP, backtrace) #20

Open
blueyed opened this Issue Mar 14, 2014 · 9 comments

4 participants

@blueyed

While the docs warn about enabling the omni-completion, it should probably work with a simple test.lua file?

When completion is triggered, Vim crashes.

Manually executing the :luafile .../lua-ftplugin/misc/lua-ftplugin/omnicomplete.lua cmdline (seen in the backtrace) does not result in a crash, but this error:

...m/bundle/lua-ftplugin/misc/lua-ftplugin/omnicomplete.lua:82: attempt to get length of global 'arg' (a nil value)

Line 82 is:

for i = 1, #arg do

Here is the scrambled screen from the crash:

 Fontconfig error: "/etc/fonts/conf.d/65-khmer.conf", line 14: out of memory
~                                                                           Fontconfig error: "/etc/fonts/conf.d/65-khmer.conf", line 23: out of memory
~                                                       Fontconfig error: "/etc/fonts/conf.d/65-khmer.conf", line 32: out of memory
~
~                                   (vim:1220): Gtk-ERROR **: GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported
~
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff6b7d3d9 in g_logv () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
(gdb)


#0  0x00007ffff6b7d3d9 in g_logv () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#1  0x00007ffff6b7d522 in g_log () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007fffd28b6992 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#3  0x00007ffff6b8127f in g_option_context_parse ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x00007fffd28b73ae in gtk_parse_args () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#5  0x00007fffd28b7409 in gtk_init_check () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#6  0x00007ffff26ddadc in ffi_call_unix64 () from /usr/lib/x86_64-linux-gnu/libffi.so.6
#7  0x00007ffff26dd40c in ffi_call () from /usr/lib/x86_64-linux-gnu/libffi.so.6
#8  0x00007fffe81357a4 in ?? () from /usr/lib/x86_64-linux-gnu/lua/5.2/lgi/corelgilua51.so
#9  0x00007fffe8350ae5 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#10 0x00007fffe835bdd4 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#11 0x00007fffe8350db9 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#12 0x00007fffe834d018 in lua_callk () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#13 0x00007fffe83672d7 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#14 0x00007fffe8350ae5 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#15 0x00007fffe8350dad in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0    100% 2: 0
#16 0x00007fffe835040c in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#17 0x00007fffe8350ff1 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0 lua  50% 1: 2[#18 0x00007fffe834d0ed in lua_pcallk () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#19 0x00007fffe835fc67 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#20 0x00007fffe8350ae5 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#21 0x00007fffe835bdd4 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#22 0x00007fffe8350db9 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#23 0x00007fffe835aafa in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#24 0x00007fffe835ae38 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#25 0x00007fffe835c168 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#26 0x00007fffe8350db9 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#27 0x00007fffe834d018 in lua_callk () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#28 0x00007fffe83672d7 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#29 0x00007fffe8350ae5 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#30 0x00007fffe8350dad in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#31 0x00007fffe835040c in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#32 0x00007fffe8350ff1 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#33 0x00007fffe834d0ed in lua_pcallk () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#34 0x00007fffe835fc67 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#35 0x00007fffe8350ae5 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#36 0x00007fffe835bdd4 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#37 0x00007fffe8350db9 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#38 0x00007fffe835040c in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#39 0x00007fffe8350ff1 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#40 0x00007fffe834d0ed in lua_pcallk () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#41 0x0000000000618a1f in ex_luafile (eap=0x7fffffff83f0) at if_lua.c:1744
#42 0x0000000000496747 in do_one_cmd (cmdlinep=0x7fffffff8510, sourcing=1,
    cstack=0x7fffffff8600, fgetline=0x47ca70 <get_func_line>, cookie=0x238efc0)
    at ex_docmd.c:2695
#43 0x0000000000493caa in do_cmdline (
    cmdline=0x25c8630 "silent luafile /home/user/.dotfiles/vim/bundle/lua-ftplugin/misc/lua-ftplugin/omnicomplete.lua", fgetline=0x47ca70 <get_func_line>, cookie=0x238efc0, flags=3)
    at ex_docmd.c:1127
#44 0x0000000000477ab3 in ex_execute (eap=0x7fffffff8bf0) at eval.c:21162
#45 0x0000000000496747 in do_one_cmd (cmdlinep=0x7fffffff8d10, sourcing=1,
    cstack=0x7fffffff8e00, fgetline=0x47ca70 <get_func_line>, cookie=0x238efc0)
    at ex_docmd.c:2695
#46 0x0000000000493caa in do_cmdline (cmdline=0x0, fgetline=0x47ca70 <get_func_line>,
    cookie=0x238efc0, flags=7) at ex_docmd.c:1127
#47 0x000000000047bf4a in call_user_func (fp=0x23a9400, argcount=2, argvars=0x7fffffff9720,
    rettv=0x7fffffff9da0, firstline=1, lastline=1, selfdict=0x0) at eval.c:22932
#48 0x0000000000463995 in call_func (
    funcname=0x23a580f "xolox#lua#dofile(s:omnicomplete_script, a:modules)", len=16,
    rettv=0x7fffffff9da0, argcount=2, argvars=0x7fffffff9720, firstline=1, lastline=1,
    doesrange=0x7fffffff98b4, evaluate=1, selfdict=0x0) at eval.c:8524
#49 0x0000000000463548 in get_func_tv (
    name=0x23a580f "xolox#lua#dofile(s:omnicomplete_script, a:modules)", len=16,
    rettv=0x7fffffff9da0, arg=0x7fffffff9d48, firstline=1, lastline=1,
    doesrange=0x7fffffff98b4, evaluate=1, selfdict=0x0) at eval.c:8366
#50 0x000000000045ed23 in eval7 (arg=0x7fffffff9d48, rettv=0x7fffffff9da0, evaluate=1,
    want_string=0) at eval.c:5165
#51 0x000000000045e5ce in eval6 (arg=0x7fffffff9d48, rettv=0x7fffffff9da0, evaluate=1,
    want_string=0) at eval.c:4817
#52 0x000000000045e102 in eval5 (arg=0x7fffffff9d48, rettv=0x7fffffff9da0, evaluate=1)
    at eval.c:4633
#53 0x000000000045d416 in eval4 (arg=0x7fffffff9d48, rettv=0x7fffffff9da0, evaluate=1)
    at eval.c:4326
#54 0x000000000045d259 in eval3 (arg=0x7fffffff9d48, rettv=0x7fffffff9da0, evaluate=1)
    at eval.c:4238
#55 0x000000000045d0d8 in eval2 (arg=0x7fffffff9d48, rettv=0x7fffffff9da0, evaluate=1)
    at eval.c:4167
#56 0x000000000045cf17 in eval1 (arg=0x7fffffff9d48, rettv=0x7fffffff9da0, evaluate=1)
    at eval.c:4092
#57 0x000000000045ce76 in eval0 (
    arg=0x23a580f "xolox#lua#dofile(s:omnicomplete_script, a:modules)", rettv=0x7fffffff9da0,
    nextcmd=0x7fffffff9e78, evaluate=1) at eval.c:4049
#58 0x0000000000458c67 in ex_let (eap=0x7fffffff9e70) at eval.c:1897
#59 0x0000000000496747 in do_one_cmd (cmdlinep=0x7fffffff9f90, sourcing=1,
    cstack=0x7fffffffa080, fgetline=0x47ca70 <get_func_line>, cookie=0x24b0240)
    at ex_docmd.c:2695
#60 0x0000000000493caa in do_cmdline (cmdline=0x0, fgetline=0x47ca70 <get_func_line>,
    cookie=0x24b0240, flags=7) at ex_docmd.c:1127
#61 0x000000000047bf4a in call_user_func (fp=0x23a7eb0, argcount=1, argvars=0x7fffffffa9a0,
    rettv=0x7fffffffb020, firstline=1, lastline=1, selfdict=0x0) at eval.c:22932
#62 0x0000000000463995 in call_func (
    funcname=0x268830f "xolox#lua#getomnivariables(s:omnifunc_modules)", len=26,
    rettv=0x7fffffffb020, argcount=1, argvars=0x7fffffffa9a0, firstline=1, lastline=1,
    doesrange=0x7fffffffab34, evaluate=1, selfdict=0x0) at eval.c:8524
#63 0x0000000000463548 in get_func_tv (
    name=0x268830f "xolox#lua#getomnivariables(s:omnifunc_modules)", len=26,
    rettv=0x7fffffffb020, arg=0x7fffffffafc8, firstline=1, lastline=1,
    doesrange=0x7fffffffab34, evaluate=1, selfdict=0x0) at eval.c:8366
#64 0x000000000045ed23 in eval7 (arg=0x7fffffffafc8, rettv=0x7fffffffb020, evaluate=1,
    want_string=0) at eval.c:5165
#65 0x000000000045e5ce in eval6 (arg=0x7fffffffafc8, rettv=0x7fffffffb020, evaluate=1,
    want_string=0) at eval.c:4817
#66 0x000000000045e102 in eval5 (arg=0x7fffffffafc8, rettv=0x7fffffffb020, evaluate=1)
    at eval.c:4633
#67 0x000000000045d416 in eval4 (arg=0x7fffffffafc8, rettv=0x7fffffffb020, evaluate=1)
    at eval.c:4326
#68 0x000000000045d259 in eval3 (arg=0x7fffffffafc8, rettv=0x7fffffffb020, evaluate=1)
    at eval.c:4238
#69 0x000000000045d0d8 in eval2 (arg=0x7fffffffafc8, rettv=0x7fffffffb020, evaluate=1)
    at eval.c:4167
#70 0x000000000045cf17 in eval1 (arg=0x7fffffffafc8, rettv=0x7fffffffb020, evaluate=1)
    at eval.c:4092
#71 0x000000000045ce76 in eval0 (
    arg=0x268830f "xolox#lua#getomnivariables(s:omnifunc_modules)", rettv=0x7fffffffb020,
    nextcmd=0x7fffffffb0f8, evaluate=1) at eval.c:4049
#72 0x0000000000458c67 in ex_let (eap=0x7fffffffb0f0) at eval.c:1897
#73 0x0000000000496747 in do_one_cmd (cmdlinep=0x7fffffffb210, sourcing=1,
    cstack=0x7fffffffb300, fgetline=0x47ca70 <get_func_line>, cookie=0x23a4830)
    at ex_docmd.c:2695
#74 0x0000000000493caa in do_cmdline (cmdline=0x0, fgetline=0x47ca70 <get_func_line>,
    cookie=0x23a4830, flags=7) at ex_docmd.c:1127
#75 0x000000000047bf4a in call_user_func (fp=0x23acbb0, argcount=2, argvars=0x23a8d70,
    rettv=0x7fffffffbcc0, firstline=1, lastline=1, selfdict=0x0) at eval.c:22932
#76 0x0000000000463995 in call_func (funcname=0x226a3e0 "xolox#lua#omnifunc", len=18,
    rettv=0x7fffffffbcc0, argcount=2, argvars=0x23a8d70, firstline=1, lastline=1,
    doesrange=0x7fffffffbc1c, evaluate=1, selfdict=0x0) at eval.c:8524
#77 0x0000000000458669 in call_vim_function (func=0x226a3e0 "xolox#lua#omnifunc", argc=2,
    argv=0x7fffffffbca0, safe=0, str_arg_only=0, rettv=0x7fffffffbcc0) at eval.c:1622
#78 0x000000000044d37b in expand_by_function (type=13, base=0x23c3550 "f.") at edit.c:4019
#79 0x000000000044dfe5 in ins_compl_get_exp (ini=0x8df580 <compl_startpos>) at edit.c:4377
#80 0x000000000044eb80 in ins_compl_next (allow_get_expansion=1, count=1, insert_match=1)
    at edit.c:4732
#81 0x0000000000450236 in ins_complete (c=15) at edit.c:5416
#82 0x0000000000449120 in edit (cmdchar=105, startln=0, count=1) at edit.c:1417
#83 0x000000000052b60c in invoke_edit (cap=0x7fffffffc030, repl=0, cmd=105, startln=0)
    at normal.c:9254
#84 0x000000000052b5a5 in nv_edit (cap=0x7fffffffc030) at normal.c:9227
#85 0x000000000051d862 in normal_cmd (oap=0x7fffffffc0d0, toplevel=1) at normal.c:1198
#86 0x0000000000640cd5 in main_loop (cmdwin=0, noexmode=0) at main.c:1334
#87 0x00000000006405e1 in main (argc=1, argv=0x7fffffffc3d8) at main.c:1025

It seems to be related to issue #16.

Any pointers about how to debug this would be appreciated.

I have an uncommon LUA_PATH (for awesome window manager): …/awesome/lib/?.lua.in;/usr/share/lua/5.2/?.lua;, but unsetting it still crashes Vim on .

@mr
mr commented Jun 8, 2014

Is it possible that omnicomplete is grabbing stuff from awesome? From the docs:

"The omni completion support works by enumerating and loading all installed modules. If module loading has side effects this can have unintended consequences!"

Importing awesome stuff could have unintended side effects and crash everything.

@blueyed

Hmm, since I was/am merely interested in completion for the awesome libraries, this would make it less useful.

Would I have to test it with something along the lines of "LUA_PATH=/some/path/where/awesome/is/not/installed vim"?

A simple test case, which should work, would be useful.

Does it work for you?

@mr
mr commented Jun 8, 2014

I'm not sure. It's broken for me as well, and I also run awesome.

@blueyed

The new blacklist setting appears to help:

let g:lua_omni_blacklist = ['pl\.strict', 'lgi\..']

I am now seeing other problems, without a crash though:

Omnifunc returned bad value to YCM! Vim(lua):[string "vim chunk"]:8: bad argument #1 to 'insert' (table expected, got userdata)

It seems to badly interact with the redir used in quickfixsigns:

Omnifunc returned bad value to YCM! Vim(lua):[string "vim chunk"]:8: bad argument #1 to 'insert' (table expected, got userdata)
Omnifunc returned bad value to YCM! Vim(redir):E121: Undefined variable: output
Omnifunc returned bad value to YCM! Vim(redir):E121: Undefined variable: output
Error detected while processing function QuickfixsignsSet..<SNR>142_UpdateLineNumbers..QuickfixsignsListBufferSigns..<SNR>142_Redir:
line    5:
E121: Undefined variable: output
Error detected while processing function QuickfixsignsSet..<SNR>142_UpdateLineNumbers:
line   15:
E171: Missing :endif
Error detected while processing function QuickfixsignsSet:
line   62:
E171: Missing :endif
Omnifunc returned bad value to YCM! Vim(lua):[string "vim chunk"]:8: bad argument #1 to 'insert' (table expected, got userdata)
Error detected while processing function QuickfixsignsSet..<SNR>142_UpdateLineNumbers..QuickfixsignsListBufferSigns..<SNR>142_Redir:
line    5:
E121: Undefined variable: output
Error detected while processing function QuickfixsignsSet..<SNR>142_UpdateLineNumbers:
line   15:
E171: Missing :endif
Error detected while processing function QuickfixsignsSet:
line   62:
E171: Missing :endif
@xolox
Owner

Which exact version of Vim are you running? And which version of Lua does the Lua Interface for Vim load? For me arg is a regular table, for you it seems to be a userdata object (probably a proxy object created by the Lua Interface for Vim). This is the first I'm seeing of this, so probably I'm running an older version of Vim than you guys. Makes sense?

@xolox xolox added a commit that referenced this issue Jun 17, 2014
@xolox Make it possible to disable use of Lua Interface for Vim
Relevant for issue #20:
  #20
5d0ec87
@xolox
Owner

This issue has shown that it can be useful to disable the file type plug-in's use of the Lua Interface for Vim. I realize that doesn't actually solve the real problem yet, and I'll work towards doing so, however now you can:

let g:lua_internal = 0

To stop Vim from crashing while still being able to use omni completion where it works (if it works anywhere at all :-). If the Lua Interface for Vim has indeed been changed to employ userdata proxy objects then this option should allow you to properly use the plug-in until the issue is fixed.

@blueyed

Which exact version of Vim are you running?

I am following the hg tip / git master (mirror: https://github.com/b4winckler/vim.git), currently 7.4.316.

After adding let g:lua_internal = 0 to my current settings it works much better!

Although the manual chaining I have in place might cause these issues:

  • with YCM automatically triggering omnifunc on keypresses, it completes the base elements after a dot: _VERSION, and, arg
  • If I manually do <C-x><C-o> after e.g. utils. it completes with this context, but has the utils. prefix then.
  • requiring some module does not provide completion for it, e.g. via awful = require("awful")

Regarding my settings, I currently I have:

let g:lua_check_syntax = 0  " done via syntastic
let g:lua_complete_keywords = 0 " interferes with YouCompleteMe
let g:lua_complete_globals = 0  " interferes with YouCompleteMe?
let g:lua_complete_library = 0  " interferes with YouCompleteMe
let g:lua_complete_dynamic = 0  " interferes with YouCompleteMe
let g:lua_complete_omni = 1     " Disabled by default. Likely to crash Vim!
let g:lua_omni_blacklist = ['pl\.strict', 'lgi\..']
let g:lua_define_omnifunc = 1  " must be enabled also (g:lua_complete_omni=1, but crashes Vim!)
let g:lua_define_completion_mappings = 0
let g:lua_internal = 0

But also commenting all the lua_complete_* settings it appeared to behave similar.

I've noticed that there is g:lua_define_completefunc, which gets disabled implicitly by YCM / my custom chaining.
Maybe that is something that's expected to be there if not disabled?

I have tried to use it when setting up awesome, and have now tried only a bit to use it. Let me know if I should try it with less customization.

@xolox
Owner

After compiling the latest and greatest Vim from source I finally ran into the following issue myself:

bad argument #1 to 'insert' (table expected, got userdata)

This was just fixed in 4746f4d so you should be able to switch back to using the Lua Interface for Vim instead of an external Lua interpreter. The caveat about it being possible to crash Vim still exists though (fundamentally it can't be solved).

@meijieru

hello,I have the same issue with you,have you solve the problem?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment