Vscode: Crash lors de l'exécution de nuit

Cela semble se produire régulièrement chaque nuit, je laisse l'ordinateur en marche. Il semble qu'il ne répond pas car le processeur est au maximum. Peut-être qu'une boucle infinie est quelque part, peut-être à voir avec l'interrogation de fichier ou de dépôt git?

Je me demande si le système d'exploitation décide de mettre VSCode (Electron en fait) dans un état où il provoque ce crash. J'ai demandé à Electron s'ils avaient un indice.

Cela ne s'est jamais produit sur Atom fyi, du moins sur 1.19.x (de mémoire) et 1.2.4.

J'ai un problème similaire, depuis la mise à jour de novembre (0.10.2 / 0.10.3?). Presque tous les jours, je me connectais pour trouver que mes fenêtres VSCode laissées pendant la nuit se sont toutes écrasées (avec l'erreur de plantage standard non informative / apologétique, "Visual Studio Code s'est écrasé").

Aujourd'hui, après la mise à jour 0.10.5, j'ai eu mon premier crash pendant que j'y étais - malheureusement pas pendant que je l'utilisais activement.

Exécution de VSCode sur Windows 7 (64 bits), en l'utilisant principalement comme éditeur JS sur un très grand projet - près d'un million de lignes au total (y compris les bibliothèques que j'ai besoin de rechercher, ne sont donc pas exclues). Aucun problème de performances en utilisation normale et je n'ai remarqué aucune utilisation excessive des ressources menant au crash d'aujourd'hui.

Je serais heureux de fournir des journaux / informations d'erreur plus détaillés si quelqu'un peut me les indiquer.

J'obtiens le même problème de base que

Encore des repros pour moi sur vscode 0.10.5, Ubuntu 12.04

J'ai essayé de reproduire sur Windows 10, Mac OS 10.11 et Ubuntu 15 sans chance. Je soupçonne un problème de mémoire insuffisante, mais pour aucun des éléments ci-dessus, la mémoire augmentait beaucoup.

Quelqu'un peut-il essayer de reproduire cela avec les conditions suivantes:

• se reproduit-il lors de l'ouverture d'une seule instance de code vide (Fichier | Fermer le dossier)
• se reproduit-il lors de l'ouverture d'un espace de travail mais sans ouvrir de fichier dans l'éditeur

Ubuntu 12.04, vscode 0.10.5 n'a pas pu se reproduire en le laissant pendant le week-end avec une instance vide.

Il peut bien s'agir d'une fuite de mémoire subtile, mise en évidence par l'utilisation relativement élevée de la mémoire sur ce système.

J'ai quitté l'ordinateur vers 17h30, la mémoire système augmentant lentement - il faisait 15 402 Mo à 19h00. À 3 h 09, c'était l'approche la plus proche de la limite de validation du système (17 682 Mo), et l'utilisation de la validation est passée de 16218 Mo à 15217 Mo. Je soupçonne que c'est peut-être là que VSCode s'est écrasé. L'utilisation de la validation était stable là-bas jusqu'à ce que la journalisation s'arrête vers 6 heures du matin (espace disque insuffisant - ces compteurs de performances sont gros!).

Malheureusement, je n'ai pas inclus tous les processus VSCode, donc je n'ai pas de journalisation spécifique au processus. J'essaierai ça ce soir.

Ce serait très utile si je pouvais obtenir l'heure du crash. VSCode laisse-t-il des journaux n'importe où?

Malheureusement, je n'ai pas inclus tous les processus VSCode, donc je n'ai pas de journalisation spécifique au processus. J'essaierai ça ce soir.

Ce serait super utile, merci!

Actuellement, vscode ne se connecte pas au disque.

@ Elusive138 pouvez-vous partager l'espace de travail sur lequel vous laissez vscode fonctionner?

@bpasero Malheureusement non. Il est basé sur Ext JS, cependant, et c'est là que se trouve la majorité du code (de la bibliothèque). J'essaierai un espace de travail Ext JS propre après cet autre test, et je verrai s'il y est repro.

@ Elusive138 oui serait bien d'avoir un échantillon à reproduire de notre côté.

L'un des processus code.exe (code n ° 3 dans le journal, joint) semble fuir. La validation a commencé à environ 200 Mo à 17h30 et a atteint 460 Mo à 9h00 le lendemain, avec une augmentation constante:

Le nombre de descripteurs n'augmente pas.

vscode_memleak.zip

Il n'y a pas eu de plantage cette fois, peut-être parce que je n'avais pas autant d'autres programmes gourmands en mémoire en cours d'exécution. Vous pourrez peut-être tester cela dans une machine virtuelle avec une limite de validation faible plus tard.

Ce journal a été créé pendant la nuit avec 3 grands espaces de travail ouverts dans différentes fenêtres. Je vais essayer de le réduire à un espace de travail que je peux partager.

@ Elusive138, il serait utile de comprendre les détails du processus qui fuit. Pouvez-vous trouver son PID puis imprimer ses métadonnées complètes en utilisant ps aux | grep <pid> ?

Ah, c'est peut-être sous Windows, pas sûr :)?

@bpasero La ligne de commande est:

"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

Autres détails:

L'arbre des processus:

C'est après une autre journée complète d'utilisation. Comme vous pouvez le voir, l'utilisation de la mémoire du processus semble avoir augmenté de façon linéaire pendant cette période (même espace de travail).

Ah ... ce n'est même pas le très mauvais.

4772 était le processus qui a fui du jour au lendemain. L'autre semble avoir augmenté à cause de mon utilisation pendant la journée ... je pense.

@ Elusive138 on dirait que vous avez plusieurs fenêtres ouvertes avec Code est-ce vrai?

@bpasero Oui, le test d'hier soir avait trois fenêtres ouvertes avec différents espaces de travail. Je vais l'essayer ce soir avec un seul, sur un espace de travail Ext JS propre comme mentionné ci-dessus.

Ça m'a l'air bien!

Malheureusement, pas de repro ... c'est étrange. Qu'est-ce qui pourrait causer une fuite dans ce projet spécifique?

En parlant de cela, cela pourrait être différent du problème initial de

@ Elusive138 bizarre. se reproduit-il si vous ouvrez simplement cet espace de travail sans ouvrir aucun fichier JS?

En outre, nous pouvons peut-être commencer à profiler cela à l'aide des outils de développement Chrome où vous pouvez faire des instantanés de tas. Pour cela, faites un instantané avant et après un certain temps pour voir où va cette mémoire.

@bpasero Oh, j'ai complètement oublié ces devtools. J'essaierai celui-là ce soir.

@bpasero Les instantanés de tas de Main.js , workerMain.js et workerMain.js (2) ne changent pas vraiment. Par peut-être 5 Mo au maximum.

Ajoutant plus sur ma situation, j'ai essayé de l'exécuter avec un dossier ouvert (celui qui s'est écrasé) mais aucun fichier de travail et cela ne s'est pas produit du jour au lendemain. Ainsi, cela ne se produit que lorsqu'un dossier est ouvert et que des fichiers de travail sont actifs.

@ Elusive138 nous engendrons d'autres processus qui peuvent causer la pression de la mémoire et ils

@Tyriar pouvez-vous être plus précis ce que vous entendez par là. est-ce que vous n'avez ouvert aucun fichier dans l'éditeur ou que la section des fichiers de travail est littéralement vide?

La raison pour laquelle je demande l'ouverture d'un fichier ou non est que, par exemple, le service de langage JS ne démarre qu'une fois que vous ouvrez un fichier JS. La même chose est vraie pour tout autre service linguistique. Donc, si ce problème se reproduit sans ouvrir un fichier dans l'éditeur, il est probable que la fuite de mémoire ne se trouve pas dans un service de langue mais ailleurs.

Une autre chose qui vaut la peine d'essayer: exécutez sans aucune extension pour voir si peut-être une extension fuit. Vous pouvez exécuter avec --disable-extensions pour ce faire.

@bpasero Je suis sûr que la ligne de commande fournie ci-dessus était pour 4772, celle en surbrillance (qui fuit) dans la capture d'écran. Il dit --type=renderer .

Je vais le laisser fonctionner à nouveau pendant le week-end et voir ce qui se passe. Je ne pense pas avoir fait un test propre sans que les fichiers JS ne soient encore ouverts.

@bpasero Je crois que je n'avais aucun fichier ouvert (à droite), seulement des fichiers de travail au-dessus de l'arborescence. Si je me souviens quand j'ai fini de travailler, j'essaierai de vérifier avec un fichier ouvert et de noter la langue.

Je ne sais pas avec certitude, mais ce n'était probablement pas un fichier JavaScript lorsque le mien s'est écrasé, plus probablement C ++, Java ou aucun langage. Je ne manquerai pas de vérifier.

@Tyriar s'il se reproduit uniquement en ayant quelque chose sous les fichiers de travail et avec tous les éditeurs fermés (dès le démarrage - c'est important), nous pourrions être sur quelque chose.

@bpasero Je pourrais essayer d'ouvrir un tas d'instances dans des conditions variables avant de quitter le travail vendredi et voir si je peux éliminer toutes mes expériences en une nuit. À moins que vous n'ayez des raisons de croire qu'une instance de blocage de vscode briserait toutes les autres?

@Tyriar oui totalement, si vous avez plus d'une fenêtre ouverte, tout s'ajoute à la mémoire totale utilisée et ils

• aucune extension activée via --disable-extensions (une extension qui consomme beaucoup de mémoire ou des fuites provoquerait également un crash)
• aucun fichier ouvert au démarrage (la simple fermeture d'un fichier après le démarrage est déjà trop tardive)
• pas de fichier de travail sous les fichiers de travail

btw la seule chose pour les fichiers de travail qui pourrait avoir un impact est que pour chaque fichier de travail qui ne se trouve pas dans l'espace de travail, nous installons un observateur de fichiers pour surveiller les changements. peut-être que cela cause la fuite, ce serait surprenant. De plus, nous n'installons pas d'observateur si le fichier est à l'intérieur de l'espace de travail ouvert, uniquement pour les fichiers extérieurs.

@bpasero Aucune fuite lorsqu'il n'y a pas de fichiers ouverts (?). J'essaierai l'espace de travail propre ce soir après m'être assuré d'en ouvrir quelques-uns.

J'ai essayé pendant le week-end avec la configuration suivante:

1. Lancer avec Code --disable-extensions
2. Ouvrez un fichier JavaScript d'environ 1300 lignes

La mémoire et le processeur étaient à peu près les mêmes vendredi soir et lundi matin.

@Tyriar était-ce simplement d'ouvrir un espace de travail vide avec un fichier ou d'ouvrir d'abord un dossier, puis un fichier à partir de celui-ci?

@bpasero Ouverture d'un espace de travail vide, je n'ai pas ouvert de dossier et aucun dossier n'était ouvert au lancement

OK bon à savoir. Cela semble donc être lié à l'ouverture d'un dossier (potentiellement volumineux). Reste à savoir si le simple fait d'ouvrir ce dossier est suffisant ou si l'ouverture d'un fichier ne fait que le déclencher.

@bpasero J'ai eu un grand dossier ouvert sans fichiers ouverts pendant le week-end, sans augmentation notable de l'utilisation de la mémoire. J'aurai les résultats d'un test d'ouverture de grands dossiers et fichiers avec, espérons-le, un espace de travail reproductible / partageable dans environ 7 heures.

@bpasero le dossier dans lequel j'ai connu des plantages auparavant aurait eu une capacité de 13000-14000 fichiers, cela inclut le dépôt git qui était d'environ 2000 à lui seul.

Je suppose que je vais vérifier que le crash se produit toujours dans la dernière version car cela fait un moment que je ne l'ai pas vu (en raison de tests).

Et je suppose que c'est un espace de travail JS?

@bpasero py, cpp, js, html, css

Ok, cela semble reproduire l'utilisation de la mémoire qui grimpe lentement, à une échelle plus petite: VSCodeTest.zip . J'ai eu /ext/build/ext-all-debug.js ouvert.

(Oui, c'est un 7z dans un zip ... GitHub ne me laisse pas télécharger un 7z ou un xz directement, et zip et gzip sont trop gros)

@ Elusive138 combien cela augmente-t-il pour vous en moyenne? J'ai eu l'espace de travail avec certains fichiers JS ouverts depuis 2 heures maintenant sans aucune augmentation de mémoire.

@bpasero Désolé, j'ai encore du mal à reproduire. Je pense que j'ai eu un repo git errant lors d'une tentative antérieure, qui n'était pas inclus dans l'archive ci-dessus. Je vous ferai savoir quand j'aurai des résultats plus concrets.

Ce serait vraiment utile s'il était possible d'ouvrir plusieurs instances indépendantes ... se limiter à un test par nuit est assez lent. Pensez-vous que vous portez les drapeaux Chromium pour des profils séparés?

Il est possible de créer plusieurs versions de code qui peuvent s'exécuter en parallèle, bien que nous ne l'ayons pas documenté. Si vous modifiez les valeurs dans https://github.com/Microsoft/vscode/blob/master/product.json afin qu'elles soient différentes, puis construisez à partir de la ligne de commande, vous pouvez démarrer plusieurs instances distinctes. Les identifiants qui doivent être uniques sont:

• darwinBundleIdentifier
• win32MutexName
• nomShort
• nomLong
• dataFolderName (par exemple "dataFolderName": ".oss-code-1")

Windows 8.1. Dans Code, a ouvert un dossier pour un référentiel git contenant 39 000 fichiers le matin.
Fait très peu avec lui, quelques petites modifications dans quelques fichiers.
À la fin de la journée, la taille de validation signalée par le Gestionnaire des tâches était de 672 164 Ko.
Il a augmenté régulièrement toute la journée, même lorsque je n'étais pas dans le programme.

@gushie une chance que ce repo puisse être partagé avec moi? aussi, quelle a été la mémoire initiale rapportée?

@bpasero Je suis désolé, je ne suis pas autorisé à partager le dépôt lui-même, mais s'il y a des détails à ce sujet qui pourraient aider, en excluant le contenu du fichier lui-même, faites le moi savoir. Le processus commence initialement à environ 110 Mo, passe rapidement à environ 130 Mo avant de revenir à 90 Mo. Il augmentera ensuite régulièrement à partir de ce point. (Il existe 5 autres processus code.exe qui varient de 4 Mo à 30 Mo mais ceux-ci n'augmentent pas sensiblement. Il n'y a qu'une seule fenêtre de code)

Je ne sais pas quelle était la taille finale de validation d'hier car le processus s'était écrasé lorsque j'y suis retourné aujourd'hui.

@gushie J'ai utilisé l'Analyseur de performances sur les processus code.exe pour surveiller la "Taille privée".

Plutôt ennuyeux de ne pas pouvoir partager les espaces de travail avec lesquels nous avons des problèmes! Je me demande si quelqu'un a rencontré cela avec quelque chose d'open source. Vous recherchez des similitudes: votre dépôt a-t-il déjà été utilisé avec git-svn?

@bpasero Merci, si le processus que j'ai laissé n'a pas été reproché à mon retour lundi, je pourrais essayer d'en construire quelques copies supplémentaires. Aurait besoin de savoir comment garder une trace de laquelle, cependant .. cela pourrait être un problème.

@ Elusive138 Nous utilisons les outils Atlassian, donc SourceTree se connectant à un serveur Stash privé

Ah, c'est complètement différent du mien. Était un dépôt Git local (avec extensions Git) se connectant à un serveur SVN. Mon test actuel est avec un repo git basé sur celui de vscode ... j'espère que cela reprendra et que je pourrai le partager.

@gushie se reproduit-il si vous ouvrez simplement l'espace de travail sans ouvrir aucun fichier? essayez d'abord de fermer tous les fichiers et de redémarrer pour obtenir cette configuration. si cela ne se reproduit pas, est-ce que cela se reproduit si vous ouvrez l'espace de travail et ouvrez un fichier JS et laissez-le comme ça?

@bpasero Je l'avais déjà laissé ouvert avec un seul fichier de travail non édité hier soir, et vérifier ce matin l'utilisation de la mémoire ne semble pas avoir beaucoup changé. J'ai maintenant édité et fait une compilation sur le fichier, et je vais laisser cela pour voir ce qui se passe.

Notez que jusqu'à ce que je lis ce problème, je n'avais jamais effacé les fichiers de travail. (Je n'en avais pas vraiment besoin, j'ai généralement ignoré ce panneau et changé de fichier via l'explorateur de fichiers de projet en dessous, ou avec Ctrl + E).

Crashed à nouveau, cette fois c'était après une utilisation régulière mais il est resté dans cet état:

• ~ 14000 dossiers de fichiers ouverts
• 5 fichiers de travail actifs (.cc, .java, .h, .py, .json)
• Aucun fichier ouvert dans l'éditeur de texte

ps aux sortie:

❯ 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

Comme mentionné, c'était après une utilisation régulière et pas en mode sans échec, donc cela aurait pu être dû à une extension?

J'ai laissé un seul fichier avec une petite modification ouverte, juste ce fichier dans les fichiers de travail. Sinon, intact toute la journée. La mémoire n'a pas augmenté par rapport à sa valeur initiale.

@Tyriar eh bien, le processus que vous montrez est notre service de surveillance de fichiers et sur Linux / Mac, nous utilisons Chokidar pour cela (https://github.com/paulmillr/chokidar). Cela indiquerait qu'ils ont une fuite lorsqu'ils regardent des fichiers. Y a-t-il une tâche de construction en cours d'exécution et de modification des fichiers en permanence?

@gushie était-ce sans ouvrir de dossier?

@bpasero J'ai ouvert le dossier. Il y a évidemment une action qui semble déclencher les fuites de mémoire au-delà de l'ouverture initiale d'un fichier dans le dossier. Je vais continuer à surveiller et essayer de le réduire.

@bpasero C'était le seul processus lié au vscode que je pouvais voir dans la sortie, il est possible qu'il ne soit pas visible dans la sortie car il a déjà été tué en raison d'une absence de réponse? Comme indiqué, ce processus n'utilisait que 0,5% de la mémoire et 0% du processeur. Je pense que d'après mes récentes découvertes, le problème que je rencontre n'est probablement pas dû à un service JS.

Btw même si nous ne trouvons pas la raison de cela jusqu'à la fin du mois, j'ai poussé un changement pour que la boîte de dialogue de crash que vous obtenez par défaut sélectionne une action pour rouvrir la fenêtre afin que vous puissiez continuer à travailler là où vous en étiez. C'est également bon dans le cas où vous avez plusieurs fenêtres ouvertes et qu'une seule d'entre elles se bloque.

(une chose qui manque et pour l'avenir est de pouvoir vider périodiquement l'état de l'interface utilisateur sur le disque afin que la réouverture restaure également votre environnement de travail précédent)

@bpasero : +1: ce serait utile.

VS plante tous les matins depuis environ un mois maintenant. J'arrive au bout de ma patience.

J'espère que cela est traité comme un bogue PRI 0 car un éditeur sensé ne devrait pas planter aussi souvent.

S'il vous plaît laissez-moi savoir comment je peux obtenir une trace de pourquoi cela se produit. J'ai vu cela se produire sur d'autres machines également.

@nojvek pouvez-vous partager avec moi l'espace de travail où cela se produit?

Je ne sais pas ce que vous entendez par espace de travail partagé. C'est un projet dactylographié / HTML / CSS avec un peu de C ++. Environ 1 500 fichiers et 80 000 lignes de code.

Existe-t-il un moyen dans VS d'afficher les crashdumps?

@nojvek Je voudrais avoir un espace de travail avec lequel je peux exécuter Code pour reproduire ce problème. Nous soupçonnons que cela est lié à une fuite de mémoire quelque part, on ne sait tout simplement pas où. Si vous pouvez m'envoyer un zip de l'espace de travail ou peut-être l'URL git si elle est open source.

Benjamin,

Son code source interne de Microsoft et je ne pense pas pouvoir vous le donner.

S'il y a un outil de surveillance de la mémoire que je peux ajouter, faites-le moi savoir.

Cela fonctionnerait-il si je prenais des instantanés de la mémoire avec le débogueur Chrome intégré
dans vscode toutes les deux heures pour voir ce qui se passe?

Le samedi 23 janvier 2016, Benjamin Pasero [email protected]
a écrit:

@nojvek https://github.com/nojvek J'aimerais avoir un espace de travail qui
Je peux exécuter Code avec pour reproduire ce problème. Nous soupçonnons qu'il est lié à un
fuite de mémoire quelque part, on ne sait tout simplement pas où. Si tu peux m'envoyer un zip
de l'espace de travail ou peut-être l'URL git si elle est open source.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -174192367.

Oui, les instantanés de mémoire aideront si et seulement si cette fuite se trouve à l'intérieur du côté principal de VS Code. Cependant, il semble qu'au moins dans un cas, la fuite provienne de l'un des processus que nous générons (l'observateur de fichiers). Vous pourriez peut-être identifier en utilisant l'explorateur de processus, quel processus augmente constamment en termes de consommation de mémoire.

Si cela aide à me fournir le code source: je travaille pour Microsoft;)

Je vais avoir un mot avec mon manager. Ceci est dans le dépôt Windows donc je vais devoir
soyez un peu prudent.

D'après le fil, il semble que le chokidar soit utilisé pour l'observateur de fichiers. Quelque temps
retour j'ai joué avec le code source. C'était un peu de spaghetti.

Je vais voir si je peux charger chokidar sur sa propre application de nœud simple et voir si c'est
le coupable.

Btw des raisons spécifiques pour lesquelles vs doit utiliser Chokidar? Il y a d'autres
observateurs de fichiers multi-plateforme, non?

Le dimanche 24 janvier 2016, Benjamin Pasero [email protected]
a écrit:

Oui, les instantanés de la mémoire aideront si et seulement si cette fuite est à l'intérieur du
côté de VS Code. Cependant, il semble qu'au moins dans un cas, la fuite ait été
dans l'un des processus que nous générons (l'observateur de fichiers). Peut-être que tu pourrais
identifier à l'aide de l'explorateur de processus, quel processus augmente constamment
termes de consommation de mémoire.

Si cela aide à me fournir le code source: je travaille pour Microsoft;)

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -174269028.

Chokidar est utilisé sur Mac et Linux, si vous êtes sous Windows, nous utilisons un observateur de fichiers C #. Je suis heureux d'accepter un PR avec une solution de cross file watcher efficace et performante :)

Vous savez qu'à partir du nœud 4.0, la fs.watch est stabilisée sur Windows et Mac. Voir: https://github.com/Microsoft/TypeScript/issues/4643.

Typescript a une logique de surveillance de fichiers / répertoires multiplateforme assez solide. https://github.com/Microsoft/TypeScript/blob/931d162620c7e09377c12875834e1838c4cdd51b/src/compiler/sys.ts

Je vais essayer d'obtenir une version locale du code VS avec une modification et voir si elle plante toujours. Si ce n'est pas le cas, j'enverrai certainement un PR.

Je sais que cela s'est beaucoup amélioré en utilisant l'appel de surveillance récursif sur le répertoire et en évitant ainsi d'avoir à attacher un écouteur de surveillance par dossier, mais je pense que les événements manquent encore parfois le nom du fichier / dossier, du moins dans certains cas. Je me sens plus confi en utilisant C # ici.

J'ai réussi à obtenir un repro aujourd'hui. Je me suis juste écrasé avant de lancer la console des outils de développement pour prendre un instantané de la mémoire.

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

Il semble que le serveur dactylographié prend environ 200 Mo.
Le moteur de rendu a consommé environ 800 Mo, puis s'est écrasé.

Lorsque j'obtiens environ 500 Mo d'utilisation, j'essaierai de prendre un instantané de la mémoire. Le processus --renderer est le processus Webkit correct?

C'était après deux jours depuis que j'ai vu un accident pour la dernière fois. Il semble que l'utilisation de l'outil pendant une période de 8 heures en modifiant de nombreux fichiers TS contribue à une utilisation plus rapide.

Bien, le processus de rendu est le processus principal de l'éditeur. Si vous pouvez y faire un instantané de la mémoire, cela nous amènera plus loin. Malheureusement, l'instantané ne fonctionnera pour aucun des autres processus, mais ceux-ci semblent corrects.

Est-il normal que tscse (serveur de typescript) consomme 200 Mo?

Le mar 26 janvier 2016 à 21:29, Benjamin Pasero [email protected]
a écrit:

Bien, le processus de rendu est le processus principal de l'éditeur. Si vous
peut faire un instantané de la mémoire là-bas, cela nous amènerait plus loin. Malheureusement, le
snapshot ne fonctionnerait pour aucun des autres processus, mais ceux-ci semblent
être ok'ish.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -175408302.

Ouais, très facilement.

Lol! J'étais en train de prendre un instantané du tas et VS s'est écrasé.

Je vais réessayer et voir si j'ai plus de chance demain.

Existe-t-il un moyen de dire à vscode d'augmenter sa limite de mémoire afin qu'il ne plante pas en essayant de prendre un instantané de tas?

Je pense que ce qui se passe, c'est que la prise de l'instantané vous a causé une exception de mémoire insuffisante: - /. Il n'y a aucun moyen de changer la limite de mémoire, elle est codée en dur en V8.

Peut-être essayer de prendre l'instantané un peu plus tôt, avant que l'utilisation de la mémoire ne devienne si élevée? S'agit-il d'une augmentation graduelle?

Je n'ai pas pu reproduire (pas de plantages, utilisation raisonnable de la mémoire) depuis environ deux semaines. La seule différence à laquelle je peux penser est la mise à jour de l'extension PowerShell de 0.1.0 à 0.3.1 - mais je n'ai de toute façon aucun fichier PS dans l'espace de travail, et il s'est écrasé avec les extensions désactivées à l'époque.

J'ai obtenu un vidage réussi d'environ 300 Mo utilisé par le processus --renderer. Il s'est écrasé 10 secondes après avoir pris la décharge.

Il semble que l'essentiel de l'utilisation se trouve dans l'arborescence DOM.

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

J'espère que cela t'aides.

Hmmmm, je me demande si le profileur dit la vraie vérité ici. Je vois tous les éléments de l'arbre et nous pourrions tout aussi bien avoir une fuite dans l'arbre, mais je serais surpris que cette fuite puisse provoquer une perte de mémoire en si peu de temps.

J'ai pris quelques décharges supplémentaires.

Il semble que l'ouverture de fichiers .min.js provoque un énorme saut de mémoire. Même après la fermeture des fichiers, la mémoire ne semble pas s'épuiser. Entre tous les vidages de mémoire, il semble que DOM soit le dominateur.

Je ne sais pas non plus pourquoi il y avait deux processus de rendu. Peut-être que l'un d'entre eux était les outils de développement de chrome. Mais je suis devenu très proche de 1 concert.

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

J'ai pris une capture d'écran des deux processus consommant ~ 500 Mo de RAM.

Oui, l'un est devtools. On s'attend à ce que la mémoire augmente lorsque vous ouvrez des fichiers. Mais j'aimerais comprendre comment un code VS qui fonctionne pendant la nuit sans activité augmente l'utilisation de la mémoire jusqu'à ce qu'il se bloque.

Eh bien le repro est:
Commencez par rapport au code.
Ouvrez un ou deux fichiers js / ts dans un grand dossier contenant de nombreux fichiers .tsconfig.
Faites un peu de défilement / d'édition.
Fermez tous les fichiers de travail.
Mettez-le dans le même à 200 ° C pendant la nuit.
Gâteau!

Le vendredi 29 janvier 2016, Benjamin Pasero [email protected]
a écrit:

Oui, l'un est devtools. Il est prévu que la mémoire augmente lorsque vous ouvrez
des dossiers. Mais j'aimerais comprendre comment un VS Code qui roule
la nuit sans activité augmente l'utilisation de la mémoire jusqu'à ce qu'elle plante.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -177087988.

@nojvek Les .tsconfig sont-ils nécessaires pour la repro? parce que j'ai eu des plantages dans le passé sans rien lié à TS du tout. Bien que je ne puisse même plus les reproduire ...

Notre projet les a tout simplement. Cela pourrait être un hareng rouge.

Le samedi 30 janvier 2016, Bob [email protected] a écrit:

@nojvek https://github.com/nojvek Les .tsconfigs sont-ils nécessaires pour
repro? parce que j'ai eu des plantages dans le passé sans rien lié à TS à
tout. Bien que je ne puisse même plus les reproduire ...

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -177198518.

Les seuls fichiers. * Que nous avons dans notre dossier sont le dossier .git et .gitignore

@nojvek utilisez-vous un serveur dactylographié personnalisé avec le projet, ou le TS prêt à l'emploi que nous expédions en 0.10.6? Celui que nous livrons dans la version 0.10.6 est TypeScript 1.7.5

@bpasero @nojvek s'il s'agit d'un problème de mémoire côté JS. Vous pouvez comparer le cliché instantané du tas sur Chrome.

1. Prenez un instantané.
2. Effectuez l'action qui provoque une fuite de mémoire.
3. Forcer le garbage collection. Sinon, le prochain instantané de tas inclura les objets.
4. Prenez un autre instantané.
5. Différez les deux instantanés.

Tout peut être fait avec dans Chrome Devtools ci-dessus. La force du ramasse-miettes est dans l'onglet chronologie, l'icône de la poubelle. Et la différence se fait en le choisissant simplement dans l'explorateur d'instantanés dans le menu des filtres.

Indiquez simplement quels objets sont conservés et les chemins de conservation possibles (juste en dessous de la table de tas). Et ce sont toutes les données nécessaires pour résoudre ce problème.

Pas besoin d'attendre une journée entière pour collecter des données sur un crash: wink:

Le lien Dropbox que j'ai envoyé avait trois instantanés de chaleur pris à une demi-heure d'intervalle.
Je n'ai pas fait la collecte forcée des ordures. Je vais donner un truc.

Le dimanche 31 janvier 2016, Tingan Ho [email protected] a écrit:

@bpasero https://github.com/bpasero @nojvek https://github.com/nojvek
s'il s'agit d'un problème de mémoire côté JS. Vous pouvez modifier le cliché du tas sur
Chrome.

1. Prenez un instantané.
2. Effectuez l'action qui provoque une fuite de mémoire.
3. Forcer le garbage collection. Sinon, le prochain instantané de tas
   inclure les objets.
4. Prenez un autre instantané.
5. Différez les deux instantanés.

Tout peut être fait avec dans Chrome Devtools ci-dessus. La force des ordures
collection est dans l'onglet chronologie, l'icône de la poubelle. Et la différence est
fait en le choisissant simplement dans l'explorateur d'instantanés dans le menu des filtres.

Indiquez simplement quels objets sont conservés et les chemins de conservation possibles (juste en dessous
la table de tas). Et ce sont toutes les données nécessaires pour résoudre ce problème.

Pas besoin d'attendre une journée entière pour collecter des données sur un plantage [image:
:clin d'œil:]

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -177462412.

J'ai le même problème, VS Code plante constamment, pas seulement pendant la nuit, même après 30 minutes d'inactivité.
J'utilise Windows 7, 64 bits et la dernière version de VS Code. En ce qui concerne le projet lui-même, c'est un énorme projet js, avec node_modules et bower_components également chargés. Au total, il contient environ 40 Ko de fichiers.

Étapes à suivre pour reproduire:
1) Ouvrez le dossier du projet (avec beaucoup de fichiers), ouvrez plusieurs fichiers afin qu'ils puissent être dans la liste des fichiers de travail.
2) Ouvrez le gestionnaire de tâches.
3) Placez le curseur pour concentrer un fichier dans VS Code
4) Regardez comme la mémoire monte pendant le temps.

Les personnes avec des espaces de travail JS qui voient ce problème peuvent-elles essayer notre version 0.10.7 initiés (https://vscode-builds.azurewebsites.net/insider) avec la possibilité d'utiliser Salsa comme service de langage JS: https://github.com /Microsoft/vscode-docs/blob/vnext/release-notes/latest.md#javascript --- salsa-preview

Merci!

+1 pour ce numéro. Apparaît également sur Windows. C'est totalement ennuyeux et je n'aime pas ça.

@bpasero Je voudrais essayer la nouvelle version, mais chaque fois que j'essaye d'accéder au lien que vous avez fourni (https://vscode-builds.azurewebsites.net/insider), j'obtiens une page de message d'erreur très inutile avec le texte suivant :

Se connecter
Désolé, mais nous rencontrons des difficultés pour vous connecter.
Nous avons reçu une mauvaise demande.

Informations techniques supplémentaires:
ID de corrélation: e477dc1b-c193-4cf9-864b-1d3fdbba4f34
Horodatage: 2016-02-03 19: 37: 17Z
AADSTS50020: Le compte utilisateur ' [email protected] ' du fournisseur d'identité ' https://sts.windows.net/5a7d8144-6966-4b1e-8147-de672a307ea0/ ' n'existe pas dans le locataire 'Microsoft' et ne peut pas accéder à l'application ' 9d5f02f6-ffd9-4e80-92d5-e42c85e09bc9 'dans ce locataire. Le compte doit d'abord être ajouté en tant qu'utilisateur externe dans le client. Déconnectez-vous et reconnectez-vous avec un autre compte d'utilisateur Azure Active Directory.

Je ne parviens pas à télécharger la version et à l'essayer à cause de ce problème.

Ah désolé, mauvais lien, veuillez utiliser https://code.visualstudio.com/insiders

@bpasero merci J'ai les initiés construits avec Salsa comme service de langage JS. Je vous ferai savoir comment ça se passera le lendemain ou deux

@bpasero , j'ai essayé la publication d'initiés et le problème existe toujours, après une nuit d'inactivité, VS Code s'est écrasé.

@milenkovic @gwynjudd, vous devrez également suivre les étapes pour activer Salsa comme indiqué dans https://github.com/Microsoft/vscode-docs/blob/vnext/release-notes/latest.md#javascript --- salsa- Aperçu

@bpasero , vous aviez raison, activer Salsa a résolu le problème. J'ai laissé VS Code ouvert pendant le week-end et il ne s'est toujours pas écrasé.

Bien d'entendre ça! Ce serait intéressant si d'autres pouvaient vérifier cela aussi en essayant.

@bpasero J'avais activé la salsa et je l'ai laissée fonctionner pendant le week-end. Ce matin, il s'était écrasé.

Typographie installée

$ 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

J'ai défini settings.json pour être

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

et l'environnement

$ setx VSCODE_TSJS 1

SUCCESS: Specified value was saved.

Je ne vois toujours pas de salsa dans le pied de page de VS code insider.

@nojvek J'ai fait essentiellement ce que vous avez fait, et je vois Salsa dans le pied de page, mais uniquement lorsqu'un fichier .js est ouvert et visible dans l'éditeur

@gwynjudd Je suppose que vous avez obtenu la boîte de dialogue de crash et que maintenant, avec 0.10.8 out, avez pu rouvrir la fenêtre?

@bpasero oui j'ai eu la nouvelle boîte de dialogue de crash et j'ai pu redémarrer

Gwyn Judd

-------- Message d'origine --------
De: Benjamin Pasero
Date: 09/02/2016 19:13 (GMT + 12: 00)
À: Microsoft / vscode
Cc: Gwyn Judd
Objet: Re: [vscode] Crash lors de l'exécution pendant la nuit (# 508)

@gwyn juddhttps: //github.com/gwynjudd Je suppose que vous avez eu la boîte de dialogue de crash et que maintenant, avec 0.10.8 out, avez pu rouvrir la fenêtre?

Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps: //github.com/Microsoft/vscode/issues/508#issuecomment -181726111.

@gwynjudd est-ce un espace de travail JS uniquement ou d'autres types de fichiers comme PHP inclus?

@bpasero il existe de nombreux types de fichiers, notamment dactylographiés, java script, css, less, aspx, cs

Gwyn Judd

-------- Message d'origine --------
De: Benjamin Pasero
Date: 09/02/2016 22:49 (GMT + 12: 00)
À: Microsoft / vscode
Cc: Gwyn Judd
Objet: Re: [vscode] Crash lors de l'exécution pendant la nuit (# 508)

@gwyn juddhttps: //github.com/gwynjudd est-ce un espace de travail JS uniquement ou d'autres types de fichiers comme PHP inclus?

Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps: //github.com/Microsoft/vscode/issues/508#issuecomment -181786273.

Avec la nouvelle version, il s'est écrasé chaque matin en le laissant fonctionner pendant la nuit. Je n'ai installé que ces extensions (dans la nouvelle version, dans la version de version, j'avais différentes extensions):

Ce matin, quand je suis entré au travail, il ne s'était pas écrasé. Je n'ai rien fait de différent avant de quitter le travail vendredi.

Devrait essayer de se reproduire avec l'espace de travail Chromium en utilisant Ubuntu car il semble que @Tyriar avait une configuration comme celle-là quand cela s'est produit.

Suivez les instructions ici pour obtenir le code https://www.chromium.org/developers/how-tos/get-the-code

J'ai également remarqué un décalage dans Code après un certain temps d'utilisation, et des plantages éventuels. J'ai remarqué que lorsqu'il est lent, je peux le faire fonctionner plus facilement si j'appuie sur F1 et que je tape «Recharger la fenêtre». Cela semble éclaircir le problème pour le moment et je suis alors en mesure de le contourner pour le moment. Je suis vraiment intéressé de voir cela corrigé.

En lisant ce fil, je suppose également que cela est dû au processus de rendu, bien que je n'ai pas fait de test avec lui, et cela semble se produire quelle que soit la quantité de fichiers de travail dans la liste dans le panneau de l'explorateur, que ce soit ou pas un fichier est ouvert lorsque le code est chargé, peut-être la taille des fichiers en cours de travail, et je ne suis pas sûr si cela a quelque chose à voir avec le vérificateur git diff ou non, mais je doute que ce soit le coupable .

Je suis également sur Mac OS X El Capitan 10.11.3 et je n'avais pas vraiment vu le problème sous Windows lorsque je l'ai utilisé à la maison, mais je n'ai pas d'arborescence de travail énorme pour les projets à la maison, seulement le dossier massif sur lequel je travaille au travail.

J'espère que les deux problèmes sont liés, mais je crains qu'ils ne le soient pas: la plupart des gens ici voient le code se bloquer en le laissant fonctionner sans aucune interaction de l'utilisateur, ce qui semble très suspect. Faire en sorte que Code se bloque éventuellement avec une exception de mémoire insuffisante lors de son utilisation pendant une longue période peut être provoqué par d'autres fuites de mémoire. Idéalement, les deux problèmes sont les mêmes :)

Techniquement, il semble ralentir et planter même si je ne l'utilise pas aussi, mais je ne suis pas sûr qu'ils éprouvent également la même chose, dans ce cas. Quoi qu'il en soit, les symptômes semblent au moins similaires. S'il s'avère que mon problème n'est pas lié, je pourrais créer un problème distinct à la place.

@cwadrupldijjit si vous voyez le problème de plantage pendant la nuit, il serait utile d'avoir accès à l'espace de travail si possible.

Je vais voir ce que je peux faire. Je mets généralement le mac en veille la nuit, donc rien ne se passe pendant cette période. J'essaierai de le garder la nuit et je vous préviendrai le matin si quelque chose se passe. Je vous tiendrai également informé si vous pouvez accéder à mon espace de travail.

Ça sonne bien, merci!

K. J'ai donc laissé l'instance de code s'exécuter pendant la nuit, et je n'ai pas eu de problème avec le crash ou la sensation de retard. J'ai continué à travailler aujourd'hui, et j'ai même pris une petite pause pour ne pas l'utiliser tout en faisant d'autres choses, et il a recommencé à être lent. Il semble presque que le problème ne vient peut-être pas de son utilisation active, mais cela ressemble aussi à quelque chose d'autre l'a déclenché pendant le temps où je travaille dessus.

Je vais exécuter le profileur pour garder mon œil dessus, et je vais créer un nouveau problème s'il y a d'autres résultats différents de ceux expliqués ci-dessus.

Je n'ai pas vérifié si vous pouvez avoir accès à mon espace de travail, bien que je soupçonne que je ne peux pas partager cela avec vous, malheureusement.

J'ai essayé d'exécuter le profileur hier alors qu'il devenait particulièrement lent et lorsque je prenais un instantané de tas, l'ordinateur était au maximum de la RAM disponible et je ne pouvais presque rien faire du tout, même pas forcer la fermeture du code, j'ai donc dû redémarrer l'ordinateur. J'essaierai de l'exécuter plus tôt qu'avant pour éviter que cela ne se reproduise.

C'est un peu hors sujet, mais vous avez publié le lien pour la construction d'initiés, que j'ai visitée. Je voulais télécharger la version Windows (comme je l'utilise à la maison), et chaque fois que j'essaie d'accéder à ce lien, il redirige d'abord vers la page de téléchargement habituelle, mais me redirige ensuite rapidement vers la page principale sans lancer de téléchargement. En fait, cela écrase l'historique de la page de téléchargement sur laquelle j'étais, donc je ne peux même pas revenir en arrière pour y accéder. Y a-t-il un autre moyen pour que les initiés se construisent?

@cwadrupldijjit

C'est un peu hors sujet, mais vous avez publié le lien pour la construction d'initiés, que j'ai visitée. Je voulais télécharger la version Windows (comme je l'utilise à la maison), et chaque fois que j'essaie d'accéder à ce lien, il redirige d'abord vers la page de téléchargement habituelle, mais me redirige ensuite rapidement vers la page principale sans lancer de téléchargement.

Désolé pour cela, mais certains utilisateurs ont signalé un problème étrange sur la version des initiés et nous l'avons temporairement supprimé jusqu'à ce que nous comprenions ce problème.

@egamma Je me suis demandé si cela aurait pu être inaccessible à cause de cela. Je vais garder un œil sur quand ça marche, alors.

@Tyriar J'ai essayé l'espace de travail chrome pendant la nuit sous Linux, Windows et Mac et je

Je ne sais pas si cela est lié, mais j'ai remarqué que VS Code a tendance à planter pendant ma journée de travail si je l'ouvre et l'oublie pendant un certain temps. Je suis au travail pendant 11 heures et j'ouvre généralement le code tôt le matin. À un moment de la journée, mon ordinateur ralentira et commencera à se bloquer jusqu'à ce qu'il plante ou que je le tue de force.

Juste au cas où cela pourrait aider ...

Le projet principal que j'ai ouvert dans VS Code est une version relativement non modifiée d'un panier appelé BVCart (version 2004.7). J'ai environ 25-30 fichiers de travail en ce moment et même le simple fait d'ouvrir VS Code et de ne pas le toucher toute la journée entraîne un crash.

Le projet comprend 1836 fichiers et 130 dossiers totalisant environ 35 Mo et il est contenu dans un petit référentiel git.

@ZombieProtectionAgency est-il possible de partager cet espace de travail avec moi?

@bpasero Désolé, je n'ai vraiment pas pu le partager: (Je n'ai pas cherché, mais vous pourrez peut-être le trouver en ligne quelque part. Il s'agit simplement d'un panier d'achat ASP VB.Net à l'ancienne. La grande majorité des les fichiers sont .vb avec aspx, ascx et une petite poignée de fichiers css.

J'ai exactement la même erreur. VS Code plante toutes les quelques minutes. Je l'utilise avec l'orme. Il ne se heurte pas lorsqu'il est laissé allumé. Il se heurte quelques minutes après avoir commencé à terminer le fichier. C'est comme ça depuis trois jours, rendant VS Code inutilisable. Comment vérifier ce qui se passe? J'utilise la version 0.10.10.

Une autre pensée que j'ai eue: nous avons un service qui peut recevoir la sortie de divers points de terminaison (git, tâches, extensions) et c'est quelque chose qui peut se produire en arrière-plan et s'additionner. Nous avons fait pas mal de correctifs dans ce domaine pour GA qui ne figurent pas dans les versions précédentes.

Si quelqu'un avec des plantages pendant la nuit pouvait simplement vérifier brièvement s'il y a une sortie enregistrée en arrière-plan? Vous pouvez le voir à partir de Affichage> Basculer la sortie, puis en passant par les canaux dans la liste déroulante.

@bpasero
Dans la sortie "Tâches", je vois simplement la sortie que j'attendrais de ma propre tâche de compilation.
Dans la sortie 'Git', je vois pas mal de git fetch, entrecoupés de quelques git show. Je ne sais pas à quelle fréquence car il n'y a pas d'horodatage. Aucune autre sortie cependant.

Nous effectuons une récupération automatique de temps en temps, mais le résultat principal que vous voyez provient probablement du travail que vous effectuez dans VS Code. Ce serait intéressant si la sortie s'additionne lorsque VS Code est en arrière-plan. La tâche s'exécute-t-elle constamment ou uniquement lorsque vous appelez explicitement la tâche de compilation?

La tâche est juste quand je ctrl + shift + B et se termine peu de temps après. J'ai eu des plantages cependant lorsque je n'ai pas exécuté de tâche.

J'obtiens deux émissions git identiques lorsque je passe d'un fichier à l'autre et oui, la récupération git se produit automatiquement une fois toutes les deux minutes.

Notez que je ne fais aucune extraction, etc. dans VSCode, j'utilise SourceTree pour toutes les tâches liées à git.

@bpasero Je vais laisser la fenêtre de sortie

Notre dernière version d'initiés est sortie et j'apprécierais que les gens puissent l'essayer sur ce problème: https://code.visualstudio.com/insiders

@bpasero J'avais toujours la version précédente des initiés, puis-je simplement l'exécuter et faire "vérifier les mises à jour", ou dois-je mettre à jour la version à partir du lien que vous avez donné?

Je vais essayer de vous répondre. Pour être honnête, je vois moins de VSCode
plante de nos jours. Au moins, il ne plante pas tous les jours.

Je peux le faire planter en ouvrant un énorme fichier avec plus de millions de lignes
js minifié et défilement de haut en bas à plusieurs reprises. Mais je sais ce que c'est
repoussant les limites de l'éditeur.

Tout ce que vous avez ajouté comme sauce magique fonctionne pour moi.

Le mer 16 mars 2016 à 12 h 29, Benjamin Pasero [email protected]
a écrit:

Notre dernière version d'initiés est sortie et j'apprécierais que les gens puissent
essayez-le sur ce problème: https://code.visualstudio.com/insiders

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -197503185

@gwynjudd, vous devriez pouvoir mettre à jour si le logo VS Code apparaît sous forme de logo vert:

@nojvek oui cela repousse un peu les limites. pour la version de mars, nous avons fait des tests de mémoire explicites pour trouver des domaines où nous pouvons nous améliorer. la compilation des initiés inclut certains de ces correctifs (pas tous, nous avons fait des changements hier et aujourd'hui qui ne sont pas encore entrés). si simplement curieux de savoir si cela fait une différence pour les personnes qui voient cela ...

@bpasero merci d'avoir fait ça et je vous ferai savoir comment ça se passe

@bpasero a toujours eu le même crash du jour au lendemain avec la build des initiés de mars. Voulez-vous que j'essaye d'obtenir un vidage de tas des outils de développement pendant une utilisation normale? Je peux essayer de garder un œil sur l'utilisation de la mémoire pour le code et récupérer un vidage s'il semble augmenter

Oui, merci.

Voici un instantané du tas immédiatement après le lancement du code (utilisation de la mémoire d'environ 100 Mo à ce moment-là)

Heap-20160318T115937.zip

Je vais réessayer dans une heure ou deux. Le plus délicat semble être de l'obtenir à un point où la mémoire a quelque peu augmenté, mais pas au point que la prise de l'instantané le déclenche une panne de mémoire.

J'ai vu le même genre de résultats lorsque j'ai essayé de prendre un instantané de tas (à court de mémoire), et ce n'est pas amusant.

J'ai l'impression qu'il y a encore des problèmes de mémoire dans la dernière version d'initiés (pour mac). Je vais voir si je peux obtenir un autre instantané de tas sans sacrifier mon ordinateur.

@bpasero désolé, je n'ai pas encore réussi à obtenir un instantané du tas. Soit la mémoire est très faible, comme pour celle que j'ai capturée avant, soit elle saute pour dire environ 500 Mo ou plus et la capture de l'instantané déclenche un crash.

Je dois redémarrer vscode 1 à 2 fois par jour car l'utilisation de la mémoire augmente de plus de 1 Go et les choses commencent à se sentir léthargiques. Il utilise la quantité de mémoire qu'un IDE complet ferait, donc il y a certainement une fuite en cours.

@ vincent-ly pouvez-vous partager plus de détails sur l'espace de travail avec lequel vous voyez cela?

@bpasero Il y a environ 30 à 40 fichiers js / scss / html qui utilisent quelques composants bower avec gulp (sans le lanceur de tâches vscode). Je travaille avec 2 volets d'éditeur et utilise fréquemment la recherche de fichiers, assez standard. L'utilisation de la mémoire est inférieure à 100 Mo au démarrage, mais augmente avec le temps, même lorsqu'elle est réduite.

Intellisense joue-t-il un rôle? J'ai installé des définitions de type Angular et jQuery.

Vous pouvez essayer notre build d'initié où nous avons travaillé sur la réduction de la pression mémoire pour voir si cela l'améliore: http://code.visualstudio.com/download?insiders=true

Avez-vous des extensions installées?

@bpasero Juste des extraits angulaires
https://marketplace.visualstudio.com/items?itemName=johnpapa.Angular1

Je vais essayer la compilation d'initié et faire un rapport, merci!

+1

Voir le même problème sur VSCode pour Windows 0.10.11 . Il plante généralement tous les soirs lorsqu'il n'est pas utilisé. Compte tenu des étapes pour collecter des informations, je serais heureux de vous aider.

Exécution sur un référentiel git TypeScript avec 28 438 fichiers, 4 812 dossiers. A également des observateurs de gulp, avec de nombreuses défs TypeSript.

J'ai les extensions suivantes installées:

• PowerShell
• C #
• Kit de thème matériel

@alanwright pourriez-vous essayer s'il se reproduit toujours avec notre dernière version d'initié (http://code.visualstudio.com/Download#insiders). Si oui, pouvez-vous partager l'espace de travail avec moi?

@bpasero Il s'est reproduit pendant la nuit avec un build d'initié. J'ai essayé à la fois notre enrôlement privé plus large et notre enrôlement open source, et seul l'enrôlement privé plus large semblait causer le problème, que je ne peux malheureusement pas partager (il est interne à Microsoft, donc peut-être que nous pouvons vous y accéder? alanwri)

Puis-je faire quelque chose sur ma machine pour capturer les journaux et les partager avec vous?

Veuillez partager avec moi sur mon alias benjpas, merci! J'apprécierais également quelques détails sur la façon dont vous utilisez VS Code sur cet espace de travail pour provoquer l'augmentation de la mémoire.

Je m'écrase aussi pendant la nuit et pendant la journée.

Cela ne semble pas être particulièrement lié à un espace de travail, à des espaces de travail extrêmement petits 3 à 20 fichiers ou à d'énormes espaces de travail, principalement remarqués lors de l'ouverture de plusieurs fenêtres.

Repos je l'ai utilisé qui s'est écrasé.
Plus de 1500 fichiers asp, js, .inc (asp)
70 + fichiers asp.net core, js, cshtml
Ce dépôt (https://github.com/gogits/gogs)

@ eByte23 exécutez -vous avec ou sans extensions? sur quelle plateforme êtes-vous? avez-vous essayé avec la libération d'initiés?

@bpasero Win10 & OSX avec C # comme extension.
J'ai essayé des initiés mais je n'ai pas noté s'il tombait en panne car il y avait un bug de tabulation, j'ai donc arrêté de l'utiliser mais je peux le laisser fonctionner toute la nuit pour essayer de le reproduire.

@ eByte23 oui s'il vous plaît. quel bug de tabulation?

@bpasero semble être dans les deux dernières versions d'initié avec des espaces d'affichage et de conversion des onglets en espace blanc avec un fichier avec des onglets existants, il semble continuer à tabuler et ne pas écrire d'espaces même sur les nouvelles lignes.

Je n'avais pas eu l'occasion de faire des tests complets mais je vais le faire maintenant.

@ eByte23 Je vous suggère de signaler quelque chose comme ça comme un problème distinct si vous pensez qu'il en est un. nous avons introduit un nouveau paramètre editor.detectIndentation qui vaut par défaut true . Vous pouvez peut-être essayer de le définir sur false .

@bpasero Ma
J'ai testé Insider Hier pendant la nuit et il s'est également écrasé.

@bpasero semble que vous êtes peut-être en train de

Nous avons beaucoup investi dans la correction des fuites de mémoire pour la version 1.0, donc je m'attendrais à ce que la situation soit meilleure avec 1.0. Mais il y a encore des cas où cela se produit.

Je pourrais avoir une nouvelle théorie parce que j'ai récemment découvert que les applications Electron (notre cadre d'interface utilisateur) sont étranglées dès que leur fenêtre perd le focus ou passe à l'arrière-plan. Je me demande si cette limitation pourrait avoir un impact sur la consommation de mémoire.

Chaque fois que j'ai testé pour reproduire, j'ai laissé la fenêtre VS Code ouverte avec le focus clavier, donc peut-être une différence est de la laisser fonctionner en arrière-plan.

Il existe un moyen de désactiver la limitation en arrière-plan afin que je puisse produire une construction avec un indicateur pour l'activer.

Sinon, il serait également intéressant d'entendre des gens si un crash après minimisation est le scénario typique.

Tous mes plantages se sont produits lorsque VSCode n'avait pas le focus. En général, ils se sont produits après l'avoir laissé en arrière-plan toute la journée en naviguant sur Internet ou en utilisant Visual Studio

J'appuie cela. J'ai récemment subi un accident. C'était avec un VS en
fond quand je me suis concentré sur le sublime pendant la majeure partie de la journée.

Le samedi 16 avril 2016 à 11h44, Toni [email protected] a écrit:

Tous mes plantages se sont produits lorsque VSCode n'avait pas le focus. Généralement ils
s'est produit après l'avoir laissé en arrière-plan toute la journée en parcourant le
Internet ou en utilisant Visual Studio

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -210872544

J'ai rencontré un crash lors de l'utilisation de la version d'initié il n'y a pas longtemps. Avait été pendant 2 jours. C'est devenu soudainement lent. La sélection de texte avec la souris a cessé de fonctionner. Shift-Right a fonctionné mais très lentement. L'application s'est plantée quelques minutes après avoir perdu le focus.

C'est mon premier crash pour la version d'initié, mais comme pour la version normale, j'ai mis à niveau vers la v1.0 et elle se bloque toujours toutes les quelques minutes environ après son ouverture, ce qui la rend inutilisable. Je n'ai même rien à faire de spécial. Ouvrez-le, modifiez un fichier (principalement des fichiers .elm) ou laissez-le simplement faire et il se bloque. N'attend même pas de perdre sa concentration en premier.

1.0 plante presque tous les soirs.
Windows 10 Ent.
Plugins: vérificateur d'orthographe et de grammaire, ESLint

Ok, une version d'initiés est sortie avec ma modification incluse. Je serais heureux que quelqu'un l'essaie: http://code.visualstudio.com/Download#insiders

N'importe qui :)?

Je l'utilise maintenant. Je n'ai pas eu d'accident depuis hier.

@bpasero Je vais mettre à jour maintenant et le laisser fonctionner pendant la nuit et voir comment nous allons! À votre santé :)

@bpasero Je l'ai installé vendredi mais je suis parti pour un long week-end, aussi mon PC de travail a été redémarré donc je n'ai rien à signaler.

@bpasero s'est écrasé hier. Resté debout pendant 3 jours avant de s'écraser.

@bpasero Je vois toujours le crash occasionnel le matin avec les dernières versions d'initiés

Moi aussi.
Windows 8

@bpasero Insider 1.1.0 empile mieux, a pris près d'une semaine avant qu'il ne plante.

Je vais prendre 1.1.0 maintenant et voir comment ça se passe

Je n'arrive pas à prendre un instantané de tas sans qu'il se bloque lorsque l'utilisation de la mémoire est supérieure à 150 Mo.

Chaque matin, je déverrouille mon ordinateur pour constater que VS Code s'est écrasé pendant la nuit.

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

J'ai généralement laissé des fichiers ouverts. Je cours avec des extensions. Y a-t-il des paramètres que je peux utiliser pour vous aider à collecter plus d'informations de diagnostic?

Notre nouvelle version d'initiés est sortie (http://code.visualstudio.com/Download#insiders) et inclut notre travail pour les onglets / piles. Cela s'accompagne d'une élimination plus agressive des ressources car dès que vous fermez un éditeur, nous nous débarrassons de ses ressources sous-jacentes.

Curieux de savoir si les gens pourraient s'auto-héberger sur ce sujet pendant un moment et signaler si les choses s'améliorent.

Remarque: les initiés sont désormais mis à jour tous les soirs (voir http://code.visualstudio.com/blogs/2016/05/23/evolution-of-insiders)

@bpasero J'ai mis à jour tous mes appareils aujourd'hui, voyez comment nous allons au cours des prochains jours

Ouais, je suis principalement passé aux initiés à cause du terminal. Oh combien je
aimer. J'ai trouvé l'éditeur beaucoup plus vif et plus léger. Bon travail.

Est-il possible que je puisse remplacer "code". Dans la ligne de commande pour pointer vers
initiés?

Le mercredi 8 juin 2016, Elijah Bate [email protected] a écrit:

@bpasero https://github.com/bpasero J'ai mis à jour tous mes appareils aujourd'hui,
voir comment nous allons au cours des prochains jours

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -224539214,
ou couper le fil
https://github.com/notifications/unsubscribe/AA-JVM4KoGeXoc2SU5VeEYnxkZyPVWYMks5qJo13gaJpZM4Gnvn5
.

Cela se passe toujours sur 1.2.0 pour moi. Se produit tous les soirs - fonctionnant sous Windows 7 Enterprise SP1. J'ai la même question que @garthk

J'ai généralement laissé des fichiers ouverts. Je cours avec des extensions. Y a-t-il des paramètres que je peux utiliser pour vous aider à collecter plus d'informations de diagnostic?

@northerncodemky Je

@bpasero Aah ok - n'a pas chronométré l'horodatage de votre commentaire. Je vais changer à un moment donné aujourd'hui pour voir si cela améliore les choses. Et obtenez de nouvelles fonctionnalités pour démarrer :)

@bpasero a l' air bien jusqu'à présent !!

J'ai fait construire VSCode Insiders pendant le week-end. Je suis venu lundi matin et j'ai vu un accident.

Je me demande s'il existe des données de plantage / vidage de télémétrie qui sont automatiquement envoyées lorsque VSCode se bloque? Un peu comme les rapports de Watson.

J'ai eu une nouvelle machine la semaine dernière. Quand je l'ai configuré, je n'ai mis que la version de version (pas les initiés) - je n'ai pas remarqué qu'elle plante depuis lors.

@bpasero Je n'ai vu aucun crash depuis la 1.3, exécutant Windows 10 Insider Build> = 14367

@bpasero avec les onglets activés, le projet ac # ouvert et vscode plante une erreur quelques minutes après la dernière mise à jour du hachage de validation d'initié: 5474147bb83618975409dad7d8aa96151d7d1ea1.
REMARQUE: je n'avais auparavant pas activé les onglets jusqu'à présent

@ eByte23 pouvez-vous vérifier que cela est lié à l'activation ou non des onglets en essayant sans onglets?

@bpasero se produit toujours lorsque les onglets sont désactivés, mais nulle part près de la gravité avec les onglets activés.

Mais est très visible et reproductible lorsque vous travaillez avec des images, en cliquant rapidement entre de grandes images à la fois dans Insider et v1.2.1

@ eByte23 Je suggère d'ouvrir un nouveau numéro à ce sujet avec autant de détails que vous pouvez fournir (par exemple, la mémoire augmente-t-elle?).

Sûr peut faire. Je n'ai pas encore fait beaucoup d'enquête à ce sujet, mais je vous donnerai des détails plus détaillés un peu plus tard.

VSCode 1.3.1 plante environ deux fois par jour pour moi, une fois pendant la nuit (toujours) et parfois au hasard pendant la journée. Il s'est écrasé maintenant alors que je l'avais ouvert en arrière-plan, sans l'utiliser pendant environ 2 heures. De plus, en ouvrant à nouveau vscode, il perd mon espace de travail et je dois rouvrir le dossier de projet qu'il avait ouvert avant le crash. Les onglets et les fractionnements sont conservés après la réouverture du dossier.

Je suis resté ouvert en arrière-plan pendant un moment avec des modifications non enregistrées, je suis revenu, j'ai commencé à taper et vscode s'est figé pendant quelques secondes, puis s'est écrasé. il a perdu mon travail.

J'espère que vous comprendrez ma frustration. C'est inacceptable pour un éditeur. De plus, la session qu'il a restaurée n'avait même pas les bons onglets ouverts, ni ma place dans chaque onglet.

@DelvarWorld pouvez-vous partager plus de détails sur votre environnement de travail? pouvez-vous essayer d'exécuter avec les extensions désactivées pour voir si cela aide?

J'ai ce même problème sur Linux Mint 17 Qiana (je ne me souviens plus de la version d'ubuntu!). Il a juste gelé pour moi après ~ 2 heures d'inactivité. Je me souviendrai de vérifier l'utilisation de la mémoire / du processeur la prochaine fois que cela se produira, même si je n'ai jamais remarqué de ralentissement général dans d'autres applications, etc. lorsque cela se produit.

Informations sur le VSCode:

Version 1.4.0
Commit 6276dcb0ae497766056b4c09ea75be1d76a8b679
Date 2016-08-04T16: 49: 32.489Z
Coquille 0,37,6
Moteur de rendu 49.0.2623.75
Nœud 5.10.0

Ce problème a disparu pour moi (sur 1.5.3, Windows 7) - étant donné que le dernier commentaire date d'il y a 2 mois, est-ce peut-être résolu?

Je n'ai pas vu cela se produire pour moi depuis des lustres non plus. J'utilise la version actuelle depuis des mois. Semble correct

Même. Ne semble pas du tout surcharger.

Ok, nous devrions continuer dans les problèmes individuels et éviter les bugs monstres comme celui-ci qui sont difficiles à suivre. Si quelqu'un rencontre toujours ce problème, veuillez signaler les nouveaux problèmes avec plus de détails. VEUILLEZ éviter de détourner un problème existant 👍

Je me souviens aussi d'avoir vu cela auparavant et je ne l'ai pas vu depuis des lustres, c'est donc ma vérification.