Vscode: Absturz beim Laufen über Nacht

Dies scheint konsequent jede Nacht zu passieren, wenn ich den Computer laufen lasse. Es sieht so aus, als würde es nicht reagieren, da die CPU voll ist. Vielleicht gibt es irgendwo eine Endlosschleife, vielleicht mit Datei- oder Git-Repo-Abfragen?

Ich frage mich, ob das Betriebssystem beschließt, VSCode (Electron tatsächlich) in einen Zustand zu versetzen, in dem es diesen Absturz verursacht. Ich habe Electron angerufen, wenn sie eine Ahnung haben.

Nie auf Atom fyi passiert, zumindest auf 1.19.x (aus dem Speicher) und 1.2.4.

Ich habe seit dem November-Update ein ähnliches Problem (0.10.2 / 0.10.3?). Fast jeden Tag, an dem ich mich anmeldete, um festzustellen, dass meine über Nacht verbliebenen VSCode-Fenster alle abgestürzt sind (mit dem standardmäßigen nicht informativen / entschuldigenden Absturzfehler "Visual Studio Code ist abgestürzt").

Heute, nach dem 0.10.5-Update, hatte ich meinen ersten Absturz, als ich dort war - leider nicht, während ich es aktiv benutzte.

Ausführen von VSCode unter Windows 7 (64-Bit), hauptsächlich als JS-Editor für ein sehr großes Projekt - insgesamt fast eine Million Zeilen (einschließlich der zu durchsuchenden Bibliotheken, daher nicht ausgeschlossen). Keine Leistungsprobleme bei normaler Verwendung und ich habe keine übermäßige Ressourcennutzung festgestellt, die zum heutigen Absturz geführt hat.

Gerne stelle ich Ihnen detailliertere Fehlerprotokolle / Informationen zur Verfügung, wenn mich jemand darauf hinweisen kann.

Ich bekomme das gleiche grundlegende Problem wie @ Elusive138 , wenn ich den Code über Nacht (jede Nacht) laufen bekomme ich morgens ohne Fehler "Visual Studio Code ist abgestürzt".

Immer noch Repros für mich auf vscode 0.10.5, Ubuntu 12.04

Ich habe versucht, ohne Glück unter Windows 10, Mac OS 10.11 und Ubuntu 15 zu reproduzieren. Ich vermute ein Problem mit zu wenig Speicher, aber bei keinem der oben genannten Probleme hat der Speicher stark zugenommen.

Kann jemand versuchen, dies unter folgenden Bedingungen zu reproduzieren:

• Wird es reproduziert, wenn nur eine leere Codeinstanz geöffnet wird (Datei | Ordner schließen)?
• Wird beim Öffnen eines Arbeitsbereichs reproduziert, ohne dass eine Datei im Editor geöffnet wird?

Ubuntu 12.04, vscode 0.10.5 konnte nicht reproduziert werden und ließ es über das Wochenende mit einer leeren Instanz zurück.

Es kann durchaus ein subtiler Speicherverlust sein, der durch die relativ hohe Speicherauslastung auf diesem System deutlich wird.

Ich verließ den Computer gegen 17:30 Uhr, und das Festschreiben des Systemspeichers stieg langsam an - um 19:00 Uhr waren es 15.402 MB. Um 3:09 Uhr war die Annäherung an das System-Commit-Limit (17.682 MB) am nächsten, und die Commit-Nutzung ging von 16.218 MB auf 15.217 MB zurück. Ich vermute, dass hier VSCode abgestürzt ist. Die Commit-Nutzung war dort stabil, bis die Protokollierung gegen 6 Uhr morgens gestoppt wurde (nicht genügend Speicherplatz - diese Leistungsindikatoren sind groß!).

Leider habe ich nicht alle VSCode-Prozesse eingeschlossen, sodass ich keine prozessspezifische Protokollierung habe. Ich werde das heute Abend versuchen.

Wäre sehr nützlich, wenn ich die Zeit des Absturzes bekommen könnte. Hinterlässt VSCode irgendwo Protokolle?

Leider habe ich nicht alle VSCode-Prozesse eingeschlossen, sodass ich keine prozessspezifische Protokollierung habe. Ich werde das heute Abend versuchen.

Das wäre super nützlich, danke!

Derzeit protokolliert vscode nicht auf der Festplatte.

@ Elusive138 Können Sie den Arbeitsbereich freigeben, auf dem vscode ausgeführt wird?

@bpasero Leider nicht. Es basiert jedoch auf Ext JS, und dort befindet sich der Großteil des (Bibliotheks-) Codes. Ich werde versuchen, einen sauberen Ext JS-Arbeitsbereich zu erstellen, nachdem diese anderen Tests abgeschlossen sind, und prüfen, ob er dort erneut angezeigt wird.

@ Elusive138 Ja, wäre gut, wenn wir ein Muster hätten, das wir reproduzieren

Einer der code.exe-Prozesse (Code Nr. 3 im Protokoll, beigefügt) scheint undicht zu sein. Das Commit begann um 17:30 Uhr bei etwa 200 MB und erreichte am nächsten Tag um 9:00 Uhr 460 MB mit einem konstanten Anstieg:

Die Anzahl der Griffe steigt nicht an.

vscode_memleak.zip

Diesmal gab es keinen Absturz, vielleicht weil nicht so viele andere speicherintensive Programme ausgeführt wurden. Möglicherweise können Sie dies später in einer VM mit einem niedrigen Festschreibungslimit testen.

Dieses Protokoll wurde über Nacht mit 3 großen Arbeitsbereichen erstellt, die in verschiedenen Fenstern geöffnet sind. Ich werde versuchen, es auf einen Arbeitsbereich zu beschränken, den ich freigeben kann.

@ Elusive138 Es wäre hilfreich, die Details des Prozesses zu verstehen, der leckt. Können Sie die PID finden und dann die vollständigen Metadaten mit ps aux | grep <pid> drucken?

Ah, vielleicht ist das unter Windows, nicht sicher :)?

@bpasero Die Befehlszeile lautet:

"C:\Program Files (x86)\Microsoft VS Code\code.exe" --type=renderer --no-sandbox --lang=en-US --app-user-model-id=Microsoft.VisualStudioCode --node-integration=true --device-scale-factor=1 --enable-delegated-renderer --num-raster-threads=4 --gpu-rasterization-msaa-sample-count=8 --content-image-texture-target=3553 --video-image-texture-target=3553 --disable-accelerated-video-decode --channel="4896.1.1021371100\1043577992" /prefetch:673131151

Andere Details:

Der Prozessbaum:

Dies ist nach einem weiteren vollen Gebrauchstag. Wie Sie sehen können, scheint die Speichernutzung des Prozesses in dieser Zeit linear angestiegen zu sein (gleicher Arbeitsbereich).

Ah ... das ist nicht mal der wirklich schlechte.

4772 war der Prozess, der über Nacht durchgesickert ist. Der andere scheint aufgrund meiner Verwendung während des Tages gestiegen zu sein ... denke ich.

@ Elusive138 das sieht so aus, als hätten Sie mehrere Fenster mit Code geöffnet, stimmt das?

@bpasero Ja, der Test letzte Nacht hatte drei geöffnete Fenster mit unterschiedlichen Arbeitsbereichen. Ich werde es heute Abend mit nur einem versuchen, auf einem sauberen Ext JS-Arbeitsbereich, wie oben erwähnt.

Klingt gut!

Leider kein Repro ... das ist seltsam. Was könnte ein Leck innerhalb dieses spezifischen Projekts verursachen?

Apropos, dies könnte sich von der ersten Ausgabe von @Tyriar unterscheiden. Sein reagierte nicht, meins und gwynjudd stürzen mit dem Fehlerdialog ab ..? In diesem Fall sollten wir vielleicht eine neue Ausgabe machen ...

@ Elusive138 ungerade. Wird es reproduziert, wenn Sie diesen Arbeitsbereich nur öffnen, ohne eine JS-Datei zu öffnen?

Vielleicht können wir dies auch mit den Chrome-Entwicklertools profilieren, mit denen Sie Heap-Schnappschüsse machen können. Machen Sie dazu einfach vor und nach einiger Zeit einen Schnappschuss, um zu sehen, wohin diese Speicher gehen.

@bpasero Oh, ich habe diese Devtools komplett vergessen. Ich werde es heute Abend versuchen.

@bpasero Heap-Schnappschüsse von Main.js , workerMain.js und workerMain.js (2) ändern sich nicht wirklich. Um vielleicht höchstens 5 MB.

Ich fügte meiner Situation mehr hinzu und versuchte, sie mit einem geöffneten Ordner (dem abgestürzten) auszuführen, aber ohne Arbeitsdateien, und es passierte nicht über Nacht. Es passiert also nur, wenn ein Ordner geöffnet ist und Arbeitsdateien aktiv sind.

@ Elusive138 Wir angezeigt werden . Aus einem Ihrer vorherigen Beiträge geht jedoch hervor, dass Sie den hohen Speicher des Renderer-Prozesses identifiziert haben und dass dieser unter dem Heap-Schnappschuss angezeigt werden sollte. Sind Sie sicher, dass Sie den hohen Speicher für den Renderer-Prozess und nicht für seine untergeordneten Elemente gesehen haben? weil der Renderer das übergeordnete Element anderer Prozesse ist, die er erzeugt, z. B. ein Prozess zum Überwachen von Dateien.

@ Tyriar können Sie genauer sagen, was Sie damit meinen. Ist es so, dass Sie keine Datei im Editor geöffnet haben oder dass der Abschnitt mit den Arbeitsdateien buchstäblich leer war?

Der Grund, warum ich nach dem Öffnen einer Datei frage oder nicht, ist, dass beispielsweise der JS-Sprachdienst erst gestartet wird, wenn Sie eine JS-Datei öffnen. Gleiches gilt für alle anderen Sprachdienste. Wenn dieses Problem reproduziert wird, ohne eine Datei im Editor zu öffnen, liegt der Speicherverlust wahrscheinlich nicht in einem Sprachdienst, sondern an einem anderen Ort.

Ein weiterer Versuch lohnt sich: Führen Sie den Vorgang ohne Erweiterung aus, um festzustellen, ob möglicherweise eine Erweiterung undicht ist. Sie können dazu mit --disable-extensions laufen.

@bpasero Ich bin sicher, die oben angegebene Befehlszeile war für 4772, die hervorgehobene (undichte) im Screenshot. Es heißt --type=renderer .

Ich werde es über das Wochenende wieder laufen lassen und sehen, was passiert. Ich glaube nicht, dass ich einen sauberen Test ohne geöffnete JS-Dateien durchgeführt habe.

@bpasero Ich glaube, ich hatte keine Datei geöffnet (rechts), nur Arbeitsdateien über dem Baum. Wenn ich mich erinnere, wenn ich mit der Arbeit fertig bin, werde ich versuchen, mit geöffneter Datei zu prüfen und die Sprache zu notieren.

Ich weiß es nicht genau, aber es war wahrscheinlich keine JavaScript-Datei, als meine abstürzte, eher C ++, Java oder keine Sprache. Ich werde es sicher überprüfen.

@Tyriar Wenn es nur reproduziert wird, indem etwas unter Arbeitsdateien ist und alle Editoren geschlossen sind (direkt vom Start - das ist wichtig), sind wir möglicherweise bei etwas angelangt.

@bpasero Ich könnte versuchen, eine Reihe von Instanzen unter verschiedenen Bedingungen zu öffnen, bevor ich am Freitag die Arbeit verlasse, und räumen kann. Es sei denn, Sie haben Grund zu der Annahme, dass eine Instanz des vscode-Hängens alle anderen beschädigen würde?

@ Tyriar Ja, wenn Sie mehr als ein Fenster geöffnet haben, summiert sich alles auf den insgesamt verwendeten Speicher und alle würden abstürzen. Dies liegt daran, dass beim Öffnen mehrerer Fenster weiterhin alle übergeordneten Prozesse und ein Speicherlimit von etwa 1 bis 1,5 GB gemeinsam genutzt werden. Um wirklich zu verstehen, woher das Leck kommt, ist es am besten, 1 Fenster zu messen, das unter folgenden Bedingungen isoliert ist:

• Keine Erweiterung über --disable-extensions aktiviert (eine Erweiterung, die viel Speicher oder Lecks verbraucht, würde ebenfalls einen Absturz verursachen)
• Beim Start wurde keine Datei geöffnet (nur das Schließen einer Datei nach dem Start ist bereits zu spät)
• Keine Arbeitsdatei unter Arbeitsdateien

Übrigens ist das einzige, was für Arbeitsdateien Auswirkungen haben kann, dass wir für jede Arbeitsdatei, die sich nicht im Arbeitsbereich befindet, einen Datei-Watcher installieren, um nach Änderungen zu suchen. Vielleicht verursacht dies das Leck, wäre aber überraschend. Außerdem installieren wir keinen Watcher, wenn sich die Datei innerhalb des geöffneten Arbeitsbereichs befindet, nur für Dateien außerhalb.

@bpasero Keine Lecks, wenn keine Dateien geöffnet sind (?). Ich werde heute Abend den sauberen Arbeitsbereich ausprobieren, nachdem ich einige geöffnet habe.

Ich habe es über das Wochenende mit folgendem Setup versucht:

1. Starten Sie mit Code --disable-extensions
2. Öffnen Sie eine JavaScript-Datei mit ~ 1300 Zeilen

Speicher und CPU waren ungefähr am Freitagabend und Montagmorgen gleich.

@ Tyriar öffnete dies nur einen leeren Arbeitsbereich mit einer Datei oder öffnete zuerst einen Ordner und dann eine Datei daraus?

@bpasero Beim Öffnen des leeren Arbeitsbereichs habe ich keinen Ordner geöffnet und beim Start war kein Ordner geöffnet

Ok, gut zu wissen. Dies scheint also damit zu tun zu haben, dass ein (möglicherweise großer) Ordner geöffnet ist. Wenn Sie noch herausfinden müssen, ob das Öffnen dieses Ordners ausreicht oder ob eine Datei geöffnet ist, wird dies nur ausgelöst.

@bpasero Ich hatte einen großen Ordner geöffnet, in dem am Wochenende keine Dateien geöffnet waren, ohne dass die Speichernutzung merklich zunahm. Ich werde die Ergebnisse eines Tests zum Öffnen großer Ordner und Dateien mit hoffentlich einem reproduzierbaren / gemeinsam nutzbaren Arbeitsbereich in etwa 7 Stunden haben.

@bpasero der Ordner, in dem ich zuvor Abstürze erlebt habe, wäre 13000-14000 Dateien stark gewesen, dies schließt das Git-Repo ein, das ungefähr 2000 für sich war.

Ich denke, ich werde noch einmal überprüfen, ob der Absturz in der nächsten Version noch passiert, da es eine Weile her ist, seit ich ihn gesehen habe (aufgrund von Tests).

Und ich nehme an, es ist ein JS-Arbeitsbereich?

@bpasero py, cpp, js, html, css

Ok, dies scheint die langsam steigende Speichernutzung zu reproduzieren, wenn auch in kleinerem Maßstab: VSCodeTest.zip . Ich hatte /ext/build/ext-all-debug.js geöffnet.

(Ja, es ist eine 7z in einer Zip ... GitHub lässt mich keine 7z oder xz direkt hochladen, und Zip und Gzip sind zu groß.)

@ Elusive138 wie viel erhöht es sich für dich im Durchschnitt? Ich hatte den Arbeitsbereich mit einigen JS-Dateien jetzt seit 2 Stunden geöffnet, ohne den Speicher zu vergrößern.

@bpasero Entschuldigung, ich habe Probleme beim erneuten Reproduzieren. Ich glaube, ich hatte in einem früheren Versuch ein streunendes Git-Repo, das nicht im obigen Archiv enthalten war. Ich werde Sie wissen lassen, wenn ich konkretere Ergebnisse habe.

Wäre sehr hilfreich, wenn es möglich wäre, mehrere unabhängige Instanzen zu öffnen ... auf einen Test pro Nacht beschränkt zu sein, ist ziemlich langsam. Tragen Sie zufällig die Chromium-Flags für separate Profile?

Es ist möglich, mehrere Codeversionen zu erstellen, die parallel ausgeführt werden können, obwohl wir dies nicht dokumentiert haben. Wenn Sie die Werte in https://github.com/Microsoft/vscode/blob/master/product.json so ändern, dass sie unterschiedlich sind, und dann über die Befehlszeile erstellen, können Sie mehrere unterschiedliche Instanzen starten. Die Bezeichner, die eindeutig sein müssen, sind:

• darwinBundleIdentifier
• win32MutexName
• nameShort
• nameLong
• dataFolderName (zB "dataFolderName": ".oss-code-1")

Windows 8.1. Öffnen Sie in Code morgens einen Ordner für ein Git-Repository mit 39.000 Dateien.
Habe sehr wenig damit gemacht, ein paar kleine Änderungen in ein paar Dateien.
Am Ende des Tages betrug die vom Task-Manager gemeldete Commit-Größe 672.164 KB.
Es wuchs den ganzen Tag stetig, auch wenn ich nicht im Programm war.

@gushie Gibt es eine Chance, dass dieses Repo mit mir geteilt werden kann? Was war der ursprüngliche Speicher?

@bpasero Es tut mir leid, ich darf das Repo selbst nicht teilen, aber wenn es Details dazu gibt, die helfen könnten, mit Ausnahme des Dateiinhalts selbst, lassen Sie es mich wissen. Der Prozess beginnt zunächst bei ca. 110 MB und wächst schnell auf ca. 130 MB, bevor er sich wieder auf 90 MB einstellt. Ab diesem Zeitpunkt wird es dann stetig wachsen. (Es gibt 5 andere code.exe-Prozesse, die von 4 MB bis 30 MB variieren, aber nicht merklich wachsen. Es gibt nur ein Codefenster.)

Ich weiß nicht, wie hoch die endgültige Commit-Größe von gestern war, da der Prozess abgestürzt war, als ich heute darauf zurückkam.

@gushie Ich habe Performance Monitor für die code.exe-Prozesse verwendet, um die "Private Size" zu überwachen.

Ziemlich ärgerlich, dass wir die Arbeitsbereiche, mit denen wir Probleme haben, nicht teilen können! Ich frage mich, ob jemand dies mit etwas Open-Source begegnet ist. Auf der Suche nach Ähnlichkeiten: Wurde Ihr Repo jemals mit git-svn verwendet?

@bpasero Danke, wenn der Prozess, den ich verlassen habe, bei meiner Rückkehr am Montag nicht wiederholt wurde, könnte ich versuchen, ein paar zusätzliche Kopien zu erstellen. Müsste herausfinden, wie man den Überblick darüber behält, welches welches ist. Das könnte ein Problem sein.

@ Elusive138 Wir verwenden Atlassian-Tools, daher stellt SourceTree eine Verbindung zu einem privaten Stash-Server her

Ah, das ist ganz anders als bei mir. War ein lokales Git-Repo (mit Git-Erweiterungen), das eine Verbindung zu einem SVN-Server herstellte? Mein aktueller Test ist mit einem Git-Repo, das auf dem Vscode basiert. Hoffentlich wird das Repro und ich kann es teilen.

@gushie wird es reproduziert, wenn Sie nur den Arbeitsbereich öffnen, ohne eine Datei zu öffnen? Versuchen Sie zunächst, alle Dateien zu schließen und neu zu starten, um dieses Setup zu erhalten. Wenn dies nicht reproduziert wird, wird es reproduziert, wenn Sie den Arbeitsbereich öffnen und eine JS-Datei öffnen und es so lassen?

@bpasero Ich hatte es

Beachten Sie, dass ich die Arbeitsdateien noch nie gelöscht habe, bis ich dieses Problem gelesen habe. (Ich hatte es nicht wirklich nötig, ich ignorierte dieses Panel im Allgemeinen und wechselte die Dateien über den Projektdateiexplorer darunter oder mit Strg + E).

Wieder abgestürzt, diesmal nach regelmäßigem Gebrauch, aber in diesem Zustand belassen:

• ~ 14000 Dateiordner geöffnet
• 5 Arbeitsdateien aktiv (.cc, .java, .h, .py, .json)
• Keine Datei im Texteditor geöffnet

ps aux Ausgabe:

❯ ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
...
daniimms  6086  0.0  0.5 970620 92180 pts/0    Sl   Jan11   0:36 /home/local/ANT/daniimms/VSCode-linux-x64/Code /home/local/ANT/daniimms/VSCode-linux-x64/resources/app/out/bootstrap --type=watcherService

Wie bereits erwähnt, war dies nach dem regulären Gebrauch und nicht im abgesicherten Modus, also könnte es an einer Erweiterung liegen?

Ich habe eine einzelne Datei mit einer kleinen Bearbeitung offen gelassen, nur diese Datei in den Arbeitsdateien. Ansonsten den ganzen Tag unberührt. Der Speicher hat sich von seinem Anfangswert nicht erhöht.

@ Tyriar Nun, der Prozess, den Sie

@gushie war das ohne einen Ordner zu öffnen?

@bpasero Ich hatte den Ordner geöffnet. Es gibt offensichtlich eine Aktion, die die Speicherlecks nach dem ersten Öffnen einer Datei im Ordner auslöst. Ich werde weiterhin überwachen und versuchen, es einzugrenzen.

@bpasero Das war der einzige vscode-bezogene Prozess, den ich in der Ausgabe sehen konnte. Ist es möglich, dass er in der Ausgabe nicht sichtbar war, weil er bereits aufgrund von Reaktionslosigkeit beendet wurde? Wie gezeigt, verwendete dieser Prozess nur 0,5% des Speichers und 0% der CPU. Ich denke, aufgrund meiner jüngsten Entdeckungen ist das Problem, auf das ich stoße, wahrscheinlich nicht auf einen JS-Dienst zurückzuführen.

Übrigens, auch wenn wir den Grund dafür erst Ende des Monats finden, habe ich eine Änderung vorgenommen, sodass der Absturzdialog, den Sie standardmäßig erhalten, eine Aktion zum erneuten Öffnen des Fensters auswählt, damit Sie dort weiterarbeiten können, wo Sie gegangen sind. Dies ist auch gut für den Fall, dass mehrere Fenster geöffnet sind und nur eines davon abstürzt.

(Eine Sache fehlt und für die Zukunft ist es, den UI-Status regelmäßig auf die Festplatte zu leeren, damit durch das erneute Öffnen auch Ihre vorherige Arbeitsumgebung wiederhergestellt wird.)

@bpasero : +1: das wäre hilfreich.

VS stürzt seit ungefähr einem Monat jeden Morgen ab. Ich bin am Ende meiner Geduld angelangt.

Ich hoffe, dass dies als PRI 0-Fehler behandelt wird, da ein vernünftiger Editor nicht so oft abstürzen sollte.

Bitte lassen Sie mich wissen, wie ich herausfinden kann, warum dies geschieht. Ich habe dies auch auf anderen Maschinen gesehen.

@nojvek Kannst du mir den Arbeitsbereich

Ich bin mir nicht sicher, was Sie unter Arbeitsbereich freigeben verstehen. Es ist ein Typoskript / HTML / CSS-Projekt mit etwas C ++. Rund 1500 Dateien und 80.000 Codezeilen.

Gibt es in VS eine Möglichkeit, Crashdumps anzuzeigen?

@nojvek Ich hätte gerne einen Arbeitsbereich, mit dem ich Code ausführen kann, um dieses Problem zu reproduzieren. Wir vermuten, dass es irgendwo mit einem Speicherverlust zusammenhängt, es ist einfach nicht klar, wo. Wenn Sie mir eine Zip-Datei des Arbeitsbereichs oder möglicherweise die Git-URL senden können, wenn es sich um Open Source handelt.

Benjamin,

Sein interner Microsoft-Quellcode und ich glaube nicht, dass ich ihn Ihnen geben kann.

Wenn es ein Speicherüberwachungstool gibt, das ich hinzufügen kann, lassen Sie es mich wissen.

Würde es funktionieren, wenn ich Speicher-Snapshots mit dem eingebetteten Chrome-Debugger machen würde?
in vscode alle paar stunden um zu sehen was los ist?

Am Samstag, 23. Januar 2016, Benjamin Pasero [email protected]
schrieb:

@nojvek https://github.com/nojvek Ich hätte gerne einen Arbeitsbereich, der
Ich kann Code mit ausführen, um dieses Problem zu reproduzieren. Wir vermuten, dass es mit a zusammenhängt
Speicherverlust irgendwo, es ist einfach nicht klar, wo. Wenn du mir einen Reißverschluss schicken kannst
des Arbeitsbereichs oder vielleicht der Git-URL, wenn es Open Source ist.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/Microsoft/vscode/issues/508#issuecomment -174192367.

Ja, Speicher-Snapshots helfen genau dann, wenn sich dieses Leck auf der Hauptseite von VS Code befindet. Es scheint jedoch, dass zumindest in einem Fall das Leck in einem der Prozesse war, die wir erzeugen (dem Datei-Watcher). Vielleicht können Sie mithilfe des Prozess-Explorers feststellen, welcher Prozess im Hinblick auf den Speicherverbrauch ständig zunimmt.

Wenn es hilft, mir den Quellcode zur Verfügung zu stellen: Ich arbeite für Microsoft;)

Ich werde mit meinem Manager sprechen. Dies ist in Windows Repo, also muss ich
Sei ein bisschen vorsichtig.

Aus dem Thread geht hervor, dass der Chokidar für den Datei-Watcher verwendet wird. Eine Weile
zurück Ich habe mit dem Quellcode gespielt. Es war ein bisschen Spaghetti.

Ich werde sehen, ob ich Chokidar auf seiner eigenen einfachen Knoten-App laden kann und ob es ist
der Täter.

Übrigens gibt es bestimmte Gründe, warum vs Chokidar verwenden muss? Da sind andere
plattformübergreifende Datei-Beobachter, oder?

Am Sonntag, dem 24. Januar 2016, Benjamin Pasero [email protected]
schrieb:

Ja, Speicher-Snapshots helfen genau dann, wenn sich dieses Leck in der Hauptleitung befindet
Seite des VS-Codes. Es scheint jedoch, dass zumindest in einem Fall das Leck war
in einem der Prozesse, die wir erzeugen (der Datei-Watcher). Vielleicht könntest du
Identifizieren Sie mit dem Prozess-Explorer, in welchem ​​Prozess der Prozess ständig zunimmt
hinsichtlich des Speicherverbrauchs.

Wenn es hilft, mir den Quellcode zur Verfügung zu stellen: Ich arbeite für Microsoft;)

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/Microsoft/vscode/issues/508#issuecomment -174269028.

Chokidar wird unter Mac und Linux verwendet. Wenn Sie unter Windows arbeiten, verwenden wir einen C # -Datei-Watcher. Ich bin froh, eine PR mit einer funktionierenden und performanten Cross File Watcher-Lösung zu akzeptieren :)

Sie wissen, dass ab Knoten 4.0 die fs.watch sowohl unter Windows als auch unter Mac stabilisiert ist. Siehe: https://github.com/Microsoft/TypeScript/issues/4643.

Typescript hat eine ziemlich solide plattformübergreifende Logik zur Überwachung von Dateien und Verzeichnissen. https://github.com/Microsoft/TypeScript/blob/931d162620c7e09377c12875834e1838c4cdd51b/src/compiler/sys.ts

Ich werde versuchen, mit einer Änderung einen lokalen Build von VS-Code zu erhalten und zu prüfen, ob dieser immer noch abstürzt. Wenn nicht, schicke ich definitiv eine PR.

Ich weiß, dass es viel besser geworden ist, indem der rekursive Überwachungsaufruf für das Verzeichnis verwendet wurde und somit vermieden wurde, dass ein Überwachungslistener pro Ordner angehängt werden muss, aber ich denke, dass die Ereignisse manchmal immer noch den Datei- / Ordnernamen verfehlen, zumindest in einigen Fällen. Ich fühle mich mit C # hier sicherer.

Ich habe heute einen Repro bekommen. Ich bin gerade abgestürzt, bevor ich die Developer Tools-Konsole aufrufen wollte, um einen Speicher-Snapshot zu erstellen.

http://i.imgur.com/rirFul1.png

Es scheint, dass der Typoskript-Server ungefähr 200 MB benötigt.
Der Renderer verbrauchte ungefähr 800 MB und stürzte dann ab.

Wenn ich ungefähr 500 MB ausgelastet bin, werde ich versuchen, einen Speicher-Snapshot zu erstellen. Der --renderer-Prozess ist der Webkit-Prozess, oder?

Dies war nach zwei Tagen, seit ich das letzte Mal einen Absturz gesehen habe. Die Verwendung des Tools über einen Zeitraum von 8 Stunden scheint die Bearbeitung vieler TS-Dateien zu beschleunigen.

Schön, der Renderer-Prozess ist der Hauptprozess für den Editor. Wenn Sie dort einen Speicher-Snapshot erstellen können, würde dies uns weiterbringen. Leider würde der Schnappschuss für keinen anderen Prozess funktionieren, aber diese scheinen in Ordnung zu sein.

Ist es normal, dass tscse (Typoskript-Server) 200 MB verbraucht?

Am Dienstag, den 26. Januar 2016 um 21:29 Uhr, Benjamin Pasero [email protected]
schrieb:

Schön, der Renderer-Prozess ist der Hauptprozess für den Editor. Wenn du
kann dort einen Erinnerungsschnappschuss machen, der uns weiter bringen würde. Leider die
Schnappschuss würde für keinen anderen Prozess funktionieren, aber diese scheinen zu funktionieren
sei ok'ish.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/Microsoft/vscode/issues/508#issuecomment -175408302.

Ja, sehr leicht.

Lol! Ich war gerade dabei, einen Heap-Schnappschuss zu machen, und VS stürzte ab.

Ich werde es noch einmal versuchen und sehen, ob ich morgen besseres Glück habe.

Gibt es eine Möglichkeit, vscode anzuweisen, das Speicherlimit zu erhöhen, damit es beim Versuch, einen Heap-Snapshot zu erstellen, nicht abstürzt?

Ich denke, was passiert ist, dass das Aufnehmen des Schnappschusses, den Sie verursacht haben, eine Ausnahme aufgrund von Speichermangel verursacht hat: - /. Es gibt keine Möglichkeit, das Speicherlimit zu ändern. Es ist in V8 fest codiert.

Versuchen Sie vielleicht, den Schnappschuss etwas früher zu machen, bevor die Speichernutzung so hoch wird? Ist es eine allmähliche Zunahme?

Ich konnte in den letzten zwei Wochen keine Reproduktion durchführen (keine Abstürze, angemessene Speichernutzung). Der einzige Unterschied, den ich mir vorstellen kann, ist die Aktualisierung der PowerShell-Erweiterung von 0.1.0 auf 0.3.1 - aber ich habe sowieso keine PS-Dateien im Arbeitsbereich und sie stürzte mit deaktivierten Erweiterungen ab.

Ich habe einen erfolgreichen Speicherauszug von ca. 300 MB erhalten, der vom --renderer-Prozess verwendet wird. Es stürzte 10 Sekunden nachdem ich den Dump genommen hatte.

Es scheint, dass der Großteil der Nutzung im DOM-Baum liegt.

https://www.dropbox.com/s/dk5exyke3fqgahk/VS.heapsnapshot?dl=0

Hoffe das hilft.

Hmmmm, ich frage mich, ob der Profiler hier die wahre Wahrheit sagt. Ich sehe alle Baumelemente und wir könnten genauso gut ein Leck im Baum haben, aber ich wäre überrascht, dass dieses Leck in so kurzer Zeit zu einem Speichermangel führen könnte.

Ich nahm noch ein paar Müllkippen.

Es scheint, dass das Öffnen von .min.js-Dateien einen großen Speichersprung verursacht. Selbst nach dem Schließen der Dateien scheint der Speicher nicht zu sinken. Zwischen allen Speicherabbildern scheint DOM der Dominator zu sein.

Auch nicht sicher, warum es zwei Renderer-Prozesse gab. Vielleicht war einer von ihnen die Chrom-Devtools. Aber ich bin einem Auftritt sehr nahe gekommen.

https://www.dropbox.com/sh/3t238zx7l3vfpzx/AABCbFBNYLzHinkN7OTe6ubya?dl=0

Ich habe einen Screenshot der beiden Prozesse gemacht, die ~ 500 MB RAM verbrauchen.

Ja, man ist devtools. Es wird erwartet, dass der Speicher beim Öffnen von Dateien größer wird. Aber ich würde gerne verstehen, wie ein VS-Code, der über Nacht ohne Aktivität ausgeführt wird, die Speichernutzung erhöht, bis er abstürzt.

Nun, der Repro ist:
Start vs Code.
Öffnen Sie eine oder zwei js / ts-Dateien in einem großen Ordner mit vielen .tsconfig-Dateien.
Führen Sie einen Bildlauf / eine Bearbeitung durch.
Schließen Sie alle Arbeitsdateien.
Legen Sie es über Nacht bei 200 ° C in den geraden Bereich.
Kuchen!

Am Freitag, 29. Januar 2016, Benjamin Pasero [email protected]
schrieb:

Ja, man ist devtools. Es wird erwartet, dass der Speicher beim Öffnen größer wird
Dateien. Aber ich würde gerne verstehen, wie ein VS-Code überläuft
Nacht ohne Aktivität erhöht die Speichernutzung, bis es abstürzt.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/Microsoft/vscode/issues/508#issuecomment -177087988.

@nojvek Sind die .tsconfig s notwendig, um zu repro? Weil ich in der Vergangenheit Abstürze hatte, ohne dass es irgendetwas mit TS zu tun hatte. Obwohl ich diese nicht einmal mehr tadeln kann ...

Unser Projekt hat sie einfach. Könnte ein roter Hering sein.

Am Samstag, dem 30. Januar 2016, schrieb Bob [email protected] :

@nojvek https://github.com/nojvek Sind die .tsconfigs dazu notwendig
Repro? Weil ich in der Vergangenheit Abstürze hatte, ohne dass etwas mit TS zu tun hatte
alle. Obwohl ich diese nicht einmal mehr tadeln kann ...

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/Microsoft/vscode/issues/508#issuecomment -177198518.

Die einzigen. * -Dateien, die wir in unserem Ordner haben, sind der .git-Ordner und .gitignore

@nojvek Verwenden Sie einen benutzerdefinierten Typoskript-Server für das Projekt oder den sofort einsatzbereiten TS, den wir in 0.10.6 ausliefern? Die Version 0.10.6 ist TypeScript 1.7.5

@bpasero @nojvek, wenn es sich um ein Speicherproblem auf der JS-Seite handelt. Sie können den Heap-Schnappschuss in Chrome unterscheiden.

1. Mach einen Schnappschuss.
2. Führen Sie die Aktion aus, die einen Speicherverlust verursacht.
3. Speicherbereinigung erzwingen. Andernfalls enthält der nächste Heap-Snapshot die Objekte.
4. Machen Sie einen weiteren Schnappschuss.
5. Diff beide Schnappschuss.

Alles kann mit den oben genannten Chrome Devtools erledigt werden. Die Stärke der Speicherbereinigung befindet sich auf der Registerkarte "Zeitachse", dem Speicherbereinigungssymbol. Die Abweichung erfolgt durch einfaches Auswählen im Snapshot-Explorer im Filtermenü.

Geben Sie einfach an, welche Objekte beibehalten werden und welche Pfade möglicherweise beibehalten werden (direkt unter der Heap-Tabelle). Und das sind alle Daten, die zur Behebung dieses Problems benötigt werden.

Sie müssen nicht einen ganzen Tag warten, um Daten über einen Absturz zu sammeln: wink:

Über den von mir gesendeten Dropbox-Link wurden drei Hitze-Schnappschüsse im Abstand von einer halben Stunde erstellt.
Ich habe die Müllabfuhr nicht erzwungen. Wird das einen Trick geben.

Am Sonntag, dem 31. Januar 2016, schrieb Tingan Ho [email protected] :

@bpasero https://github.com/bpasero @nojvek https://github.com/nojvek
wenn es sich um ein Speicherproblem auf der JS-Seite handelt. Sie können den Heap-Schnappschuss unterscheiden
Chrom.

1. Mach einen Schnappschuss.
2. Führen Sie die Aktion aus, die einen Speicherverlust verursacht.
3. Speicherbereinigung erzwingen. Andernfalls wird der nächste Heap-Snapshot erstellt
   Schließen Sie die Objekte ein.
4. Machen Sie einen weiteren Schnappschuss.
5. Diff beide Schnappschuss.

Alles kann mit den oben genannten Chrome Devtools erledigt werden. Die Kraft des Mülls
Die Sammlung befindet sich auf der Registerkarte "Zeitachse", dem Garbage-Symbol. Und das ist anders
Wählen Sie es einfach im Snapshot-Explorer im Filtermenü aus.

Geben Sie einfach an, welche Objekte beibehalten werden und welche Pfade möglicherweise beibehalten werden (siehe unten)
die Heap-Tabelle). Und das sind alle Daten, die zur Behebung dieses Problems benötigt werden.

Sie müssen nicht einen ganzen Tag warten, um Daten über einen Absturz zu sammeln [Bild:
:zwinkern:]

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/Microsoft/vscode/issues/508#issuecomment -177462412.

Ich habe das gleiche Problem, VS Code stürzt ständig ab, nicht nur über Nacht, auch nach 30 Minuten Leerlauf.
Ich verwende Windows 7, 64 Bit und die neueste Version von VS Code. In Bezug auf das Projekt selbst ist es ein riesiges js-Projekt, in das auch node_modules und bower_components geladen sind. Insgesamt hat es rund 40K Dateien.

Schritte zum Reproduzieren:
1) Öffnen Sie den Projektordner (mit vielen Dateien) und mehrere Dateien, damit sie sich in der Liste der Arbeitsdateien befinden.
2) Öffnen Sie den Task-Manager.
3) Setzen Sie den Cursor, um eine Datei im VS-Code zu fokussieren
4) Beobachten Sie, wie der Speicher im Laufe der Zeit steigt.

Können Personen mit JS-Arbeitsbereichen, die dieses Problem sehen, unseren Insidern von 0.10.7 einen Versuch (https://vscode-builds.azurewebsites.net/insider) mit der Option geben, Salsa als JS-Sprachdienst zu verwenden: https://github.com /Microsoft/vscode-docs/blob/vnext/release-notes/latest.md#javascript --- Salsa-Vorschau

Vielen Dank!

+1 für dieses Problem. Erscheint auch unter Windows. Es ist total nervig und ich mag es nicht.

@bpasero Ich möchte den neuen Build ausprobieren, aber wenn ich versuche, auf den von Ihnen angegebenen Link (https://vscode-builds.azurewebsites.net/insider) zuzugreifen, wird eine sehr nicht hilfreiche Fehlermeldungsseite mit dem folgenden Text angezeigt ::

Anmelden
Entschuldigung, aber wir haben Probleme, Sie anzumelden.
Wir haben eine schlechte Anfrage erhalten.

Zusätzliche technische Informationen:
Korrelations-ID: e477dc1b-c193-4cf9-864b-1d3fdbba4f34
Zeitstempel: 2016-02-03 19: 37: 17Z
AADSTS50020: Benutzerkonto ' [email protected] ' vom Identitätsanbieter ' https://sts.windows.net/5a7d8144-6966-4b1e-8147-de672a307ea0/ ' ist im Mandanten 'Microsoft' nicht vorhanden und kann nicht auf die Anwendung zugreifen. ' 9d5f02f6-ffd9-4e80-92d5-e42c85e09bc9 'in diesem Mieter. Das Konto muss zuerst als externer Benutzer im Mandanten hinzugefügt werden. Melden Sie sich mit einem anderen Azure Active Directory-Benutzerkonto ab und wieder an.

Ich kann den Build aufgrund dieses Problems nicht herunterladen und ausprobieren.

Entschuldigung, falscher Link, bitte verwenden Sie https://code.visualstudio.com/insiders

@bpasero danke Ich habe die Insider-

@bpasero , ich habe versucht, Insider freizugeben, und das Problem besteht immer noch, nachdem eine Nacht im Leerlauf VS Code abgestürzt ist.

@milenkovic @gwynjudd Sie müssen auch die Schritte ausführen, um Salsa zu aktivieren, wie unter https://github.com/Microsoft/vscode-docs/blob/vnext/release-notes/latest.md#javascript --- salsa- beschrieben Vorschau

@bpasero , Sie hatten Recht, die Aktivierung von Salsa hat das Problem behoben. Ich habe VS Code über das Wochenende geöffnet gelassen und es ist immer noch nicht abgestürzt.

Gut das zu hören! Wäre interessant, wenn andere dies auch durch einen Versuch überprüfen könnten.

@bpasero Ich hatte Salsa aktiviert und über das Wochenende laufen lassen. Heute morgen war es abgestürzt.

Installiertes Typoskript

$ npm install -g typescript<strong i="6">@next</strong>
C:\Users\mapatel\AppData\Roaming\npm\tsserver -> C:\Users\mapatel\AppData\Roaming\npm\node_modules\typescript\bin\tsserver
C:\Users\mapatel\AppData\Roaming\npm\tsc -> C:\Users\mapatel\AppData\Roaming\npm\node_modules\typescript\bin\tsc
C:\Users\mapatel\AppData\Roaming\npm

Ich habe settings.json auf gesetzt

{
    "typescript.tsdk": "C:/Users/mapatel/AppData/Roaming/npm/node_modules/typescript/lib"
}

und die Umgebungseinstellung

$ setx VSCODE_TSJS 1

SUCCESS: Specified value was saved.

Ich sehe immer noch keine Salsa in der Fußzeile von VS Code Insider.

@nojvek Ich habe im Grunde das getan, was Sie getan haben, und ich sehe Salsa in der Fußzeile, aber nur, wenn eine .js-Datei geöffnet und im Editor sichtbar ist

@gwynjudd Ich nehme an, Sie haben den Absturzdialog erhalten und konnten nun mit 0.10.8 das Fenster wieder öffnen?

@bpasero ja ich habe den neuen

Gwyn Judd

-------- Originale Nachricht --------
Von: Benjamin Pasero
Datum: 02/09/2016 19:13 (GMT + 12: 00)
An: Microsoft / vscode
Cc: Gwyn Judd
Betreff: Re: [vscode] Absturz beim Laufen über Nacht (# 508)

@gwyn juddhttps: //github.com/gwynjudd Ich nehme an, Sie haben den Absturzdialog erhalten und konnten nun mit 0.10.8 das Fenster wieder öffnen?

Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf Gi tHubhttps: //github.com/Microsoft/vscode/issues/508#issuecomment -181726111 an.

@gwynjudd Ist dies ein JS-Arbeitsbereich oder andere Dateitypen wie PHP?

@bpasero Es gibt viele Dateitypen, einschließlich Typoskript, Java-Skript, CSS, Less, Aspx, CS

Gwyn Judd

-------- Originale Nachricht --------
Von: Benjamin Pasero
Datum: 02.09.2016 22:49 (GMT + 12: 00)
An: Microsoft / vscode
Cc: Gwyn Judd
Betreff: Re: [vscode] Absturz beim Laufen über Nacht (# 508)

@gwyn juddhttps: //github.com/gwynjudd Ist dies ein JS-Arbeitsbereich oder andere Dateitypen wie PHP?

Antworten Sie direkt auf diese E-Mail oder sehen Sie sie sich unter Gi tHubhttps an: //github.com/Microsoft/vscode/issues/508#issuecomment -181786273.

Mit dem neuen Build ist es jeden Morgen abgestürzt, wenn es über Nacht laufen gelassen wurde. Ich habe nur diese Erweiterungen installiert (im neuen Build hatte ich im Release-Build verschiedene Erweiterungen):

Als ich heute Morgen zur Arbeit kam, war es nicht abgestürzt. Ich habe nichts anderes gemacht, bevor ich am Freitag die Arbeit verlassen habe.

Sollte versuchen, mit dem Chromium-Arbeitsbereich unter Verwendung von Ubuntu zu reproduzieren, da @Tyriar anscheinend ein

Befolgen Sie die Anweisungen hier, um den Code https://www.chromium.org/developers/how-tos/get-the-code zu erhalten

Ich habe auch eine Verzögerung im Code nach einiger Zeit bemerkt und eventuelle Abstürze. Ich habe festgestellt, dass es bei Verzögerung zu einem reibungslosen Ablauf kommen kann, wenn ich F1 drücke und 'Fenster neu laden' eingebe. Das scheint das Problem für den Moment zu klären und dann kann ich es jetzt umgehen. Ich bin definitiv interessiert, dies behoben zu sehen.

Nach dem Lesen dieses Threads schätze ich auch, dass dies auf den Renderprozess zurückzuführen ist, obwohl ich noch keine Tests damit durchgeführt habe, und es scheint unabhängig von der Anzahl der Arbeitsdateien in der Liste im Explorer-Bereich zu geschehen, ob oder nicht, eine Datei ist geöffnet, wenn Code geladen wird, vielleicht die Größe der Dateien, an denen gerade gearbeitet wird, und ich bin nicht sicher, ob es irgendetwas mit dem Git Diff Checker zu tun hat oder nicht, aber ich bezweifle, dass es der Schuldige wäre .

Ich bin auch unter Mac OS X El Capitan 10.11.3 und habe das Problem unter Windows nicht wirklich gesehen, als ich es zu Hause verwendet habe, aber ich habe keinen riesigen Arbeitsbaum für Projekte zu Hause, nur das massiver Ordner, aus dem ich bei der Arbeit arbeite.

Ich würde hoffen, dass beide Probleme zusammenhängen, aber ich befürchte, dass dies nicht der Fall ist: Die meisten Leute hier sehen, dass Code abstürzt, wenn sie ohne Benutzerinteraktion ausgeführt werden, was sehr verdächtig erscheint. Es kann jedoch durch andere Speicherlecks verursacht werden, dass Code bei längerer Verwendung mit einer Ausnahme wegen Speichermangels abstürzt. Im Idealfall sind beide Probleme gleich :)

Technisch gesehen scheint es zu verlangsamen und abzustürzen, auch wenn ich es nicht benutze, aber ich bin mir nicht sicher, ob sie in diesem Fall auch dasselbe erleben. In jedem Fall scheinen die Symptome zumindest ähnlich zu sein. Wenn sich herausstellt, dass mein Problem nicht zusammenhängt, kann ich stattdessen ein separates Problem erstellen.

@cwadrupldijjit Wenn Sie das Problem mit einem Absturz über Nacht sehen, ist es hilfreich, wenn möglich auf den Arbeitsbereich zuzugreifen.

Ich sehe was ich tun kann. Normalerweise lege ich den Mac nachts in den Schlaf, sodass in dieser Zeit nichts passiert. Ich werde versuchen, es nachts einzuschalten und Sie am Morgen wissen lassen, wenn etwas passiert. Ich werde Sie auch auf dem Laufenden halten, wenn Sie auf meinen Arbeitsbereich zugreifen können.

Klingt gut. Danke!

K. Also habe ich die Code-Instanz über Nacht laufen lassen und hatte kein Problem damit, dass sie abstürzt oder sich sofort verzögert fühlt. Ich habe heute weiter gearbeitet und sogar eine kleine Pause eingelegt, um andere Dinge zu erledigen, und es wurde wieder träge. Es scheint fast so, als ob das Problem nicht darin besteht, es aktiv zu nutzen, aber es klingt auch so, als hätte es während der Zeit, in der ich daran gearbeitet habe, durch etwas anderes ausgelöst.

Ich werde den Profiler ausführen, um ihn im Auge zu behalten, und ein neues Problem erstellen, wenn andere als die oben erläuterten Ergebnisse vorliegen.

Ich habe nicht überprüft, ob Sie Zugriff auf meinen Arbeitsbereich haben können, obwohl ich vermuten würde, dass ich das leider nicht mit Ihnen teilen kann.

Ich habe gestern versucht, den Profiler auszuführen, als es besonders langsam wurde und als ich einen Heap-Snapshot machte, der Computer nicht genügend RAM zur Verfügung hatte, und ich konnte kaum etwas tun, nicht einmal das Schließen von Code erzwingen, also musste ich neu starten der Computer. Ich werde versuchen, es früher als zuvor auszuführen, um zu verhindern, dass es erneut passiert.

Dies ist ein wenig abseits des Themas, aber Sie haben den Link für den Insider-Build gepostet, den ich besucht habe. Ich wollte die Windows-Version herunterladen (wie ich sie zu Hause verwende), und wenn ich versuche, zu diesem Link zu gelangen, wird zuerst zur üblichen Download-Seite weitergeleitet, aber dann umgehend zur Hauptseite weitergeleitet, ohne dass ein Download initiiert wird. Tatsächlich überschreibt es den Verlauf der Download-Seite, auf der ich mich befand, sodass ich nicht einmal in den Verlauf zurückkehren kann, um darauf zuzugreifen. Gibt es eine andere Möglichkeit, die Insider zum Bauen zu bringen?

@cwadrupldijjit

Dies ist ein wenig abseits des Themas, aber Sie haben den Link für den Insider-Build gepostet, den ich besucht habe. Ich wollte die Windows-Version herunterladen (wie ich sie zu Hause verwende), und wenn ich versuche, zu diesem Link zu gelangen, wird zuerst zur üblichen Download-Seite weitergeleitet, aber dann umgehend zur Hauptseite weitergeleitet, ohne dass ein Download initiiert wird.

Tut mir leid, aber einige Benutzer haben ein seltsames Problem beim Insider-Build gemeldet und es vorübergehend entfernt, bis wir dieses Problem verstanden haben.

@egamma Ich

@ Tyriar Ich habe den Chrom-Arbeitsbereich über Nacht unter Linux, Windows und Mac ausprobiert und konnte keinen Absturz reproduzieren. Könnten Sie es bitte noch einmal versuchen?

Ich bin nicht sicher, ob dies damit zusammenhängt, aber ich habe festgestellt, dass VS Code während meines Arbeitstages zum Absturz neigt, wenn ich ihn öffne und für eine Weile vergesse. Ich bin 11 Stunden bei der Arbeit und öffne Code normalerweise als erstes am Morgen. Irgendwann im Laufe des Tages wird mein Computer langsamer und hängt, bis er entweder abstürzt oder ich ihn gewaltsam töte.

Nur für den Fall, dass es helfen könnte ...

Das Hauptprojekt, das ich in VS Code geöffnet habe, ist eine relativ unveränderte Version eines Einkaufswagens namens BVCart (Version 2004.7). Ich habe momentan ungefähr 25-30 Arbeitsdateien und selbst wenn ich VS Code nur öffne und ihn nicht den ganzen Tag berühre, kommt es zu einem Absturz.

Das Projekt umfasst 1836 Dateien und 130 Ordner mit einer Gesamtgröße von 35 MB und ist in einem kleinen Git-Repository enthalten.

@ZombieProtectionAgency Kann ich diesen Arbeitsbereich mit mir teilen?

@bpasero Entschuldigung, ich konnte es definitiv nicht teilen :( Ich habe nicht

Ich habe genau den gleichen Fehler. VS Code stürzt nur alle paar Minuten ab. Ich benutze es mit Ulme. Es kollidiert nicht, wenn es eingeschaltet bleibt. Es stößt innerhalb von Minuten nach dem Beenden der Datei zusammen. In den letzten drei Tagen war VS Code so unbrauchbar. Wie überprüfe ich, was los ist? Ich verwende Version 0.10.10.

Ein anderer Gedanke, den ich hatte: Wir haben einen Dienst, der Ausgaben von verschiedenen Endpunkten (Git, Aufgaben, Erweiterungen) empfangen kann, und dies kann im Hintergrund geschehen und sich summieren. Wir haben in diesem Bereich einige Korrekturen für GA vorgenommen, die nicht in früheren Versionen enthalten waren.

Wenn jemand mit Abstürzen über Nacht nur kurz überprüfen könnte, ob eine Ausgabe aus dem Hintergrund protokolliert wird? Sie können dies unter Ansicht> Ausgabe umschalten sehen und dann aus der Dropdown-Liste durch die Kanäle wechseln.

@bpasero
In der Ausgabe 'Aufgaben' sehe ich nur die Ausgabe, die ich von meiner eigenen Kompilierungsaufgabe erwarten würde.
In der 'Git'-Ausgabe sehe ich ein paar Git-Fetch's, durchsetzt mit ein paar Git-Shows. Ich bin mir nicht sicher, wie oft, da es keinen Zeitstempel gibt. Keine andere Ausgabe.

Wir rufen ab und zu automatisch ab, aber die Hauptausgabe, die Sie dort sehen, stammt wahrscheinlich aus der Arbeit, die Sie in VS Code ausführen. Wäre interessant, wenn sich die Ausgabe summiert, wenn sich VS Code im Hintergrund befindet. Wird die Aufgabe ständig ausgeführt oder nur, wenn Sie die Kompilierungsaufgabe explizit aufrufen?

Die Aufgabe ist nur, wenn ich Strg + Umschalt + B drücke und kurz danach endet. Ich hatte jedoch Abstürze, wenn ich keine Aufgabe ausgeführt habe.

Ich bekomme zwei identische Git-Shows, wenn ich zwischen Dateien wechsle, und ja, die Git-Abrufe erfolgen automatisch alle paar Minuten.

Beachten Sie, dass ich in VSCode keine Checkouts usw. durchführe. Ich verwende SourceTree für alle Aufgaben im Zusammenhang mit Git.

@bpasero Ich werde das Ausgabefenster heute verlassen und sehen, ob etwas erscheint. Derzeit ist es ungefähr eine Stunde lang geöffnet und ich sehe nichts in den Aufgaben oder Git-Ansichten. Wir verwenden kein Git, daher würde ich in der Regel nichts davon erwarten.

Unser neuester Insider-Build ist erschienen und ich würde mich freuen, wenn die Leute dieses Problem ausprobieren könnten: https://code.visualstudio.com/insiders

@bpasero Ich hatte immer noch den vorherigen Insider-Build. Kann ich das einfach ausführen und "nach Updates

Ich werde versuchen, mich bei Ihnen zu melden. Um ehrlich zu sein, sehe ich weniger vom VSCode
stürzt heutzutage ab. Zumindest stürzt es nicht jeden Tag ab.

Ich kann es zum Absturz bringen, indem ich eine riesige Datei mit mehr als einer Million Zeilen öffne
js minimiert und wiederholt auf und ab gescrollt. Aber ich weiß was ist
die Grenzen des Editors überschreiten.

Was auch immer Sie als magische Sauce hinzugefügt haben, funktioniert für mich.

Am Mittwoch, 16. März 2016, um 12:29 Uhr, Benjamin Pasero [email protected]
schrieb:

Unser neuester Insider-Build ist erschienen und ich würde mich freuen, wenn die Leute das könnten
Probieren Sie dieses Problem aus: https://code.visualstudio.com/insiders

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/Microsoft/vscode/issues/508#issuecomment -197503185

@gwynjudd Sie sollten in der Lage sein zu aktualisieren, wenn das VS-Code-Logo als grünes Logo

@nojvek ja das geht ein bisschen an die grenzen. Für die Veröffentlichung im März haben wir explizite Gedächtnistests durchgeführt, um Bereiche zu finden, in denen wir uns verbessern können. Der Insider-Build enthält einige dieser Korrekturen (nicht alle, wir haben gestern und heute einige Änderungen vorgenommen, die noch nicht vorliegen). also nur neugierig, ob es für Leute, die das sehen, einen Unterschied macht ...

@bpasero danke ich habe das gemacht und ich werde dich wissen lassen wie es geht

@bpasero hatte immer noch den gleichen Absturz über Nacht mit dem Marsch Insider Insider Build. Soll ich versuchen, während des normalen Gebrauchs einen Heap-Dump von den Entwicklertools zu erhalten? Ich kann versuchen, die Speichernutzung für Code im Auge zu behalten und einen Speicherauszug zu erstellen, wenn er zu steigen scheint

Ja bitte, danke.

Hier ist ein Heap-Snapshot unmittelbar nach dem Starten des Codes (Speicherauslastung ca. 100 MB zu diesem Zeitpunkt).

Heap-20160318T115937.zip

Ich werde es in ein oder zwei Stunden erneut versuchen. Das Knifflige scheint zu sein, es an einem Punkt zu bekommen, an dem der Speicher etwas zugenommen hat, aber nicht so sehr, dass das Aufnehmen des Schnappschusses dazu führt, dass der Speicher nicht mehr ausreicht.

Ich habe die gleichen Ergebnisse gesehen, als ich versucht habe, einen Heap-Schnappschuss zu machen (nicht genügend Speicher), und es macht keinen Spaß.

Ich habe das Gefühl, dass der neueste Insider-Build (für Mac) noch einige Speicherprobleme aufweist. Ich werde sehen, ob ich einen weiteren Heap-Schnappschuss erhalten kann, ohne meinen Computer zu opfern.

@bpasero Entschuldigung, ich konnte noch keinen erfolgreichen Heap-Schnappschuss

Ich muss vscode 1-2 mal am Tag neu starten, da die Speichernutzung über 1 GB steigt und sich die Dinge langsam anfühlen. Es wird die Speichermenge verwendet, die eine vollständige IDE benötigt, sodass definitiv ein Leck auftritt.

@ vincent-ly können Sie weitere Details zu dem Arbeitsbereich mitteilen, mit dem Sie dies sehen?

@bpasero Es gibt ungefähr 30-40 js / scss / html-Dateien, die einige Bower-Komponenten mit gulp verwenden (ohne den vscode-Task-Runner). Ich arbeite mit 2 Editorfenstern und benutze häufig die Dateisuche, ziemlich normal. Die Speichernutzung liegt beim Start unter 100 MB, steigt jedoch im Laufe der Zeit an, selbst wenn sie minimiert wird.

Spielt Intellisense eine Rolle? Ich habe Angular- und jQuery-Typdefinitionen installiert.

Sie können unseren Insider-Build ausprobieren, bei dem wir an einem reduzierten Speicherdruck gearbeitet haben, um festzustellen, ob dies besser ist: http://code.visualstudio.com/download?insiders=true

Haben Sie Erweiterungen installiert?

@bpasero Nur eckige Schnipsel
https://marketplace.visualstudio.com/items?itemName=johnpapa.Angular1

Ich werde den Insider-Build ausprobieren und zurückmelden, danke!

+1

Das gleiche Problem wird in VSCode für Windows 0.10.11 angezeigt. Es stürzt normalerweise jede Nacht regelmäßig ab, wenn es nicht verwendet wird. Angesichts der Schritte zum Sammeln von Informationen würde ich gerne helfen.

Läuft auf einem TypeScript Git Repo mit 28.438 Dateien, 4.812 Ordnern. Hat auch Schluckbeobachter mit vielen TypeSript-Defs.

Ich habe die folgenden Erweiterungen installiert:

• Power Shell
• C #
• Material Theme Kit

@alanwright könnten Sie versuchen, ob es immer noch mit unserem neuesten Insider-Build (http://code.visualstudio.com/Download#insiders) reproduziert wird. Wenn ja, können Sie den Arbeitsbereich mit mir teilen?

@bpasero Es wurde über Nacht mit Insider-Build reproduziert. Ich habe es sowohl in unserer privaten größeren Registrierung als auch in unserer Open-Source-Registrierung versucht, und nur die größere private Registrierung schien das Problem zu verursachen, das ich leider nicht teilen kann (es ist jedoch Microsoft-intern, sodass wir Ihnen möglicherweise Zugriff gewähren können? Mein Alias ​​ist alanwri)

Kann ich auf meinem Computer etwas tun, um Protokolle zu erfassen und mit Ihnen zu teilen?

Bitte teile mir meinen Alias ​​Benjamin mit, danke! Ich würde mich auch über einige Details freuen, wie Sie VS-Code in diesem Arbeitsbereich verwenden, um den Speicher zu vergrößern.

Ich stürze auch über Nacht und tagsüber ab.

Es scheint nicht besonders auf einen Arbeitsbereich, extrem kleine Arbeitsbereiche mit 3 bis 20 Dateien oder große Arbeitsbereiche zurückzuführen zu sein, die vor allem beim Öffnen mehrerer Fenster bemerkt werden.

Repos habe ich benutzt, die abgestürzt sind.
1500+ asp, js, .inc (asp) Dateien
70 + Dateien asp.net core, js, cshtml
Dieses Repo (https://github.com/gogits/gogs)

@ eByte23 laufen Sie mit oder ohne Erweiterungen? Auf welcher Plattform bist du? Hast du es mit Insider-Release versucht?

@bpasero Win10 & OSX mit C # als Erweiterung.
Ich habe Insider ausprobiert, aber nicht bemerkt, ob es abgestürzt ist, da es einen Tabbing-Fehler gibt. Deshalb habe ich die Verwendung eingestellt, aber ich kann es über Nacht laufen lassen, um zu versuchen, es zu wiederholen.

@ eByte23 ja bitte. Was für ein Tabbing-Bug?

@bpasero scheint in den letzten beiden Versionen von Insider mit

Ich hatte keine Gelegenheit gehabt, vollständige Tests durchzuführen, aber das werde ich jetzt tun.

@ eByte23 Ich schlage vor, Sie melden so etwas als separates Problem, wenn Sie denken, dass es eines ist. Wir haben eine neue Einstellung editor.detectIndentation die standardmäßig true . Vielleicht können Sie versuchen, es auf false .

@bpasero Mein schlechtes du bist völlig richtig, diese Einstellung auf falsch zu setzen, hat mein Problem behoben.
Ich habe Insider Yesterday über Nacht getestet und es ist auch abgestürzt.

@bpasero scheint, als ob ihr euch auf diesen einen

Wir haben viel in die Behebung von Speicherverlusten für die Version 1.0 investiert, daher würde ich erwarten, dass sich die Situation mit Version 1.0 verbessert. Aber es gibt immer noch Fälle, in denen es passiert.

Ich könnte eine neue Theorie haben, weil ich kürzlich herausgefunden habe, dass Elektronenanwendungen (unser UI-Framework) gedrosselt werden, sobald ihr Fenster entweder den Fokus verliert oder in den Hintergrund tritt. Ich frage mich, ob diese Drosselung einen Einfluss auf den Speicherverbrauch haben könnte.

Wann immer ich die Wiedergabe getestet habe, habe ich das VS-Code-Fenster mit Tastaturfokus geöffnet gelassen. Vielleicht besteht ein Unterschied darin, es im Hintergrund laufen zu lassen.

Es gibt eine Möglichkeit, die Hintergrunddrosselung zu deaktivieren, damit ich einen Build mit einem Flag erstellen kann, um dies zu aktivieren.

Ansonsten wäre es auch interessant, von Leuten zu hören, wenn ein Absturz nach dem Minimieren das typische Szenario ist.

Alle meine Abstürze ereigneten sich, als VSCode keinen Fokus hatte. Im Allgemeinen passierten sie, nachdem sie den ganzen Tag im Internet surft oder Visual Studio verwendet haben

Ich unterstütze das. Ich habe kürzlich einen Absturz erlebt. Es war mit einem VS in
Hintergrund, als ich mich den größten Teil des Tages auf das Erhabene konzentrierte.

Am Samstag, den 16. April 2016 um 11:44 Uhr schrieb Toni [email protected] :

Alle meine Abstürze ereigneten sich, als VSCode keinen Fokus hatte. Im Allgemeinen sie
passierte, nachdem ich es den ganzen Tag im Hintergrund gelassen hatte, während ich im Internet surfte
Internet oder mit Visual Studio

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/Microsoft/vscode/issues/508#issuecomment -210872544

Vor kurzem ist ein Absturz bei der Verwendung des Insider-Builds aufgetreten. War seit 2 Tagen an. Es wurde plötzlich langsam. Das Auswählen von Text mit der Maus funktioniert nicht mehr. Shift-Right funktionierte aber sehr langsam. Die App stürzte einige Minuten nach dem Fokusverlust ab.

Dies ist mein erster Absturz für den Insider-Build, aber wie für den normalen Build habe ich auf Version 1.0 aktualisiert und er stürzt nach dem Öffnen immer noch alle paar Minuten ab, wodurch er unbrauchbar wird. Ich muss nicht einmal etwas Besonderes tun. Öffnen Sie es, bearbeiten Sie eine Datei (meistens .elm-Dateien) oder lassen Sie es einfach sein und es stürzt einfach ab. Wartet nicht einmal darauf, zuerst den Fokus zu verlieren.

1.0 stürzt fast jede Nacht ab.
Windows 10 Ent.
Plugins: Rechtschreib- und Grammatikprüfung, ESLint

Ok, eine Insider-Veröffentlichung ist mit meinem Wechselgeld erschienen. Würde mich freuen, wenn jemand es versucht: http://code.visualstudio.com/Download#insiders

Jemand :)?

Verwenden Sie es jetzt. Ich habe seit gestern keinen Absturz mehr gehabt.

@bpasero Ich werde jetzt upgraden und es über Nacht laufen lassen und sehen, wie wir gehen! Prost :)

@bpasero Ich habe es Freitag installiert, bin dann aber für ein langes Wochenende

@bpasero Hatte gestern einen Absturz. Ich war 3 Tage wach, bevor ich abstürzte.

@bpasero Ich

Ich auch.
Windows 8

@bpasero Insider 1.1.0 stapelt sich besser, es dauerte fast eine Woche, bis es abstürzte.

Ich werde jetzt 1.1.0 abholen und sehen, wie es geht

Ich kann anscheinend keinen Heap-Snapshot erstellen, ohne dass dieser abstürzt, wenn die Speichernutzung über 150 MB liegt.

Jeden Morgen entsperre ich meinen Computer und stelle fest, dass VS Code über Nacht abgestürzt ist.

• Mac OS X 10.11.4 (15E65)
• VS Code 1.1.0-Insider

Ich habe normalerweise Dateien offen gelassen. Ich laufe mit Erweiterungen. Gibt es Einstellungen, mit denen ich weitere Diagnoseinformationen sammeln kann?

Unsere neue Insider-Version ist erschienen (http://code.visualstudio.com/Download#insiders) und beinhaltet unsere Arbeit für Tabs / Stacks. Dies geht mit einer aggressiveren Entsorgung von Ressourcen einher, da wir die zugrunde liegenden Ressourcen entfernen, sobald Sie einen Editor schließen.

Neugierig, ob die Leute sich für eine Weile selbst hosten und berichten könnten, wenn sich die Dinge verbessern.

Hinweis: Insider werden ab sofort jede Nacht aktualisiert (siehe http://code.visualstudio.com/blogs/2016/05/23/evolution-of-insiders).

@bpasero Ich habe heute alle meine Geräte aktualisiert. Sehen Sie, wie wir in den nächsten Tagen

Ja, ich bin hauptsächlich wegen des Terminals zu Insidern gewechselt. Oh wie viel ich
Liebe es. Ich habe festgestellt, dass der Editor viel schneller und leichter ist. Gute Arbeit.

Gibt es eine Möglichkeit, "Code" zu ersetzen? In der Befehlszeile zeigen auf
Insider?

Am Mittwoch, dem 8. Juni 2016, schrieb Elijah Bate [email protected] :

@bpasero https://github.com/bpasero Ich habe heute alle meine Geräte aktualisiert.
Sehen Sie, wie wir in den nächsten Tagen vorgehen

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/Microsoft/vscode/issues/508#issuecomment -224539214,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe/AA-JVM4KoGeXoc2SU5VeEYnxkZyPVWYMks5qJo13gaJpZM4Gnvn5
.

Immer noch am 1.2.0 für mich. Passiert jede Nacht - läuft unter Windows 7 Enterprise SP1. Ich habe die gleiche Frage wie @garthk

Ich habe normalerweise Dateien offen gelassen. Ich laufe mit Erweiterungen. Gibt es Einstellungen, mit denen ich weitere Diagnoseinformationen sammeln kann?

@northerncodemky Ich bezog mich auf die Insider-Version 1.3.0, in der unsere Tabs / Stacks enthalten sind (http://code.visualstudio.com/Download#insiders). Ich würde keine große Änderung in 1.2.0 erwarten.

@bpasero Aah ok - habe den Zeitstempel für deinen Kommentar nicht getaktet. Ich werde heute irgendwann wechseln, um zu sehen, ob dies die Dinge verbessert. Und hol dir ein paar neue Funktionen zum Booten :)

@bpasero sieht soweit gut aus !!

Ich habe VSCode Insiders Build über das Wochenende laufen lassen. Kam am Montagmorgen und sah einen Absturz.

Ich frage mich, ob es Telemetrie-Absturz- / Speicherauszugsdaten gibt, die automatisch gesendet werden, wenn VSCode abstürzt. So ähnlich wie Watson-Berichte.

Ich habe letzte Woche eine neue Maschine bekommen. Als ich es eingerichtet habe, habe ich nur den Release-Build (keine Insider) eingefügt - ich habe seitdem keinen Absturz mehr bemerkt.

@bpasero Ich habe seit 1.3 keine Abstürze mehr gesehen, unter Windows 10 Insider Build> = 14367

@bpasero mit aktivierten Registerkarten, geöffnetem ac # -Projekt und vscode stürzt einige Minuten nach dem letzten Update des Insider-Commit-Hashs ab: 5474147bb83618975409dad7d8aa96151d7d1ea1.
HINWEIS: Ich hatte bisher keine Registerkarten aktiviert

@ eByte23 Können Sie überprüfen, ob dies mit der

@bpasero tritt immer noch auf, wenn Registerkarten deaktiviert sind, aber bei aktivierten Registerkarten nicht

Ist jedoch bei der Arbeit mit Bildern stark erkennbar und reproduzierbar, da sowohl in Insider als auch in Version 1.2.1 schnell zwischen großen Bildern geklickt wird

@ eByte23 Ich schlage vor, eine neue Ausgabe zu diesem Thema mit so vielen Details wie möglich zu eröffnen (z. B. wächst der Speicher?).

Sicher kann das. Ich habe noch keine großen Nachforschungen angestellt, aber ich werde etwas später einige detaillierte Details für Sie erfahren.

VSCode 1.3.1 stürzt für mich ungefähr zweimal am Tag ab, einmal über Nacht (immer) und manchmal zufällig während des Tages. Es ist gerade abgestürzt, als ich es im Hintergrund geöffnet hatte und es ungefähr 2 Stunden lang nicht benutzt habe. Auch beim erneuten Öffnen von vscode verliert es meinen Arbeitsbereich und ich muss den Projektordner, den es vor dem Absturz geöffnet hatte, erneut öffnen. Tabulatoren und Teilungen bleiben nach dem erneuten Öffnen des Ordners erhalten.

Ich ließ eine Weile mit nicht gespeicherten Änderungen im Hintergrund offen, kam zurück, fing an zu tippen und vscode fror für ein paar Sekunden ein und stürzte dann ab. es hat meine Arbeit verloren.

Ich hoffe du kannst meine Frustration verstehen. Dies ist für einen Editor nicht akzeptabel. Auch in der wiederhergestellten Sitzung waren nicht einmal die richtigen Registerkarten geöffnet, noch mein Platz in jeder Registerkarte.

@DelvarWorld können Sie weitere Details zu Ihrer Arbeitsumgebung

Ich habe das gleiche Problem unter Linux Mint 17 Qiana (ich kann mich nicht erinnern, welche Ubuntu-Version das ist!). Es erstarrte für mich nach ~ 2 Stunden Inaktivität. Ich werde daran denken, die Speicher- / CPU-Auslastung beim nächsten Mal zu überprüfen, obwohl ich in diesem Fall noch nie eine allgemeine Verlangsamung in anderen Apps usw. bemerkt habe.

VSCode-Info:

Version 1.4.0
Commit 6276dcb0ae497766056b4c09ea75be1d76a8b679
Datum 2016-08-04T16: 49: 32.489Z
Shell 0.37.6
Renderer 49.0.2623.75
Knoten 5.10.0

Dieses Problem ist für mich behoben (unter 1.5.3, Windows 7). Wenn der letzte Kommentar vor 2 Monaten abgegeben wurde, ist dies möglicherweise behoben?

Ich habe das auch schon lange nicht mehr gesehen. Ich benutze die aktuelle Version seit Monaten. Hört sich gut an

Gleich. Scheint überhaupt nicht zu überladen.

Ok, wir sollten in einzelnen Ausgaben weitermachen und Monster-Bugs wie diesen vermeiden, die schwer zu verfolgen sind. Wenn dieses Problem immer noch auftritt, reichen Sie bitte neue Probleme mit weiteren Details ein. BITTE vermeiden Sie die Entführung eines bestehenden Problems 👍

Ich erinnere mich auch daran, dass ich das schon einmal gesehen habe und es seit Ewigkeiten nicht mehr gesehen habe. Das ist meine Bestätigung.