9

This is related to debugging the issue mentioned in: Plugin (vim-latex) crashing gVim on startup

After installing latex-suite, every time I open a .tex file, whether it's from gVim or terminal vim, whether it contains a \begin statement or not, Vim immediately crashes.

After repeatedly making it crash I was able to read a Python Traceback string in the status line, which mentioned line 530 in C:\Python27\lib\site.py (which only contains known_paths = addusersitepackages(known_paths)), but the rest of the traceback is not viewable since the statusline display truncates it and this only appears for a moment anyway before automatically crashing.

Is there a way I could capture this Traceback output in a more permanent and complete way, along with how things go from this plugin to Python, etc.?

(I tried the -V15filename.log option but it's (as usual) useless, containing some partial log upto an ancient point in the vim startup process.)

Edit: Apologies for not mentioning the OS previously (other than indirectly through the C:\ path), this problem is on Windows. And from the other linked question it seems like almost everyone who tries latex-suite on Windows runs into this problem.

Update: Just a FTR - setting verbosefile doesn't help (presumably because the writes are buffered per the doc), and :redir doesn't capture this either, ends with whatever operation happened before this error and crash.

Community
  • 1
  • 1
Sundar R
  • 13,776
  • 6
  • 49
  • 76
  • 2
    if the problem is in python part, you can go into the plugin, and in python codes add some statement to debug. I don't use that plugin so much, but after checking the plugin doc, there is a variable `g:Tex_UsePython` to force the plugin not to use python. you can `let g:Tex_UsePython=0` in your vimrc, and check if the problem is gone. – Kent Jan 27 '14 at 20:41
  • @Kent Thanks a lot! That solves the crash issue, and I'm even able to enable menus without problem (had done `let g:Tex_Menus=0` according to a suggestion elsewhere). – Sundar R Jan 27 '14 at 21:12
  • To clarify, "that" was in reference to disabling Python with the global variable. Debugging the python code will probably have to wait for now. – Sundar R Jan 27 '14 at 21:14
  • yes, I glanced at the codes, the plugin used python to generate some formatted text (maybe more than that). I think the author used python to get better performance. You can use that "disable py" variable, with some complex document, see if you got performance problem. If it was fine for your usage, you can just live with it. – Kent Jan 27 '14 at 21:17
  • @Kent thank you, I had the similar problem, but only in winxp. don't know the Tex_UsePython option. Setting it to "0" solved my problem. I tested one of my largest tex file, didn't feel slow. perhaps my computer is just too powerful? :) I think you can post it as answer in case others have the same problem can see. – Imagination Jan 28 '14 at 12:59

4 Answers4

3

OK, I put here as an answer.

This answer could be kind of work around for solving your latex plugin problem in windows vim. However if your question sticks to "getting error message before crashing" , it may not give you help. I don't have much experience with windows OS.

Latex Suite plugin uses python to generate some formatted text. It could bring better performance. However the plugin provides no-python ways for that as well, to let user without installing python runtime or with very old python version use the plugin too.

Since you mentioned that your problem was in python codes. You can try disabling python in that plugin, and test if the performance was acceptable.

The plugin provided a variable for that, you could add this line in your vimrc

let g:Tex_UsePython=0

Nice to see it helped.

Kent
  • 189,393
  • 32
  • 233
  • 301
  • This solved my immediate problem, so marking this as the answer though the bounty goes elsewhere (I guess my original question is at fault for being really two questions, but now's too late to do anything about that.) – Sundar R Feb 03 '14 at 18:21
1

Did you try to run with redirected stderr?

vim file.tex &> errors.log

or

vim file.tex 2> errors.log
Daniel W.
  • 31,164
  • 13
  • 93
  • 151
  • Though this will produce a log file (along with `file.tex`'s contents and a complaint by vim that its output is not a terminal) you won't really be able to use vim as an editor, will you? – J. Katzwinkel Feb 15 '18 at 13:02
1

1) If you are able to compile Vim from the source (using MinGW as you are on Windows), you could run it with gdb. Then you could set some breakpoints/check the stack trace until you detect a line near the crash. The instructions to run Vim with the gdb and read the stack traces are found in :help debug-gcc.

At the end of that help file (:help get-ms-debuggers) you can find instructions on how to obtain some debug tools for Windows.

These tools can be used on the following alternatives, explained in detail on :help debug-win32:

2) In case you didn't compile Vim, obtain the debug symbols (PDB), which should be available from the same place that you obtained the executable. Attach Visual Studio to the Vim process, reproduce the crash, then read the stack trace through Visual Studio's dialog reporting the crash.

3) Same as 2) but using WinDbg instead of Visual Studio.

4) Inspect the Minidump file, in case your crash generate one. In addition to the referenced help section, you may find useful information on the following links:

mMontu
  • 8,983
  • 4
  • 38
  • 53
  • Okay, I haven't tested the options given here, but this comes closest to what the bounty was for and sounds like a sensible approach, so hither the bounty goes. Thanks @mMontu. – Sundar R Feb 03 '14 at 18:18
0

In case you are on a computer running linux, did you try saving the strace output in a file? 

strace gvim -V9log.txt file.tex > stdout.txt 2> stderr.txt

And then having a closer look at the output files, especially the last 10-100 lines? I am not sure if it will capture the system calls of the plugins though, but it could be a starting point.

Eric Fournie
  • 1,362
  • 8
  • 10