Vim crashes with segmentation fault with PrettierAsync #135
Comments
|
Hi @radical-edo, Do you mind providing me your also:
For |
|
Also could you please try the following:
|
|
My I've installed the
vim version |
|
I've overwritten the path to exec using still same error appears. Don't think it's an path issue, though. |
|
You don’t want to use the asynchronous commands on save, anyway. Otherwise the reformat finished after the save. |
|
Can you post the output of |
|
Actually, the using the Although it might be this way since usually, I'd save a file more than once, so the second save will keep the reformat update :) |
|
Hi, I've been having the same problem for some time; tried to restrict the issue to a minimal vimrc with just vundle, vim-prettier and a simple file which crashes on my machine. You can find it in this example repo.
Running on macOS Sierra (v. 10.12.6 (16G1314)) Also in my case, using the |
|
Looking into this today and will comment on this issue with my findings, and hopefully if able to reproduce create a fix and do a release ASAP |
|
Hi guys, Trying to debug this issue without being able to reproduce it yet. Will try to see if I can get a Mac with same version to see if that could be related. In the meantime can you guys try reproducing this after adding this to your let g:prettier#autoformat = 0cc @nerfologist , @radical-edo , @Luobata, @simianarmy, |
|
@mitermayer I already had that line in my config and it doesn't seem to prevent the crash |
|
@simianarmy , Thank you for the reply.
|
|
I'm not sure ... the JS file I'm using as a test case is ~ 1000 lines. |
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Mar 30 2018 07:37:16)
macOS version
Included patches: 1-1650
Compiled by Homebrew
Huge version without GUI. Features included (+) or not (-):
+acl +farsi +mouse_sgr -tag_any_white
+arabic +file_in_path -mouse_sysmouse -tcl
+autocmd +find_in_path +mouse_urxvt +termguicolors
-autoservername +float +mouse_xterm +terminal
-balloon_eval +folding +multi_byte +terminfo
+balloon_eval_term -footer +multi_lang +termresponse
-browse +fork() -mzscheme +textobjects
++builtin_terms -gettext +netbeans_intg +timers
+byte_offset -hangul_input +num64 +title
+channel +iconv +packages -toolbar
+cindent +insert_expand +path_extra +user_commands
-clientserver +job +perl +vertsplit
+clipboard +jumplist +persistent_undo +virtualedit
+cmdline_compl +keymap +postscript +visual
+cmdline_hist +lambda +printer +visualextra
+cmdline_info +langmap +profile +viminfo
+comments +libcall -python +vreplace
+conceal +linebreak +python3 +wildignore
+cryptv +lispindent +quickfix +wildmenu
+cscope +listcmds +reltime +windows
+cursorbind +localmap +rightleft +writebackup
+cursorshape -lua +ruby -X11
+dialog_con +menu +scrollbind -xfontset
+diff +mksession +signs -xim
+digraphs +modify_fname +smartindent -xpm
-dnd +mouse +startuptime -xsmp
-ebcdic -mouseshape +statusline -xterm_clipboard
+emacs_tags +mouse_dec -sun_workshop -xterm_save
+eval -mouse_gpm +syntax
+ex_extra -mouse_jsbterm +tag_binary
+extra_search +mouse_netterm +tag_old_static
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "~/.vim/vimrc"
user exrc file: "$HOME/.exrc"
defaults file: "$VIMRUNTIME/defaults.vim"
fall-back for $VIM: "/usr/local/share/vim"
Compilation: clang -c -I. -Iproto -DHAVE_CONFIG_H -DMACOS_X -DMACOS_X_DARWIN -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: clang -L. -fstack-protector -L/usr/local/lib -L/usr/local/opt/libyaml/lib -L/usr/local/opt/openssl/lib -L/usr/local/opt/readline/lib -L/usr/local/lib -o vim -lncurses -liconv -framework AppKit -mmacosx-version-min=10.13 -fstack-protector-strong -L/usr/local/lib -L/usr/local/Cellar/perl/5.26.1/lib/perl5/5.26.1/darwin-thread-multi-2level/CORE -lperl -lm -lutil -lc -L/usr/local/opt/python/Frameworks/Python.framework/Versions/3.6/lib/python3.6/config-3.6m-darwin -lpython3.6m -framework CoreFoundation -lruby.2.5.1 -lobjc``` |
|
@mitermayer thanks for your support. I tried setting ...but it seems to make no difference, it still crashes on save. Also,
|
|
Does it crash if you remove the prettier plugin altogether? At its core this is a Vim bug. Nothing we do should crash vim. |
|
There are a few ways we can debug this, lets try the simple one first getting vim verbose logcan anyone that can replicate this issue give me the output of using catchsegvstarting vim with analyzing core dump via gdb (https://vi.stackexchange.com/a/7286)enabling the core dumps to be captured open vim and try to generate the segfault Check that the core file is in there see the program name check the stack trace Would be amazing if some of the folks that can reproduce this issue could gather some form of logs from any combination of the above logs in order for us to help track down this problem once and for all cc @nerfologist , @radical-edo , @Luobata, @simianarmy, |
Some investigations around vim compiled feature flagsFrom the the results were the following: Feature flags that I have installed and that none of them have are: Feature flags I don't have installed and all of them have are: My next step will be trying to recompile my Would be awesome if people that get it working could check on their cc @docwhat |
|
I tried testing with latest vim 8.1 which has just been released, did it by manually cloning the github repo and compiling it and installing by hand and still was not able to reproduce this segfault issue. I wonder if that could be OS related since im on linux |
|
@mitermayer I was able to run vim with the Following your instructions I was also successful in generating a core dump, which got dumped in the I tried to open the dump in I still hope the Thanks for your support 👍 |
|
@nerfologist, thank you so much, that log gives some great info on some areas to explore! |
|
@nerfologist is this MacVim.app or just normal vim? Your log is trying to load stuff from the MacVim.app bundle and dying there. Are you mixing support files? If this is MacVim and you updated the OS recently you may have to uninstall it and reinstall. |
|
Hi, I'm using MacVim installed with I'll try reinstalling it, but I have upgraded/reinstalled MacVim a few times over the last few months and the crash is still happening. |
|
I will try to get hold of a mac computer to see if I can reproduce this issue. It looks like it could be a problem with plugin incompatibilities from Looks like I have one idea on how to test this assumption, could you please edit this file from autocmd BufNewFile,BufReadPost *.js setfiletype javascriptto " autocmd BufNewFile,BufReadPost *.js setfiletype javascriptAnd see if you can still reproduce this issue ? |
|
Hello @mitermayer and thanks for your support 👍 I commented the line you mentioned and it's still crashing. Here you can find the new |
|
I was able to reproduce this on macOS and Ubuntu. It appears to be a bug in the following Vim job option setting: 'in-io': 'buffer'If the contents of the Currently, call job_start([&shell, &shellcmdflag, l:async_cmd], {
\ 'in_io': 'buffer',
\ 'in_top': a:startSelection,
\ 'in_bot': a:endSelection,
\ 'in_name': l:bufferName,
\ 'err_cb': {channel, msg -> s:Prettier_Job_Error(msg)},
\ 'close_cb': {channel -> s:Prettier_Job_Close(channel, a:startSelection, a:endSelection, l:bufferName)}})This tweak circumvents the segmentation fault by feeding the buffer lines directly into the jobs stdin: let l:job = job_start([&shell, &shellcmdflag, l:async_cmd], {
\ 'err_cb': {channel, msg -> s:Prettier_Job_Error(msg)},
\ 'close_cb': {channel -> s:Prettier_Job_Close(channel, a:startSelection, a:endSelection, l:bufferName)}})
let l:stdin = job_getchannel(l:job)
call ch_sendraw(l:stdin, join(getbufline(bufnr(l:bufferName), a:startSelection,a:endSelection), "\n"))
call ch_close_in(l:stdin)Fixing the segmentation fault reveals large file performance issues with The following line caused Vim to hang on a large document: " replace all lines from the current buffer with output from prettier
call setline(1, l:newBuffer)Reading call append(0, l:newBuffer)But it still took several seconds to execute, and undo would sometimes hang. So, out of interest, I tried the following: let l:idx = 0
for l:line in l:newBuffer
call append(l:idx, l:line)
let l:idx += 1
endforCuriously, this is much faster. But it is still quite slow with large documents (2K+ lines). This solution should be 'good enough' as a patch fix. However, it would be worthwhile exploring what we can further optimize to increase performance. The main concern with performance is that slower round trip times from command to updated buffer increase the delta in which buffer edits can occur. It is possible that these edits will be overwritten by the response from Prettier resulting in lost work. |
|
Thank you @SamHowie for this detailed explanation! I think we should get this patched into master to unblock users (assuming it does not break neovim and vim7.4) On the long term we could try on The 1.x branch try solving with different approach, one thing worth exploring would be maybe by writing into temporary file and replace buffer with it. |
|
This has been merged into master ! @nerfologist, @radical-edo , @Luobata, @simianarmy |
|
Massive thanks, @SamHowie! Great job! |
|
Great stuff guys! It works! Thanks! You are all heroes! |
Do you want to request a feature or report a bug?
bug
What is the current/expected behavior?
the vim doesn't receive segmentation fault
What version of
vim-prettierare you using - (output of:PrettierVersion) ?0.2.6
What version of
prettierare you using - (output of:PrettierCliVersion) ?1.12.1
What is your
prettierexecutable path - (output of:PrettierCliPath) ?not a prettier output, but just vim crashes with
This only happens when using
PrettierAsynccommand for formatting and on large files in my case it had732lines of code. It happened on node9.6.1and on10.0.0.If used
Prettiercommand to format, all is well.I'm running those commands "on save".
Did this work in previous versions of vim-prettier and/or prettier ?
don't know
The text was updated successfully, but these errors were encountered: