Closed GoogleCodeExporter closed 9 years ago
GoogleCodeExporter
commented
9 years ago Same here, use neocomplete with if_lua, vim simply crash if I don't use it for
a while.Original comment by plus...@gmail.com on 31 Oct 2014 at 7:36
GoogleCodeExporter
commented
9 years ago I can't reproduce it...
Is there any way to reproduce the issue?Original comment by chrisbr...@googlemail.com on 2 Nov 2014 at 2:10
GoogleCodeExporter
commented
9 years ago It's somewhat random (as it is related to GC). For me, when I have vim with
if_lua compiled in, and install neocomplete, if I open a vim window (this
happens for both vim in terminal and macvim), do some editing and then leave it
there, for some time without touching it, maybe several hours or even a day,
the next time I switch back to that window, it *might* then crash. After
removing the neocomplete plugin vim never crashed again.Original comment by plus...@gmail.com on 2 Nov 2014 at 6:27
GoogleCodeExporter
commented
9 years ago I concur that it's random and hard to reproduce. Neocomplete triggers the crash
for me as well, but I don't think that neocomplete is to blame here. Is there a
reliable way to stress test the lua gc by evaluating lua code?Original comment by Jochen.K...@gmail.com on 2 Nov 2014 at 7:19
GoogleCodeExporter
commented
9 years ago you can do :lua collectgarbage("collect"), but that does not crash vim for me.Original comment by plus...@gmail.com on 2 Nov 2014 at 9:19
GoogleCodeExporter
commented
9 years ago FWIW here's the issue at neocomplete's github page:
https://github.com/Shougo/neocomplete.vim/issues/310Original comment by Jochen.K...@gmail.com on 4 Nov 2014 at 10:28
GoogleCodeExporter
commented
9 years ago Following the steps from the issue, this should reproduce a crash:
:" Create some vim object.
:lua for i = 1,1000 do vim.eval('[]') end
:" Execute Lua's incremental garbage collection partly.
:" (Second argument might need to be tuned to reproduce SEGV)
:lua collectgarbage('step', 50)
:" ... Wait 'updatetime' to execute Vim's garbage collection.
:" Execute Lua's garbage collection until finish.
:lua collectgarbage('collect')
unfortunately, I still do not see that.Original comment by chrisbr...@googlemail.com on 4 Nov 2014 at 7:25
GoogleCodeExporter
commented
9 years ago I think Shuogo (the author of neocomplete) pasted that snippet as an example
for "finding ways to reproduce the bug without neocomplete". Reading from a
related issue (https://github.com/vim-jp/issues/issues/352 , unfortunately,
it's in Japanese), it seems that snippet was used to trigger a similar segfault
in if_lua, which should have already been fixed in 2013:
https://groups.google.com/forum/#!msg/vim_dev/4LcTD_3msak/fCzh004mCIYJ
What is not clear is whether that old issue is related to the current one. Original comment by plus...@gmail.com on 4 Nov 2014 at 7:55
GoogleCodeExporter
commented
9 years ago I think I jumped to quickly at Lua. From the BT I think the problem lies either
within vim's own garbage collector or in the set_ref_in_item() [1] function.
I found a discussion which sounds familiar at [2]. However, I tried out the
vimscript snippet and it does not cause a segfault. In the meantime, I'm still
getting regularly segfaults using the neocomplete plugin.
Any hints on how to build vim with debugging symbols?
[1] http://fossies.org/dox/vim-7.4/eval_8c_source.html#l06944
[2] https://groups.google.com/d/msg/vim_dev/Nr8Ja4Zjghw/3FfMjVobHmoJOriginal comment by Jochen.K...@gmail.com on 4 Nov 2014 at 9:57
GoogleCodeExporter
commented
9 years ago Try to reproduce the bug after building vim with ASan (= address sanitizer)
using the following patch to src/Makefile. Then run vim normally, ASan will
report useful stacks if a memory bug is detected at runtime (double free, used
of free memory, heap/stack/global overflow) Make sure that you run vim
unstripped which should be the case if you ran src/vim. It assumes that you
compile with a compiler that is not too ancient (>= gcc-4.8 or or >= clang-3.3
should be fine):
diff -r bfecd68c04dd src/Makefile
--- a/src/Makefile Fri Oct 31 19:51:36 2014 +0100
+++ b/src/Makefile Wed Nov 05 04:15:14 2014 +0100
@@ -616,6 +616,11 @@
#PROFILE_LIBS = -pg
#PROFILE_LIBS = -pg -lc
+# Build with address sanitizer.
+# See: # https://code.google.com/p/address-sanitizer/wiki/AddressSanitizer
+ASAN_CFLAGS = -fsanitize=address -fno-omit-frame-pointer -O1 -g
+ASAN_LIBS = $(ASAN_CFLAGS)
+
# MEMORY LEAK DETECTION
# Requires installing the ccmalloc library.
# Configuration is in the .ccmalloc or ~/.ccmalloc file.
@@ -1342,7 +1347,7 @@
PRE_DEFS = -Iproto $(DEFS) $(GUI_DEFS) $(GUI_IPATH) $(CPPFLAGS) $(EXTRA_IPATHS)
POST_DEFS = $(X_CFLAGS) $(MZSCHEME_CFLAGS) $(TCL_CFLAGS) $(EXTRA_DEFS)
-ALL_CFLAGS = $(PRE_DEFS) $(CFLAGS) $(PROFILE_CFLAGS) $(LEAK_CFLAGS)
$(POST_DEFS)
+ALL_CFLAGS = $(PRE_DEFS) $(CFLAGS) $(PROFILE_CFLAGS) $(ASAN_CFLAGS)
$(LEAK_CFLAGS) $(POST_DEFS)
# Exclude $CFLAGS for osdef.sh, for Mac 10.4 some flags don't work together
# with "-E".
@@ -1374,6 +1379,7 @@
$(TCL_LIBS) \
$(RUBY_LIBS) \
$(PROFILE_LIBS) \
+ $(ASAN_LIBS) \
$(LEAK_LIBS)
# abbreviations
Original comment by dominiqu...@gmail.com on 5 Nov 2014 at 3:23
GoogleCodeExporter
commented
9 years ago > I think I jumped to quickly at Lua. From the BT I think the problem lies
either > within vim's own garbage collector or in the set_ref_in_item() [1]
function.
>
> I found a discussion which sounds familiar at [2]. However, I tried out the
vimscript snippet and it does not cause a segfault. In the meantime, I'm still
getting regularly segfaults using the neocomplete plugin.
>
> Any hints on how to build vim with debugging symbols?
>
> [1] http://fossies.org/dox/vim-7.4/eval_8c_source.html#l06944
> [2] https://groups.google.com/d/msg/vim_dev/Nr8Ja4Zjghw/3FfMjVobHmoJ
If it is actually the same crash, I made a patch, but it is not complete yet
for LUA because I did not know how to get a return value from LUA code in the
case of a failed garbage collect.
To get the snippet in that thread to cause a crash, you may need to increase
the number of iterations used in the script.
Here is the discussion on the patch:
https://groups.google.com/d/topic/vim_dev/dnN58kO5Vg4/discussion
Here is the discussion of remaining work:
https://groups.google.com/forum/#!topic/vim_dev/RzHGXmVewvcOriginal comment by benjamin...@rockwellcollins.com on 5 Nov 2014 at 3:46
GoogleCodeExporter
commented
9 years ago This is nuts. I've recompiled vim with the address sanitizer and now it won't
crash anymore (despite being dog slow). If I simply switch back to my distro's
binary it'll crash again.
If I find the time I'll give Ben's patch a try.Original comment by Jochen.K...@gmail.com on 14 Nov 2014 at 11:54
GoogleCodeExporter
commented
9 years ago > This is nuts. I've recompiled vim with the address sanitizer and now it won't
crash anymore (despite being dog slow). If I simply switch back to my distro's
binary it'll crash again.
That's quite normal in situations like this one. That could actually suggest
that it is a concurrency(thread) issue. I would look at locking of variables,
etc ...Original comment by kybul...@gmail.com on 2 Jan 2015 at 1:48
GoogleCodeExporter
commented
9 years ago I sort of doubt it's the same crash, but see if the patch for the other garbage
collection "set_ref" crash makes any difference:
https://groups.google.com/d/msg/vim_dev/dnN58kO5Vg4/uIfaWyjMdM0JOriginal comment by fritzoph...@gmail.com on 22 Jan 2015 at 5:22
GoogleCodeExporter
commented
9 years ago I think this was fixed with 7.4.609. Please confirm.Original comment by chrisbr...@googlemail.com on 3 Feb 2015 at 5:40
GoogleCodeExporter
commented
9 years ago Apologies for not replying earlier. I'm currently running 4.7.617 and did not
see a crash yet. Before this I compiled vim with the patch from here [1] and it
also solved the problem for me.
Thanks for your help!
[1]
http://groups.google.com/forum/#!searchin/vim_dev/GC/vim_dev/DBYOdHQWvqY/1WH04_d
wETIJOriginal comment by Jochen.K...@gmail.com on 22 Feb 2015 at 3:31
Original issue reported on code.google.com by
Jochen.K...@gmail.comon 14 Oct 2014 at 9:38