A lot of "deadly singal SEGV" crashes of gvim during latex workflow

[petRUShka]

I experience a continuously crashes with something like this appearing in terminal

Vim: Caught deadly signal SEGV
Vim: Finished.
73;24M

or just like this

Vim: Caught deadly signal SEGV.

It is always happened after saving file with latex continuous mode turning on (several compilations happened also). Before crash there are a lot of refreshing of VIM and Zathura (my pdf viewer) and heavy CPU usage (according to responsiveness of system).

P.S. Arch linux, 4.0.4-2-ARCH #1 SMP PREEMPT Fri May 22 03:05:23 UTC 2015 x86_64 GNU/Linux

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled May 18 2015 07:58:41)
Included patches: 1-729
Compiled by Arch Linux
Huge version with GTK2 GUI.  Features included (+) or not (-):
+acl             +farsi           +mouse_netterm   +syntax
+arabic          +file_in_path    +mouse_sgr       +tag_binary
+autocmd         +find_in_path    -mouse_sysmouse  +tag_old_static
+balloon_eval    +float           +mouse_urxvt     -tag_any_white
+browse          +folding         +mouse_xterm     -tcl
++builtin_terms  -footer          +multi_byte      +terminfo
+byte_offset     +fork()          +multi_lang      +termresponse
+cindent         +gettext         -mzscheme        +textobjects
+clientserver    -hangul_input    +netbeans_intg   +title
+clipboard       +iconv           +path_extra      +toolbar
+cmdline_compl   +insert_expand   +perl            +user_commands
+cmdline_hist    +jumplist        +persistent_undo +vertsplit
+cmdline_info    +keymap          +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      -sniff           +xsmp_interact
+eval            +mouse_dec       +startuptime     +xterm_clipboard
+ex_extra        +mouse_gpm       +statusline      -xterm_save
+extra_search    -mouse_jsbterm   -sun_workshop    -xpm
   system vimrc file: "/etc/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  system gvimrc file: "/etc/gvimrc"
    user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
    system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK  -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz  -D_FORTIFY_SOURCE=2  -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc   -L. -Wl,-O1,--sort-common,--as-needed,-z,relro -fstack-protector -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/core_perl/CORE  -Wl,-O1,--sort-common,--as-needed,-z,relro -L/usr/local/lib -Wl,--as-needed -o vim   -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lfontconfig -lfreetype  -lSM -lICE -lXt -lX11 -lXdmcp -lSM -lICE  -lm -lncurses -lelf -lnsl   -lacl -lattr -lgpm -ldl  -L/usr/lib -llua -Wl,-E -Wl,-rpath,/usr/lib/perl5/core_perl/CORE -Wl,-O1,--sort-common,--as-needed,-z,relro -fstack-protector -L/usr/local/lib  -L/usr/lib/perl5/core_perl/CORE -lperl -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc -L/usr/lib/python2.7/config -lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic   -lruby -lpthread -lgmp -ldl -lcrypt -lm  -L/usr/lib

Xdotool

 xdotool version 3.20150503.1

Zathura

zathura 0.3.3
(plugin) djvu (0.2.4) (/usr/lib/zathura/djvu.so)
(plugin) pdf-poppler (0.2.5) (/usr/lib/zathura/pdf.so)
(plugin) ps (0.2.2) (/usr/lib/zathura/ps.so)

Latexmk

Latexmk, John Collins, 5 February 2015. Version 4.43a

[lahwaacz]

I assume that latexmk causes vim to segfault, possibly due to too frequent callbacks. Check how many instances of latexmk are running at a time, e.g.

pgrep -cf "perl /usr/bin/latexmk"

There should always be only one instance of latexmk per file, but sometimes when vim crashes the latexmk instances are left behind. Starting vim again without killing latexmk first will start another latexmk instance, which then all try to compile the same file and due to conflicts cause vim to crash again, thus creating a cascading effect which would explain the high CPU usage. Killing all latexmk processes manually should help.

[Rmano]

I had too some crashes --- never reported because I am not sure on how to reproduce them.

The common case is having two different main LaTeX files opened in two different tabs of the same gvim window and compiling/previewing both with latexmk; but it's not always leading to crashes.

[lervag]

It has happened to me as well, but I have never been able to reproduce it. And without being able to reproduce, I am also not able to debug it. I can't remember the last time it happened with me, and in my experience it is very rare.

I would be happy to investigate, but I am sorry that there is little I can do as long as I can't reproduce it... :(

[petRUShka]

There is 4 running copy of latexmk in my case!

$ pgrep -cf "perl /usr/bin/latexmk"
4

[petRUShka]

I'm thinking that it should be the reason. I'm not turning off my PC and don't logout. So may be it is some old Latexmk running and making things bad. I will check after killing all of them.

P.S. Before killing I always catch crash after several minutes of work. It was terrible!

[petRUShka]

By the way: is it possible to open VIM in debugger and see which plugin (or library) causing the crash?

[lervag]

On Linux, I guess I could use either fuser or lsof to find if there are processes that are not connected to vimtex, and instead of starting new processes I could "reconnect". However, I have NO idea how to do this on windows.

I will investigate if I can improve the reliability. There should be some way to detect running latexmk processes. (Note that it should work regardless of file names.)

[lahwaacz]

I've looked at the output of pstree and noticed that the latexmk process does not run under the vim process tree, unlike for example YCM:

systemd
  ├─bash -c cd '/home/lahwaacz/stuff/BAK' && max_print_line=2000 latexmk -pdf -e '$pdflatex =~ s/ / -file-line-error /' -outdir=./out/ -pvc -e '$success_cmd = "vim --servername VIMTEX --remote-expr \\"vimtex#latexmk#callback(1)\\""' -e '$failure_cmd = "vim --servername VIMTEX --remote-expr \\"vimtex#latexmk#callback(0)\\""' 'main.tex' >/tmp/vbIgaHk/17 2>&1 &
  │   └─perl /usr/bin/latexmk -pdf -e $pdflatex =~ s/ / -file-line-error / -outdir=./out/ -pvc -e $success_cmd = "vim --servername VIMTEX --remote-expr \\"vimtex#latexmk#callback(1)\\"" -e $failure_cmd = "vim --servername VIMTEX --remote-expr \\"vimtex#latexmk#callback(0)\\"" main.tex
  ├─tinyterm
  │   ├─bash
  │   │   └─vim -p --servername VIMTEX header.tex main.tex chapter1.tex chapter2.tex chapter3.tex chapter4.tex references.bib
  │   │       ├─python2 /usr/share/vim/vimfiles/python/ycm/../../third_party/ycmd/ycmd --port=35135 --options_file=/tmp/tmpxXYB2m --log=info --idle_suicide_seconds=10800 --stdout=/tmp/ycm_temp/server_35135_stdout.log --stderr=/tmp/ycm_temp/server_35135_stderr.log
  │   │       │   └─31*[{python2}]
  │   │       └─31*[{vim}]
  │   └─{gmain}
...

One might think that identifying the process by its command line arguments might be enough, but this will fail if the configuration changes. As has been said in this thread, the latexmk process may have quite long life...

[lervag]

@lahwaacz Yes, that is because latexmk is started in a separate shell. I am not entirely sure, but I think YCM is started with the built-in python support.

By use of pgrep -f and /proc/PID/cwd I've implemented a solution that I think works well on unix systems that has pgrep available. I am not sure if it works on OSX.

I have NO idea how to do this on Windows, so I've not implemented a solution for Windows as of yet.

[lervag]

Note that I am not sure if the issue is completely resolved. I think the last commit should fix the main problem, though.

[lahwaacz]

Actually, there must be some forking involved to detach the shell process from its parent, because the process hierarchy is preserved by default. I'm not sure yet whether this is done by vimtex, vim or the shell itself. At least on Linux it seems to be standard to kill children processes when a process dies, I think vim does it too. IMHO fixing the process tree is the proper way to go.

[lervag]

This is actually more a problem with vim than with vimtex. That is, vim does not allow asynchronous processes, which means that in order to run an attached external process like latexmk, it must be run in the foreground, i.e. blocking the editor. Thus the default behaviour of vimtex is to spawn the latexmk process as a background process.

That being said, I think the current behaviour of vimtex is pretty good. I just pushed an update to the code that handles how vimtex kills latexmk when a buffer is closed. I think this should increase the robustness. See #189.

Note that neovim is getting closer to maturity. This is a project/fork of vim that will bring, among other things, asynchronicity to the vim editor. However, I have currently not begun to use neovim myself, and I have not begun to update vimtex for neovim support either.

[lahwaacz]

I don't understand -- this "spawning" is done by adding an ampersand to the command, which is entirely a shell thing. But the shell itself is detached from vim with respect to the process tree.

[lervag]

Hmm. Perhaps I am mistaken. But I don't see how to update vimtex in order to fix things according to your suggestions.

Let's do a simple test:

1. Open vim and us ps to get the PID
2. Run watch pstree PID to see the pstree for the vim instance updated every 2 seconds
3. Inside vim, first do :call system('sleep 3') - now the pstree will show a sleep process attached to vim
4. Now do :!sleep 3; we should still see the sleep process attached
5. Finally, do :!sleep 3&; this time the sleep process is not attached to vim

I don't know how things should be, but this example at least supports my claim that for background processes, vim spawns and detaches a shell for the child process. Thus the child process no longer knows that vim is its parent. Or something like that.

If I am mistaken, and/or if there is some other way of doing this, please let me know.

[lahwaacz]

I see, it's not entirely shell thing. I will surely report back if I find anything constructive.

[lervag]

Great, thanks!