Vim-prettier: Vim crashes with segmentation fault with PrettierAsync

Created on 7 May 2018  ·  30Comments  ·  Source: prettier/vim-prettier

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-prettier are you using - (output of :PrettierVersion) ?
0.2.6
What version of prettier are you using - (output of :PrettierCliVersion) ?
1.12.1
What is your prettier executable path - (output of :PrettierCliPath) ?
not a prettier output, but just vim crashes with

Vim: Caught deadly signal SEGV

Vim: Finished.
[1]    33633 segmentation fault  vim

This only happens when using PrettierAsync command for formatting and on large files in my case it had 732 lines of code. It happened on node 9.6.1 and on 10.0.0.

If used Prettier command 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

bug
Source
picture radical-edo
👍2

Most helpful comment

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 in-io buffer is 'too large' (this varies by platform) then a segmentation fault occurs.

Currently, s:Prettier_Exec_Async starts a job by doing the following:

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 s:Apply_Prettier_Format.

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 :help setline(), it mentions the alternate method append. Swapping this call stopped vim from hanging.

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
endfor

Curiously, 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.

picture SamHowie on 25 May 2018
👍6 🎉2 ❤1

All 30 comments

Hi @radical-edo,

Do you mind providing me your vim-prettier configuration overwrites so that I can try to help you debug this issue ?

also:

  • what is your vim version ?
  • what OS are you using ?

For :PrettierCliPath to crash is most likely that prettier executable is not getting resolved properly. How did you install prettier ? is it globally installed ?

mitermayer picture mitermayer on 7 May 2018

Also could you please try the following:

  • going to the vim-prettier installation directory (if installed via vim-plug is $HOME/.vim/plugged/vim-prettier)
  • remove the node_modules directory
  • install again by either npm install or yarn install ?
mitermayer picture mitermayer on 7 May 2018

My vim-prettier config:

autocmd BufWritePre *.js,*.ts,*.tsx,*.scss PrettierAsync
let g:prettier#config#bracket_spacing = 'true'
let g:prettier#config#print_width = 100
let g:prettier#config#arrow_parens = 'always'

I've installed the vim-prettier with vundle. I have all my plugins under bundle directory.
The prettier itself was installed globally. Had no node_modules directory in bundle/vim-prettier. used yarn install still the error appears

:PrettierCliPath returns prettier.

vim version 8.0.1633. I'm running macOS 10.13.4

radical-edo picture radical-edo on 8 May 2018

I've overwritten the path to exec using

let g:prettier#exec_cmd_path = "~/.vim/bundle/vim-prettier/node_modules/.bin/prettier"

still same error appears. Don't think it's an path issue, though.

radical-edo picture radical-edo on 8 May 2018

You don’t want to use the asynchronous commands on save, anyway.

Otherwise the reformat finished after the save.

docwhat picture docwhat on 8 May 2018

Can you post the output of vim --version?

docwhat picture docwhat on 8 May 2018

vim --version output:

VIM - Vi IMproved 8.0 (2016 Sep 12, compiled May  7 2018 15:23:13)
macOS version
Included patches: 1-1633
Compiled by Homebrew
Huge version with MacVim GUI.  Features included (+) or not (-):
+acl               +farsi             +mouse_netterm     +tag_binary
+arabic            +file_in_path      +mouse_sgr         +tag_old_static
+autocmd           +find_in_path      -mouse_sysmouse    -tag_any_white
-autoservername    +float             +mouse_urxvt       -tcl
+balloon_eval      +folding           +mouse_xterm       +termguicolors
+balloon_eval_term -footer            +multi_byte        +terminal
+browse            +fork()            +multi_lang        +terminfo
++builtin_terms    +fullscreen        -mzscheme          +termresponse
+byte_offset       -gettext           +netbeans_intg     +textobjects
+channel           -hangul_input      +num64             +timers
+cindent           +iconv             +odbeditor         +title
+clientserver      +insert_expand     +packages          +toolbar
+clipboard         +job               +path_extra        +transparency
+cmdline_compl     +jumplist          +perl              +user_commands
+cmdline_hist      +keymap            +persistent_undo   +vertsplit
+cmdline_info      +lambda            +postscript        +virtualedit
+comments          +langmap           +printer           +visual
+conceal           +libcall           +profile           +visualextra
+cryptv            +linebreak         -python            +viminfo
+cscope            +lispindent        +python3           +vreplace
+cursorbind        +listcmds          +quickfix          +wildignore
+cursorshape       +localmap          +reltime           +wildmenu
+dialog_con_gui    -lua               +rightleft         +windows
+diff              +menu              +ruby              +writebackup
+digraphs          +mksession         +scrollbind        -X11
+dnd               +modify_fname      +signs             -xfontset
-ebcdic            +mouse             +smartindent       +xim
+emacs_tags        +mouseshape        +startuptime       -xpm
+eval              +mouse_dec         +statusline        -xsmp
+ex_extra          -mouse_gpm         -sun_workshop      -xterm_clipboard
+extra_search      -mouse_jsbterm     +syntax            -xterm_save
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  system gvimrc file: "$VIM/gvimrc"
    user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
    system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/Applications/MacVim.app/Contents/Resources/vim"
Compilation: clang -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall -Wno-unknown-pragmas -pipe  -DMACOS_X -DMACOS_X_DARWIN  -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: clang   -L.             -L /BuildRoot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.Internal.sdk/usr/local/libressl/lib -L/BuildRoot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.Internal.sdk/usr/local/lib -L.             -L /BuildRoot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.Internal.sdk/usr/local/libressl/lib -L/BuildRoot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.Internal.sdk/usr/local/lib  -L/usr/local/lib -o Vim -framework Cocoa -framework Carbon       -lm  -lncurses -liconv -framework AppKit   -fstack-protector  -L/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE -lperl  -L/usr/local/opt/python/Frameworks/Python.framework/Versions/3.6/lib/python3.6/config-3.6m-darwin -lpython3.6m -framework CoreFoundation  -framework Ruby

Actually, the using the Async option didn't make the changes after save. All the changes were made and then saved. I assumed the that Async would fire a separate process or thread or whatever, but the saving will "wait" for the prettier to finish. And from my experience, it looked like this.

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 :)

radical-edo picture radical-edo on 9 May 2018

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.

vim --version

VIM - Vi IMproved 8.0 (2016 Sep 12, compiled May  8 2018 10:27:57)
macOS version
Included patches: 1-1633
Compiled by Homebrew
Huge version with MacVim GUI.  Features included (+) or not (-):
+acl               +farsi             +mouse_netterm     +tag_binary
+arabic            +file_in_path      +mouse_sgr         +tag_old_static
+autocmd           +find_in_path      -mouse_sysmouse    -tag_any_white
-autoservername    +float             +mouse_urxvt       +tcl
+balloon_eval      +folding           +mouse_xterm       +termguicolors
+balloon_eval_term -footer            +multi_byte        +terminal
+browse            +fork()            +multi_lang        +terminfo
++builtin_terms    +fullscreen        -mzscheme          +termresponse
+byte_offset       -gettext           +netbeans_intg     +textobjects
+channel           -hangul_input      +num64             +timers
+cindent           +iconv             +odbeditor         +title
+clientserver      +insert_expand     +packages          +toolbar
+clipboard         +job               +path_extra        +transparency
+cmdline_compl     +jumplist          +perl              +user_commands
+cmdline_hist      +keymap            +persistent_undo   +vertsplit
+cmdline_info      +lambda            +postscript        +virtualedit
+comments          +langmap           +printer           +visual
+conceal           +libcall           +profile           +visualextra
+cryptv            +linebreak         -python            +viminfo
+cscope            +lispindent        +python3           +vreplace
+cursorbind        +listcmds          +quickfix          +wildignore
+cursorshape       +localmap          +reltime           +wildmenu
+dialog_con_gui    -lua               +rightleft         +windows
+diff              +menu              +ruby              +writebackup
+digraphs          +mksession         +scrollbind        -X11
+dnd               +modify_fname      +signs             -xfontset
-ebcdic            +mouse             +smartindent       +xim
+emacs_tags        +mouseshape        +startuptime       -xpm
+eval              +mouse_dec         +statusline        -xsmp
+ex_extra          -mouse_gpm         -sun_workshop      -xterm_clipboard
+extra_search      -mouse_jsbterm     +syntax            -xterm_save
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  system gvimrc file: "$VIM/gvimrc"
    user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
    system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/Applications/MacVim.app/Contents/Resources/vim"
Compilation: clang -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall -Wno-unknown-pragmas -pipe  -DMACOS_X -DMACOS_X_DARWIN  -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: clang   -L. -L/usr/local/lib -L. -L/usr/local/lib  -L/usr/local/lib -o Vim -framework Cocoa -framework Carbon       -lm  -lncurses -liconv -framework AppKit   -fstack-protector  -L/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE -lperl  -L/usr/local/opt/python/Frameworks/Python.framework/Versions/3.6/lib/python3.6/config-3.6m-darwin -lpython3.6m -framework CoreFoundation -F/System/Library/Frameworks -framework Tcl -framework CoreFoundation -framework Ruby

Running on macOS Sierra (v. 10.12.6 (16G1314))

Also in my case, using the Prettier command instead of PrettierAsync prevents the crash.

nerfologist picture nerfologist on 16 May 2018
👍1

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

mitermayer picture mitermayer on 16 May 2018

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 ~/.vimrc

let g:prettier#autoformat = 0

cc @nerfologist , @radical-edo , @luobata, @simianarmy,

mitermayer picture mitermayer on 16 May 2018

@mitermayer I already had that line in my config and it doesn't seem to prevent the crash

simianarmy picture simianarmy on 16 May 2018

@simianarmy , Thank you for the reply.

  • Do you recall when this start to happen ?
  • Does it always happen ?
mitermayer picture mitermayer on 16 May 2018

I'm not sure ... the JS file I'm using as a test case is ~ 1000 lines.
The crash occurs every time PrettierAsync is run, yes.

simianarmy picture simianarmy on 16 May 2018

vim --version 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

simianarmy picture simianarmy on 16 May 2018

@mitermayer thanks for your support. I tried setting

let g:prettier#autoformat = 0

...but it seems to make no difference, it still crashes on save.

Also,

  • I have been experiencing this problem for a long time (months)
  • problem occurs with the bundled prettier as well as with a prettier from node_modules
  • prettier from node_modules is perfectly able to format the file when run from the command line (node_modules/.bin/prettier crash.js)
nerfologist picture nerfologist on 17 May 2018
👍1

Does it crash if you remove the prettier plugin altogether?

At its core this is a Vim bug. Nothing we do should crash vim.

docwhat picture docwhat on 17 May 2018
👍1

There are a few ways we can debug this, lets try the simple one first

getting vim verbose log

can anyone that can replicate this issue give me the output of vimlog file when starting vim with command vim -V20vimlog and reproducing this issue ?

using catchsegv

starting vim with catchsegv vim and generating the segfault

analyzing core dump via gdb (https://vi.stackexchange.com/a/7286)

enabling the core dumps to be captured

$ ulimit -c unlimited

open vim and try to generate the segfault

$ vim someBrokenFile.*

Check that the core file is in there 

$ ls -ld *core* # see new core file that I'll call $core

see the program name 

$ file $core # see program name that I'll call $program

check the stack trace

$ gdb $program $core
(gdb) bt

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,

mitermayer picture mitermayer on 17 May 2018

Some investigations around vim compiled feature flags

From the vim --version output of everyone that has commented on both issues I tried to figure out if there was any relationship of vim compiled flags that they all shared in common and compared that to the flags that I have used for my vim (which is working as expected)

the results were the following:

Feature flags that I have installed and that none of them have are:

+gettext
+python/dyn
+python3/dyn
+xfontset
+xsmp_interact
+xterm_clipboard

Feature flags I don't have installed and all of them have are:

My next step will be trying to recompile my vim to test out with the above combination to see if I can get a repro.

Would be awesome if people that get it working could check on their vim --version and see if if the above finding is relevant at all

cc @docwhat

mitermayer picture mitermayer on 18 May 2018

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

For reference could not reproduce this on :+1: VIM - Vi IMproved 8.1 (2018 May 17, compiled May 17 2018 16:05:22) Included patches: 1 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

mitermayer picture mitermayer on 18 May 2018

@mitermayer I was able to run vim with the -V20vimlog flag and the resulting output is now visible here.

Following your instructions I was also successful in generating a core dump, which got dumped in the /cores directory. It's a huge file (1.3 GB) on which I ran file:

✎  $ file core.28050
core.28050: Mach-O 64-bit core x86_64

I tried to open the dump in gdb or lldb but in both cases I guess I was unsuccessful.

I still hope the -V20 log can be of some use.

Thanks for your support 👍

nerfologist picture nerfologist on 18 May 2018
👍1

@nerfologist, thank you so much, that log gives some great info on some areas to explore!

mitermayer picture mitermayer on 19 May 2018

@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.

docwhat picture docwhat on 19 May 2018

Hi, I'm using MacVim installed with --with-override-system-vim:

✎  $ brew info macvim
macvim: stable 8.0-146 (bottled), HEAD
GUI for vim, made for macOS
https://github.com/macvim-dev/macvim
/usr/local/Cellar/macvim/8.0-146_1 (2,161 files, 34.4MB) *
  Built from source on 2018-05-08 at 10:28:15 with: --with-override-system-vim
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/macvim.rb

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.

nerfologist picture nerfologist on 21 May 2018

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 vim-javascript and vim-prettier.

Looks like vim-javascript make some assumptions that the filetype for javascript would be controlled by it.

I have one idea on how to test this assumption, could you please edit this file ~/.vim/plugged/vim-prettier/ftdetect/javascript.vim

from 

autocmd BufNewFile,BufReadPost *.js setfiletype javascript

to 

" autocmd BufNewFile,BufReadPost *.js setfiletype javascript

And see if you can still reproduce this issue ?

cc @nerfologist, @radical-edo , @Luobata, @simianarmy

mitermayer picture mitermayer on 23 May 2018

Hello @mitermayer and thanks for your support 👍

I commented the line you mentioned and it's still crashing. Here you can find the new -V20 log of the attempt.

nerfologist picture nerfologist on 23 May 2018

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 in-io buffer is 'too large' (this varies by platform) then a segmentation fault occurs.

Currently, s:Prettier_Exec_Async starts a job by doing the following:

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 s:Apply_Prettier_Format.

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 :help setline(), it mentions the alternate method append. Swapping this call stopped vim from hanging.

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
endfor

Curiously, 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.

SamHowie picture SamHowie on 25 May 2018
👍6 🎉2 ❤1

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.

mitermayer picture mitermayer on 25 May 2018

This has been merged into master ! @nerfologist, @radical-edo , @Luobata, @simianarmy

mitermayer picture mitermayer on 25 May 2018
🎉4 ❤2

Massive thanks, @SamHowie! Great job!

docwhat picture docwhat on 2 Jun 2018
❤1

Great stuff guys! It works! Thanks! You are all heroes!

radical-edo picture radical-edo on 7 Jun 2018
❤1 🎉1
Was this page helpful?
0 / 5 - 0 ratings

Related issues

larister picture larister  ·  4Comments
yshuman1 picture yshuman1  ·  6Comments
axelav picture axelav  ·  4Comments
mitermayer picture mitermayer  ·  5Comments
christopherball picture christopherball  ·  4Comments