Dies bezieht sich auf das Debuggen des in Plugin (vim-latex ) Absturz von gVim beim Start
Nach der Installation von Latex-Suite, stürzt Vim sofort ab, wenn ich eine .tex-Datei öffne, egal ob von gVim oder terminal vim, ob sie eine \ begin -Anweisung enthält oder nicht.
Nachdem ich es wiederholt zum Absturz gebracht habe, konnte ich in der Statuszeile eine Python-Trace-Back-Zeichenfolge lesen, die Zeile 530 in C:\Python27\lib\site.py enthielt (die nur known_paths = addusersitepackages(known_paths) enthält), aber der Rest des Tracebacks konnte nicht angezeigt werden statusline display schneidet es ab und das erscheint nur für einen Moment bevor es automatisch abstürzt.
Gibt es eine Möglichkeit, wie ich diese Traceback-Ausgabe dauerhafter und vollständiger erfassen kann und wie die Dinge von diesem Plugin zu Python usw. gehen?
(Ich habe die -V15filename.log -Option versucht, aber sie ist (wie üblich) nutzlos und enthält ein Teilprotokoll bis zu einem alten Punkt im vim-Startprozess.)
Bearbeiten: Entschuldigung dafür, dass das Betriebssystem zuvor nicht erwähnt wurde (anders als indirekt über den Pfad C:\ ), dieses Problem tritt bei Windows auf. Und von der anderen verbundenen Frage scheint es, dass fast jeder, der Latex-Suite auf Windows versucht, auf dieses Problem eingeht.
Update: Nur eine FTR - Einstellung verbosefile hilft nicht (wahrscheinlich, weil die Schreibvorgänge per dem Dokument gepuffert sind), und: redir erfasst das auch nicht, endet mit der Operation, die vor diesem Fehler passiert ist und stürzt ab.
OK, ich habe hier eine Antwort gegeben.
Diese Antwort könnte eine Art Problem sein, um Ihr Latex-Plugin-Problem in Windows Vim zu lösen. Wenn Ihre Frage jedoch so bleibt, dass Sie vor dem Absturz eine Fehlermeldung erhalten, erhalten Sie möglicherweise keine Hilfe. Ich habe nicht viel Erfahrung mit Windows OS.
Das Latex Suite-Plugin verwendet Python, um formatierten Text zu generieren. Es könnte bessere Leistung bringen. Das Plugin bietet jedoch auch keine Python-Möglichkeiten, um Benutzer ohne Python-Laufzeit oder mit sehr alten Python-Versionen zu benutzen.
Da Sie erwähnt haben, dass Ihr Problem in Python-Codes lag. Sie können versuchen, Python in diesem Plugin zu deaktivieren und testen, ob die Leistung akzeptabel war.
Das Plugin hat dafür eine Variable zur Verfügung gestellt. Sie könnten diese Zeile in Ihrem vimrc hinzufügen
%Vor%Schön zu sehen, dass es geholfen hat.
Haben Sie versucht, mit umgeleitetem stderr zu laufen?
%Vor%oder
%Vor% 1) Wenn Sie in der Lage sind, Vim aus der Quelle zu kompilieren (mit MinGW wie unter Windows), könnten Sie es ausführen mit gdb . Dann könnten Sie einige Haltepunkte setzen / überprüfen Sie die Stapelspur, bis Sie eine Linie in der Nähe des Absturzes erkennen. Die Anweisungen zum Ausführen von Vim mit gdb und zum Lesen der Stack-Traces finden Sie in : help debug-gcc .
Am Ende dieser Hilfedatei (: help get-ms-debuggers) Sie finden Anweisungen, wie Sie einige Debug-Tools für Windows erhalten.
Diese Tools können für die folgenden Alternativen verwendet werden, die im Detail auf erläutert werden: help debug-win32 :
2) Wenn Sie Vim nicht kompiliert haben, besorgen Sie sich die Debug-Symbole (PDB), die an der Stelle verfügbar sein sollten, an der Sie die ausführbare Datei erhalten haben. Hängen Sie Visual Studio an den Vim-Prozess an, reproduzieren Sie den Absturz und lesen Sie dann den Stack-Trace durch den Visual Studio-Dialog, der den Absturz meldet.
3) Wie 2) aber mit WinDbg anstelle von Visual Studio.
4) Untersuchen Sie die Minidump-Datei , falls Ihr Absturz einen generiert. Zusätzlich zu der referenzierten Hilfe finden Sie nützliche Informationen zu den folgenden Links:
Haben Sie auf einem Computer mit Linux versucht, die strace-Ausgabe in einer Datei zu speichern?
%Vor%Und dann die Ausgabedateien genauer betrachten, besonders die letzten 10-100 Zeilen? Ich bin mir nicht sicher, ob es die Systemaufrufe der Plugins erfassen wird, aber es könnte ein Anfangspunkt sein.
Tags und Links vim latex-suite