Vscode: Crash cuando se ejecuta durante la noche

Esto parece suceder constantemente todas las noches que dejo la computadora encendida. Parece que no responde debido a que la CPU está al máximo. ¿Quizás algún bucle infinito esté en alguna parte, quizás relacionado con el sondeo del repositorio de archivos o git?

Me pregunto si el sistema operativo decide poner VSCode (Electron en realidad) en un estado en el que está causando este bloqueo. He hecho ping a Electron si tienen una pista.

Nunca sucedió en Atom fyi, al menos en 1.19.x (desde la memoria) y 1.2.4.

Tengo un problema similar desde la actualización de noviembre (¿0.10.2 / 0.10.3?). Casi todos los días, me registraba para encontrar que las ventanas de VSCode que quedaban durante la noche se habían bloqueado (con el error estándar de bloqueo no informativo / apologético, "Visual Studio Code se ha bloqueado").

Hoy, después de la actualización 0.10.5, tuve mi primer bloqueo mientras estaba allí, desafortunadamente no mientras lo usaba activamente.

Ejecutando VSCode en Windows 7 (64 bits), usándolo principalmente como un editor JS en un proyecto muy grande: casi un millón de líneas en total (incluidas las bibliotecas que necesito buscar, por lo que no están excluidas). No hay problemas de rendimiento en el uso normal y no noté ningún uso excesivo de recursos antes del bloqueo de hoy.

Estaría encantado de proporcionar registros / información de errores más detallados si alguien me puede indicar.

Tengo el mismo problema básico que @ Elusive138 , cuando dejo el código ejecutándose durante la noche (todas las noches), por la mañana, sin falta,

Todavía repros para mí en vscode 0.10.5, Ubuntu 12.04

Intenté reproducirlo en Windows 10, Mac OS 10.11 y Ubuntu 15 sin suerte. Sospecho que hay un problema de falta de memoria, pero por ninguno de los anteriores, la memoria estaba aumentando mucho.

¿Alguien puede intentar reproducir esto con las siguientes condiciones:

• ¿Se reproduce al abrir solo una instancia vacía de código (Archivo | Cerrar carpeta)?
• ¿Se reproduce al abrir un espacio de trabajo pero no al abrir ningún archivo en el editor?

Ubuntu 12.04, vscode 0.10.5 no se pudo reproducir dejándolo durante el fin de semana con una instancia vacía.

Bien puede ser una fuga de memoria sutil, que se pone de manifiesto por la utilización de memoria relativamente alta en este sistema.

Dejé la computadora alrededor de las 5:30 p.m., con la confirmación de la memoria del sistema aumentando lentamente: era de 15,402 MB a las 7:00 p.m. A las 3:09 a.m. fue el enfoque más cercano al límite de confirmación del sistema (17,682 MB), y el uso de la confirmación se redujo de 16,218 MB a 15,217 MB. Sospecho que esto podría ser donde VSCode se bloqueó. El uso de la confirmación se mantuvo estable hasta que el registro se detuvo alrededor de las 6 a.m. (sin espacio en disco, ¡esos contadores de rendimiento son grandes!).

Desafortunadamente, no incluí todos los procesos de VSCode, por lo que no tengo un registro específico del proceso. Lo intentaré esta noche.

Sería muy útil si pudiera obtener la hora del accidente. ¿VSCode deja registros en cualquier lugar?

Desafortunadamente, no incluí todos los procesos de VSCode, por lo que no tengo un registro específico del proceso. Lo intentaré esta noche.

Eso sería muy útil, ¡gracias!

Actualmente, vscode no se registra en el disco.

@ Elusive138 ¿puedes compartir el espacio de trabajo en el que dejas que se ejecute vscode?

@bpasero Lamentablemente no. Sin embargo, se basa en Ext JS, y ahí es donde se encuentra la mayoría del código (de la biblioteca). Probaré un espacio de trabajo limpio de Ext JS después de que se hayan realizado otras pruebas, y veré si repros allí.

@ Elusive138 sí, sería bueno tener una muestra para reproducir de nuestra parte.

Uno de los procesos de code.exe (código # 3 en el registro, adjunto) parece tener una fuga. La confirmación comenzó en aproximadamente 200 MB a las 5:30 p.m. y alcanzó los 460 MB a las 9:00 a.m. del día siguiente, con un aumento constante:

El recuento de manejadores no aumenta.

vscode_memleak.zip

Esta vez no hubo ningún bloqueo, tal vez porque no tenía tantos programas que consumían mucha memoria en ejecución. Podría probar esto en una máquina virtual con un límite de confirmación bajo más adelante.

Este registro se creó durante la noche con 3 grandes espacios de trabajo abiertos en diferentes ventanas. Intentaré reducirlo a un espacio de trabajo que pueda compartir.

@ Elusive138 sería útil comprender los detalles del proceso que se filtra. ¿Puede encontrar su PID y luego imprimir sus metadatos completos usando ps aux | grep <pid> ?

Ah, tal vez esto esté en Windows, ¿no estoy seguro :)?

@bpasero La línea de comando es:

"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

Otros detalles:

El árbol de procesos:

Esto es después de otro día completo de uso. Como puede ver, el uso de memoria del proceso parece haber aumentado linealmente en ese tiempo (mismo espacio de trabajo).

Ah ... este ni siquiera es el realmente malo.

4772 fue el proceso que se filtró durante la noche. El otro parece haberse levantado debido a mi uso durante el día ... creo.

@ Elusive138 parece que tienes varias ventanas abiertas con el código, ¿es cierto?

@bpasero Sí, la prueba de anoche tenía tres ventanas abiertas con diferentes espacios de trabajo. Lo intentaré esta noche con solo uno, en un espacio de trabajo limpio de Ext JS como se mencionó anteriormente.

¡Suena bien!

Desafortunadamente, no hay repro ... esto es extraño. ¿Qué podría estar causando una fuga dentro de ese proyecto específico?

Hablando de eso, esto podría ser diferente del número inicial de @Tyriar . El suyo no respondía, el mío y gwynjudd se bloquean con el diálogo de error ..? En cuyo caso tal vez deberíamos hacer un nuevo número ...

@ Elusive138 extraño. ¿Se reproduce si simplemente abre ese espacio de trabajo sin abrir ningún archivo JS?

Además, tal vez podamos comenzar a perfilar esto utilizando las herramientas de desarrollo de Chrome, donde puede hacer muchas instantáneas. Para eso, simplemente haga una instantánea antes y después de un tiempo para ver a dónde va ese recuerdo.

@bpasero Oh, me olvidé por completo de esas herramientas de desarrollo. Probaré esa esta noche.

@bpasero Las instantáneas de montón de Main.js , workerMain.js y workerMain.js (2) realmente no cambian. Tal vez por 5 MB como máximo.

Añadiendo más sobre mi situación, traté de ejecutarlo con una carpeta abierta (la que falló) pero sin archivos de trabajo y no sucedió de la noche a la mañana. Por lo tanto, solo sucede cuando una carpeta está abierta y hay archivos activos activos.

@ Elusive138 generamos otros procesos que pueden causar la presión de la memoria y no aparecerían en el perfil del montón. Sin embargo, a partir de una de sus publicaciones anteriores, parece que había identificado la memoria alta proveniente del proceso del renderizador y que debería aparecer debajo de la instantánea del montón. ¿Está seguro de que vio la memoria alta para el proceso de renderizado y no para sus hijos? porque el renderizador es el padre de otros procesos que genera, por ejemplo, un proceso para ver archivos.

@Tyriar, ¿puedes ser más específico a lo que te refieres con eso? ¿Es que no abrió ningún archivo en el editor o que literalmente tenía la sección de archivos de trabajo vacía?

La razón por la que pregunto acerca de abrir un archivo o no es que, por ejemplo, el servicio de lenguaje JS solo se inicia una vez que abre un archivo JS. Lo mismo ocurre con cualquier otro servicio de idiomas. Entonces, si este problema se reproduce sin abrir un archivo en el editor, es probable que la pérdida de memoria no esté en ningún servicio de idioma sino en otro lugar.

Otra cosa que vale la pena intentar: ejecutar sin ninguna extensión para ver si tal vez una extensión tiene una fuga. Puede ejecutar con --disable-extensions para hacerlo.

@bpasero Estoy seguro de que la línea de comando proporcionada anteriormente era para 4772, la resaltada (con fugas) en la captura de pantalla. Dice --type=renderer .

Lo dejaré funcionando durante el fin de semana nuevamente y veré qué sucede. No creo que haya hecho una prueba limpia sin archivos JS abiertos todavía.

@bpasero Creo que no tenía ningún archivo abierto (a la derecha), solo archivos de trabajo sobre el árbol. Si recuerdo cuando termine el trabajo, intentaré verificar con un archivo abierto y anotar el idioma.

No lo sé con certeza, pero probablemente no era un archivo JavaScript cuando el mío falló, más probablemente C ++, Java o ningún idioma. Me aseguraré de comprobarlo.

@Tyriar si se reproduce solo teniendo algo en los archivos de trabajo y con todos los editores cerrados (desde el inicio, eso es importante), podríamos estar en algo.

@bpasero Podría intentar abrir un montón de instancias en diferentes condiciones antes de salir del trabajo el viernes y ver si puedo sacar todos mis experimentos del camino en una noche. ¿A menos que tenga motivos para creer que una instancia de vscode colgando rompería todas las demás?

@Tyriar sí, totalmente, si tiene más de una ventana abierta, todo se suma a la memoria total que se está utilizando y todas se bloquean. Esto se debe a que cuando abre varias ventanas, todavía comparten todo un proceso principal y un límite de memoria de aproximadamente 1-1,5 GB. Para comprender realmente de dónde proviene la fuga, lo mejor sería medir 1 ventana aislada en estas condiciones:

• ninguna extensión habilitada a través de --disable-extensions (una extensión que consume mucha memoria o fugas también causaría un bloqueo)
• ningún archivo se abrió al inicio (solo cerrar un archivo después del inicio ya es demasiado tarde)
• no hay archivo de trabajo en archivos de trabajo

Por cierto, lo único para los archivos de trabajo que podría tener un impacto es que para cada archivo de trabajo que no esté dentro del espacio de trabajo, instalamos un observador de archivos para observar los cambios. tal vez esto cause la fuga, aunque sería sorprendente. Además, no instalamos un observador si el archivo está dentro del espacio de trabajo que se abre, solo para archivos externos.

@bpasero Sin fugas cuando no hay archivos abiertos (?). Probaré el espacio de trabajo limpio esta noche después de asegurarme de abrir algunos.

Probé durante el fin de semana con la siguiente configuración:

1. Lanzamiento con Code --disable-extensions
2. Abra un archivo JavaScript de ~ 1300 líneas

La memoria y la CPU eran aproximadamente las mismas el viernes por la noche y el lunes por la mañana.

@Tyriar , ¿esto fue simplemente abrir un espacio de trabajo vacío con un archivo o abrir una carpeta primero y luego un archivo de ella?

@bpasero Abriendo un espacio de trabajo vacío, no abrí una carpeta y no había ninguna carpeta abierta cuando inicié

Bien, es bueno saberlo. Entonces, esto parece estar relacionado con tener una carpeta (potencialmente grande) abierta. Aún queda por averiguar si solo abrir esta carpeta es suficiente o tener un archivo abierto solo lo activa.

@bpasero Tenía una carpeta grande abierta sin archivos abiertos durante el fin de semana, sin un aumento notable en el uso de memoria. Tendré los resultados de una prueba de apertura de archivos y carpetas grandes con, con suerte, un espacio de trabajo reproducible / compartible en aproximadamente 7 horas.

@bpasero, la carpeta en la que experimenté bloqueos antes habría sido de 13000-14000 archivos fuertes, esto incluye el repositorio de git, que tenía alrededor de 2000 por sí mismo.

Supongo que volveré a verificar que el bloqueo aún ocurre en la última versión, ya que ha pasado un tiempo desde que lo vi (debido a las pruebas).

¿Y supongo que es un espacio de trabajo JS?

@bpasero py, cpp, js, html, css

Ok, esto parece reproducir el uso de memoria que aumenta lentamente, si en una escala más pequeña: /ext/build/ext-all-debug.js abiertos.

(Sí, es un 7z dentro de un zip ... GitHub no me deja subir un 7z o xz directamente, y zip y gzip son demasiado grandes)

@ Elusive138 ¿cuánto aumenta para ti en promedio? Tuve el espacio de trabajo con algunos archivos JS abiertos durante 2 horas sin ningún aumento de memoria.

@bpasero Lo siento, tengo problemas para reproducirme de nuevo. Creo que tuve un repositorio de git perdido en un intento anterior, que no estaba incluido en el archivo anterior. Te avisaré cuando tenga resultados más concretos.

Sería realmente útil si fuera posible abrir múltiples instancias independientes ... estar limitado a una prueba por noche es bastante lento. ¿Lleva las banderas de Chromium para perfiles separados?

Es posible crear varias versiones de Código que se pueden ejecutar en paralelo, aunque no lo hemos documentado. Si cambia los valores en https://github.com/Microsoft/vscode/blob/master/product.json para que sean diferentes y luego compile desde la línea de comando, puede iniciar múltiples instancias distintas. Los identificadores que tienen que ser únicos son:

• darwinBundleIdentifier
• win32MutexName
• nameShort
• nameLong
• dataFolderName (por ejemplo, "dataFolderName": ".oss-code-1")

Windows 8.1. En Code, abrió una carpeta para un repositorio de git que contiene 39,000 archivos por la mañana.
Hice muy poco con él, algunas pequeñas ediciones en un par de archivos.
Al final del día, el Tamaño de confirmación informado por el Administrador de tareas era 672,164K.
Creció de manera constante durante todo el día, incluso cuando no estaba en el programa.

@gushie, ¿hay alguna posibilidad de que este repositorio se pueda compartir conmigo? además, ¿cuál fue la memoria inicial reportada?

@bpasero Lo siento, no puedo compartir el repositorio en sí, pero si hay algún detalle al respecto que pueda ayudar, excluyendo el contenido del archivo, avíseme. El proceso comienza inicialmente en alrededor de 110 MB, crece rápidamente a alrededor de 130 MB antes de volver a establecerse en 90 MB. Luego crecerá de manera constante a partir de este punto en adelante. (Hay otros 5 procesos de code.exe que varían de 4 MB a 30 MB, pero estos no crecen notablemente. Solo hay una ventana de código)

No sé cuál fue el tamaño de compromiso final de ayer, ya que el proceso se había bloqueado cuando volví hoy.

@gushie He estado usando Performance Monitor en los procesos code.exe para monitorear el "Tamaño privado".

¡Es bastante molesto que no podamos compartir los espacios de trabajo con los que tenemos problemas! Me pregunto si alguien ha encontrado esto con algo de código abierto. Buscando similitudes: ¿alguna vez se usó su repositorio con git-svn?

@bpasero Gracias, si el proceso que dejé no se ha reprogramado cuando regrese el lunes, podría intentar construir un par de copias adicionales. Necesitaría averiguar cómo hacer un seguimiento de cuál, aunque ... eso podría ser un problema.

@ Elusive138 Usamos herramientas de Atlassian, por lo que SourceTree se conecta a un servidor Stash privado

Ah, eso es completamente diferente al mío. Era un repositorio de Git local (con extensiones de Git) que se conectaba a un servidor SVN. Mi prueba actual es con un repositorio de git basado en el vscode uno ... con suerte eso se reproducirá y puedo compartirlo.

@gushie, ¿se reproduce si simplemente abre el espacio de trabajo sin abrir ningún archivo? Primero intente cerrar todos los archivos y reinicie para obtener esta configuración. si eso no se reproduce, ¿se reproduce si abre el espacio de trabajo y abre un archivo JS y lo deja así?

@bpasero Ya lo había dejado abierto con un solo archivo de trabajo sin editar anoche, y al comprobar esta mañana el uso de la memoria no parece haber cambiado mucho. Ahora edité y construí el archivo, y dejaré esto para ver qué sucede.

Tenga en cuenta que hasta que leí este problema, nunca había borrado los archivos de trabajo. (Realmente no había tenido la necesidad de hacerlo, generalmente ignoré este panel y cambié los archivos a través del explorador de archivos del proyecto debajo de él, o con Ctrl + E).

Se estrelló nuevamente, esta vez fue después del uso regular, pero se dejó en este estado:

• ~ Carpeta de archivos 14000 abierta
• 5 archivos de trabajo activos (.cc, .java, .h, .py, .json)
• Ningún archivo abierto en el editor de texto

ps aux salida:

❯ 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

Como se mencionó, esto fue después del uso regular y no en modo seguro, por lo que _ ¿podría_ haber sido debido a una extensión?

Dejé un solo archivo con una pequeña edición abierta, solo ese archivo en los archivos de trabajo. De lo contrario, intacto todo el día. La memoria no ha aumentado de su valor inicial.

@Tyriar bueno, el proceso que está mostrando es nuestro servicio de observación de archivos y en Linux / Mac usamos Chokidar para él (https://github.com/paulmillr/chokidar). Esto indicaría que tienen una fuga al ver archivos. ¿Hay alguna tarea de compilación que se ejecute constantemente y cambie archivos?

@gushie ¿ fue esto sin abrir una carpeta?

@bpasero Tenía la carpeta abierta. Obviamente, hay alguna acción que parece iniciar las pérdidas de memoria más allá de la apertura inicial de un archivo dentro de la carpeta. Continuaré monitoreando e intentaré reducirlo.

@bpasero Ese fue el único proceso relacionado con vscode que pude ver en la salida, ¿es posible que no fuera visible en la salida porque ya se eliminó debido a la falta de respuesta? Como se muestra, ese proceso solo usaba el 0.5% de la memoria y el 0% de la CPU. Creo que, de mis descubrimientos recientes, el problema que estoy experimentando probablemente no se deba a un servicio JS.

Por cierto, incluso si no encontramos el motivo de esto hasta fin de mes, presioné un cambio para que el cuadro de diálogo de bloqueo que aparece por defecto seleccione una acción para volver a abrir la ventana para que pueda continuar trabajando donde lo dejó. Esto también es bueno para el caso en el que tiene varias ventanas abiertas y solo una de ellas se bloquea.

(una cosa que falta y para el futuro es poder vaciar periódicamente el estado de la interfaz de usuario en el disco para que la reapertura también restaure su entorno de trabajo anterior)

@bpasero : +1: eso sería útil.

VS ha estado fallando todas las mañanas durante aproximadamente un mes. He llegado al final de mi paciencia.

Espero que esto sea tratado como un error PRI 0 porque cualquier editor en su sano juicio no debería fallar tan a menudo.

Hágame saber cómo puedo rastrear el motivo de esto. También he visto que esto sucede en otras máquinas.

@nojvek, ¿puedes compartir conmigo el espacio de trabajo donde sucede esto?

No estoy seguro de a qué te refieres con compartir espacio de trabajo. Es un proyecto mecanografiado / HTML / CSS con un poco de c ++. Alrededor de ~ 1500 archivos y 80,000 líneas de código.

¿Hay alguna forma en VS para mostrar los volcados de emergencia?

@nojvek Me gustaría tener un espacio de trabajo con el que pueda ejecutar Code para reproducir este problema. Sospechamos que está relacionado con una fuga de memoria en algún lugar, pero no está claro dónde. Si puede enviarme un zip del espacio de trabajo o tal vez la URL de git si es de código abierto.

Benjamín,

Es el código fuente interno de Microsoft y no creo que pueda dárselo.

Si hay alguna herramienta de monitoreo de memoria que pueda agregar, avíseme.

¿Funcionaría si tomo instantáneas de memoria con el depurador de Chrome integrado?
en vscode cada dos horas para ver qué está pasando?

El sábado 23 de enero de 2016, Benjamin Pasero [email protected]
escribió:

@nojvek https://github.com/nojvek Me gustaría tener un espacio de trabajo que
Puedo ejecutar Code con para reproducir este problema. Sospechamos que está relacionado con un
pérdida de memoria en alguna parte, simplemente no está claro dónde. Si puedes enviarme un zip
del espacio de trabajo o tal vez la URL de git si es de código abierto.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -174192367.

Sí, las instantáneas de memoria ayudarán si y solo si esta fuga está dentro del lado principal de VS Code. Sin embargo, parece que al menos en un caso la filtración se produjo en uno de los procesos que generamos (el observador de archivos). Tal vez pueda identificar con el explorador de procesos, qué proceso aumenta constantemente en términos de consumo de memoria.

Si me ayuda proporcionarme el código fuente: trabajo para Microsoft;)

Hablaré con mi gerente. Esto está en el repositorio de Windows, así que tendré que
tenga un poco de cuidado.

Desde el hilo, parece que el chokidar se usa para el observador de archivos. Un rato
atrás jugué con el código fuente. Fue un poco de espagueti.

Veré si puedo cargar chokidar en su propia aplicación de nodo simple y veré si es
el culpable.

Por cierto, ¿hay alguna razón específica por la que vs necesita usar chokidar? Hay otros
observadores de archivos multiplataforma, ¿verdad?

El domingo 24 de enero de 2016, Benjamin Pasero [email protected]
escribió:

Sí, las instantáneas de memoria ayudarán si y solo si esta fuga está dentro de la
lado de VS Code. Sin embargo, parece que al menos en un caso la fuga fue
en uno de los procesos que generamos (el observador de archivos). tal vez podrías
identificar mediante el explorador de procesos, cuyo proceso aumenta constantemente en
términos de consumo de memoria.

Si me ayuda proporcionarme el código fuente: trabajo para Microsoft;)

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -174269028.

Chokidar se usa en Mac y Linux, si está en Windows, usamos un observador de archivos C #. Me complace aceptar un PR con una solución de observador de archivos cruzados que funcione y que funcione :)

Sabe que a partir del nodo 4.0 el fs.watch está estabilizado tanto en Windows como en Mac. Ver: https://github.com/Microsoft/TypeScript/issues/4643.

TypeScript tiene una lógica de observación de archivos / directorios multiplataforma bastante sólida. https://github.com/Microsoft/TypeScript/blob/931d162620c7e09377c12875834e1838c4cdd51b/src/compiler/sys.ts

Intentaré obtener una compilación local del código VS con un cambio y veré si aún falla. Si no es así, definitivamente enviaré un PR.

Sé que mejoró mucho al usar la llamada de vigilancia recursiva en el directorio y así evitar tener que adjuntar un oyente de vigilancia por carpeta, pero creo que los eventos a veces pierden el nombre del archivo / carpeta, al menos en algunos casos. Me siento más confiado usando C # aquí.

Logré conseguir una reproducción hoy. Me bloqueé antes de abrir la consola de herramientas del desarrollador para tomar una instantánea de la memoria.

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

Parece que el servidor de mecanografiado está ocupando unos 200 MB.
El renderizador consumió alrededor de 800 MB y luego se bloqueó.

Cuando tenga unos 500 MB de uso, intentaré tomar una instantánea de la memoria. El proceso de --renderer es el proceso de webkit, ¿verdad?

Esto fue después de dos días desde la última vez que vi un accidente. Parece que usar la herramienta durante un período de 8 horas editando muchos archivos TS aumenta el uso más rápido.

Bonito, el proceso de renderizado es el proceso principal para el editor. Si puede hacer una instantánea de la memoria allí, nos llevaría más lejos. Desafortunadamente, la instantánea no funcionaría para ningún otro de los procesos, pero esos parecen estar bien.

¿Es normal que tscse (servidor mecanografiado) consuma 200 MB?

El martes 26 de enero de 2016 a las 9:29 p.m., Benjamin Pasero [email protected]
escribió:

Bonito, el proceso de renderizado es el proceso principal para el editor. Si tu
Puede hacer una instantánea de la memoria que nos llevaría más lejos. Desafortunadamente, el
La instantánea no funcionaría para ningún otro de los procesos, pero esos parecen funcionar
estar bien.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -175408302.

Sí, muy fácilmente.

Jajaja Estaba en el proceso de tomar una instantánea del montón y VS se bloqueó.

Lo intentaré de nuevo y veré si tengo mejor suerte mañana.

¿Hay alguna manera de decirle a vscode que aumente su límite de memoria para que no se bloquee al intentar tomar una instantánea del montón?

Creo que lo que sucede es que al tomar la instantánea, causó una excepción de memoria insuficiente: - /. No hay forma de cambiar el límite de memoria, está codificado en V8.

¿Quizás intentar tomar la instantánea un poco antes, antes de que el uso de la memoria aumente tanto? ¿Es un aumento gradual?

No he podido reproducir (sin fallas, uso de memoria razonable) durante las últimas dos semanas más o menos. La única diferencia en la que puedo pensar es en la actualización de la extensión PowerShell de 0.1.0 a 0.3.1, pero de todos modos no tengo ningún archivo PS en el espacio de trabajo, y se bloqueó con las extensiones deshabilitadas en ese momento.

Obtuve un volcado exitoso de alrededor de 300 MB utilizados por el proceso --renderer. Se estrelló 10 segundos después de que me tirara al basurero.

Parece que la mayor parte del uso está en el árbol DOM.

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

Espero que esto ayude.

Mmmm, me pregunto si el generador de perfiles está diciendo la verdad real aquí. Veo todos los elementos del árbol y también podríamos tener una fuga en el árbol, pero me sorprendería que esta fuga pudiera causar una falta de memoria en un período de tiempo tan corto.

Tomé algunos vertederos más.

Parece que abrir archivos .min.js provoca un gran salto en la memoria. Incluso después de cerrar los archivos, la memoria no parece disminuir. Entre todos los volcados de memoria, parece que DOM es el dominador.

Tampoco estoy seguro de por qué hubo dos procesos de renderizado. Puede que uno de ellos fuera el de cromo devtools. Pero estuve muy cerca de 1 concierto.

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

Tomé una captura de pantalla de los dos procesos que consumían ~ 500 MB de RAM.

Sí, uno es devtools. Se espera que la memoria aumente cuando abre archivos. Pero me gustaría entender cómo un código VS que se ejecuta durante la noche sin actividad aumenta el uso de la memoria hasta que se bloquea.

Bueno, la repro es:
Inicio vs código.
Abra uno o dos archivos js / ts en una carpeta grande con muchos archivos .tsconfig.
Haz un desplazamiento / edición.
Cierre todos los archivos de trabajo.
Ponlo en el uniforme a 200c durante la noche.
¡Pastel!

El viernes 29 de enero de 2016, Benjamin Pasero [email protected]
escribió:

Sí, uno es devtools. Se espera que la memoria aumente al abrir
archivos. Pero me gustaría entender cómo un VS Code que se está ejecutando
noche sin actividad aumenta el uso de la memoria hasta que se bloquea.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -177087988.

@nojvek ¿Son los .tsconfig s necesarios para reproducir? porque he tenido accidentes en el pasado sin nada relacionado con el TS. Aunque ya no puedo reprocharlos ...

Nuestro proyecto simplemente los tiene. Podría ser una pista falsa.

El sábado 30 de enero de 2016, Bob [email protected] escribió:

@nojvek https://github.com/nojvek ¿Son los .tsconfigs necesarios para
repro? porque he tenido accidentes en el pasado sin nada relacionado con TS en
todas. Aunque ya no puedo reprocharlos ...

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -177198518.

Los únicos archivos. * Que tenemos en nuestra carpeta son la carpeta .git y .gitignore

@nojvek, ¿está utilizando un servidor mecanografiado personalizado con el proyecto o el TS listo para usar que enviamos en 0.10.6? El que enviamos en 0.10.6 es TypeScript 1.7.5

@bpasero @nojvek si se trata de un problema de memoria en el lado de JS. Puede diferenciar la instantánea del montón en Chrome.

1. Toma una foto.
2. Realice la acción que provoca la pérdida de memoria.
3. Forzar la recolección de basura. De lo contrario, la siguiente instantánea del montón incluirá los objetos.
4. Toma otra instantánea.
5. Diferencia ambas instantáneas.

Todo se puede hacer con Chrome Devtools arriba. La fuerza de la recolección de basura está en la pestaña de la línea de tiempo, el icono de basura. Y la diferenciación se realiza simplemente eligiéndolo en el explorador de instantáneas en el menú de filtro.

Simplemente informe qué objetos se retienen y posibles rutas de retención (justo debajo de la tabla de montón). Y esos son todos los datos necesarios para solucionar este problema.

No es necesario esperar un día entero para recopilar datos sobre un accidente: guiño:

El enlace de Dropbox que envié tenía tres instantáneas de calor tomadas con media hora de diferencia.
No hice la recolección forzada de basura. Le daré un truco.

El domingo 31 de enero de 2016, Tingan Ho [email protected] escribió:

@bpasero https://github.com/bpasero @nojvek https://github.com/nojvek
si es un problema de memoria en el lado JS. Puede diferenciar la instantánea del montón en
Cromo.

1. Toma una foto.
2. Realice la acción que provoca la pérdida de memoria.
3. Forzar la recolección de basura. De lo contrario, la siguiente instantánea del montón
   incluir los objetos.
4. Toma otra instantánea.
5. Diferencia ambas instantáneas.

Todo se puede hacer con Chrome Devtools arriba. La fuerza de la basura
La colección está en la pestaña de la línea de tiempo, el icono de basura. Y la diferencia es
hecho simplemente eligiéndolo en el explorador de instantáneas en el menú de filtro.

Simplemente informe qué objetos se retienen y posibles rutas de retención (justo debajo
la mesa del montón). Y esos son todos los datos necesarios para solucionar este problema.

No es necesario esperar un día entero para recopilar datos sobre un bloqueo [imagen:
:guiño:]

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -177462412.

Tengo el mismo problema, VS Code se bloquea constantemente, no solo durante la noche, incluso después de 30 minutos de inactividad.
Estoy usando Windows 7, 64 bits y la última versión de VS Code. Con respecto al proyecto en sí, es un gran proyecto js, ​​con node_modules y bower_components también cargados. Totalmente tiene alrededor de 40K de archivos.

Pasos para reproducir:
1) Abra la carpeta del proyecto (con muchos archivos), abra varios archivos para que estén en la lista de Archivos de trabajo.
2) Abra el administrador de tareas.
3) Coloque el cursor para enfocar algún archivo en VS Code
4) Observe cómo la memoria aumenta con el tiempo.

¿Pueden las personas con espacios de trabajo JS que vean este problema probar nuestra versión 0.10.7 para iniciados (https://vscode-builds.azurewebsites.net/insider) con la opción de usar Salsa como servicio de lenguaje JS: https://github.com /Microsoft/vscode-docs/blob/vnext/release-notes/latest.md#javascript --- salsa-preview

¡Gracias!

+1 para este problema. También aparece en Windows. Es totalmente molesto y no me gusta.

@bpasero Me gustaría probar la nueva compilación, pero cada vez que intento acceder al enlace que proporcionó (https://vscode-builds.azurewebsites.net/insider), aparece una página de mensaje de error muy inútil con el siguiente texto :

Registrarse
Lo sentimos, pero tenemos problemas para iniciar sesión.
Recibimos una solicitud incorrecta.

Información técnica adicional:
ID de correlación: e477dc1b-c193-4cf9-864b-1d3fdbba4f34
Marca de tiempo: 2016-02-03 19: 37: 17Z
AADSTS50020: la cuenta de usuario ' [email protected] ' del proveedor de identidad ' https://sts.windows.net/5a7d8144-6966-4b1e-8147-de672a307ea0/ ' no existe en el inquilino 'Microsoft' y no puede acceder a la aplicación ' 9d5f02f6-ffd9-4e80-92d5-e42c85e09bc9 'en ese inquilino. La cuenta debe agregarse primero como un usuario externo en el inquilino. Cierre la sesión y vuelva a iniciarla con una cuenta de usuario de Azure Active Directory diferente.

No puedo descargar la compilación y probarla debido a este problema.

Ah, lo siento, enlace incorrecto, utilice https://code.visualstudio.com/insiders

@bpasero gracias. Tengo la compilación de información privilegiada ejecutándose con Salsa como servicio de lenguaje JS. Te haré saber cómo va todo el día siguiente más o menos

@bpasero , probé la liberación de información privilegiada y el problema aún existe, después de que una noche en inactivo VS Code se bloqueó.

@milenkovic @gwynjudd también tendrá que seguir los pasos para habilitar Salsa como se describe en https://github.com/Microsoft/vscode-docs/blob/vnext/release-notes/latest.md#javascript --- salsa- avance

@bpasero ,

¡Bueno oír eso! Sería interesante que otros pudieran verificar esto también intentándolo.

@bpasero Había habilitado salsa y lo dejé funcionando durante el fin de semana. Esta mañana se había estrellado.

Mecanografiado instalado

$ 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

He configurado settings.json para que sea

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

y el entorno

$ setx VSCODE_TSJS 1

SUCCESS: Specified value was saved.

Todavía no veo salsa en el pie de página de información privilegiada del código VS.

@nojvek Hice básicamente lo que hiciste tú, y veo Salsa en el pie de página, pero solo cuando un archivo .js está abierto y visible en el editor.

@gwynjudd Supongo que obtuviste el cuadro de diálogo de bloqueo y ahora con 0.10.8, ¿pudiste volver a abrir la ventana?

@bpasero sí, obtuve el nuevo cuadro de diálogo de bloqueo y pude reiniciar

Gwyn Judd

-------- Mensaje original --------
De: Benjamin Pasero
Fecha: 02/09/2016 19:13 (GMT + 12: 00)
Para: Microsoft / vscode
Cc: Gwyn Judd
Asunto: Re: [vscode] falla cuando se ejecuta durante la noche (# 508)

@gwyn juddhttps: //github.com/gwynjudd Supongo que obtuviste el cuadro de diálogo de bloqueo y ahora, con 0.10.8, ¿pudiste volver a abrir la ventana?

Responda a este correo electrónico directamente o véalo en Gi

@gwynjudd ¿ es este un espacio de trabajo exclusivo de JS u otros tipos de archivos como PHP incluido?

@bpasero hay muchos tipos de archivos, incluidos mecanografiado, java script, css, less, aspx, cs

Gwyn Judd

-------- Mensaje original --------
De: Benjamin Pasero
Fecha: 02/09/2016 22:49 (GMT + 12: 00)
Para: Microsoft / vscode
Cc: Gwyn Judd
Asunto: Re: [vscode] falla cuando se ejecuta durante la noche (# 508)

@gwyn juddhttps: //github.com/gwynjudd ¿ es este un espacio de trabajo solo de JS u otros tipos de archivos como PHP incluido?

Responda a este correo electrónico directamente o véalo en Gi

Con la nueva construcción se ha estrellado cada mañana al dejarla funcionando durante la noche. Solo tengo estas extensiones instaladas (en la nueva compilación, en la versión de lanzamiento tenía diferentes extensiones):

Esta mañana, cuando llegué al trabajo, no se había estrellado. No hice nada diferente antes de salir del trabajo el viernes.

Debería intentar reproducir con el espacio de trabajo de Chromium usando Ubuntu, ya que parece que @Tyriar tenía una configuración así cuando sucedió.

Siga las instrucciones aquí para obtener el código https://www.chromium.org/developers/how-tos/get-the-code

También noté un retraso en el código después de un tiempo de usarlo y eventuales fallas. Me di cuenta de que cuando se retrasa, puedo hacer que se ejecute con mayor fluidez si presiono F1 y escribo 'Recargar ventana'. Eso parece aclarar el problema por el momento y luego puedo solucionarlo por ahora. Definitivamente estoy interesado en ver esto arreglado.

Al leer este hilo, también supongo que se debe al proceso de renderizado, aunque no he hecho ninguna prueba con él, y parece suceder independientemente de la cantidad de archivos de trabajo en la lista en el panel del explorador, ya sea o no hay un archivo abierto cuando se carga el código, tal vez los tamaños de los archivos en los que se está trabajando actualmente, y no estoy seguro de si tiene algo que ver con el verificador de diferencias de git o no, pero dudo que sea el culpable .

También estoy en Mac OS X El Capitan 10.11.3 y realmente no había visto el problema en Windows cuando lo usé en casa, pero no tengo un árbol de trabajo enorme para ningún proyecto en casa, solo el carpeta masiva desde la que trabajo en el trabajo.

Espero que ambos problemas estén relacionados, pero me temo que es posible que no: la mayoría de las personas aquí ven que el código falla cuando lo deja en ejecución sin interacción del usuario, lo que parece muy sospechoso. Sin embargo, hacer que el código se bloquee eventualmente con una excepción de falta de memoria mientras lo usa durante mucho tiempo puede deberse a otras fugas de memoria. Idealmente, ambos problemas son iguales :)

Técnicamente, parece ralentizarse y bloquearse incluso si no lo estoy usando, pero no estoy seguro si ellos también experimentan lo mismo, en ese caso. De cualquier manera, los síntomas parecen similares al menos. Si se descubre que mi problema no está relacionado, podría crear un problema por separado.

@cwadrupldijjit si ve el problema de

Veré lo que puedo hacer. Normalmente pongo el mac a dormir por la noche, así no pasa nada durante ese tiempo. Intentaré mantenerlo puesto por la noche y te avisaré por la mañana si pasa algo. También te mantendré informado si puedes acceder a mi espacio de trabajo.

¡Suena bien. Gracias!

K. Así que dejé la instancia de código ejecutándose durante la noche y no tuve ningún problema con que se bloqueara o sintiera un retraso inmediato. Continué trabajando hoy, e incluso me tomé un pequeño descanso de usarlo mientras hacía otras cosas, y comenzó a retrasarse nuevamente. Casi parece que tal vez el problema no sea por usarlo activamente, pero también parece que algo más lo desencadenó durante el tiempo que he estado trabajando en él.

Ejecutaré el generador de perfiles para vigilarlo y crearé un nuevo problema si hay otros hallazgos diferentes a los explicados anteriormente.

No he comprobado si puedes tener acceso a mi espacio de trabajo, aunque sospecho que no puedo compartirlo contigo, desafortunadamente.

Intenté ejecutar el generador de perfiles ayer cuando se estaba volviendo particularmente lento y cuando estaba tomando una instantánea de la pila, la computadora se agotó al máximo de RAM disponible, y casi no pude hacer nada, ni siquiera forzar el cierre del código, así que tuve que reiniciar el ordenador. Intentaré ejecutarlo antes que antes para evitar que vuelva a suceder.

Esto es un poco fuera de tema, pero publicaste el enlace para la compilación de información privilegiada, que visité. Quería descargar la versión de Windows (ya que la uso en casa), y cada vez que intento acceder a ese enlace, primero me redirige a la página de descarga habitual, pero luego me redirige rápidamente a la página principal sin iniciar una descarga. De hecho, sobrescribe el historial de la página de descarga en la que estaba, por lo que ni siquiera puedo volver al historial para acceder a él. ¿Hay alguna otra forma en que pueda hacer que los de adentro construyan?

@cwadrupldijjit

Esto es un poco fuera de tema, pero publicaste el enlace para la compilación de información privilegiada, que visité. Quería descargar la versión de Windows (ya que la uso en casa), y cada vez que intento acceder a ese enlace, primero me redirige a la página de descarga habitual, pero luego me redirige rápidamente a la página principal sin iniciar una descarga.

Lo sentimos, pero algunos usuarios informaron un problema extraño en la compilación de información privilegiada y lo eliminamos temporalmente hasta que comprendamos este problema.

@egamma Me preguntaba si podría haber sido inaccesible por eso. Estaré atento a cuando funcione, entonces.

@Tyriar Probé el espacio de trabajo de

No estoy seguro de si esto está relacionado, pero he notado que VS Code tiende a fallar durante mi día de trabajo si lo abro y me olvido de él por un tiempo. Estoy en el trabajo durante 11 horas y generalmente abro el código a primera hora de la mañana. En algún momento durante el día, mi computadora se ralentizará y comenzará a colgarse hasta que se bloquee o lo fuerce a matarlo.

Por si acaso podría ayudar ...

El proyecto principal que tengo abierto en VS Code es una versión relativamente sin modificar de un carrito de compras llamado BVCart (versión 2004.7). Tengo alrededor de 25-30 archivos de trabajo en este momento e incluso abrir VS Code y no tocarlo en todo el día provoca un bloqueo.

El proyecto consta de 1836 archivos y 130 carpetas que suman alrededor de 35 MB y está contenido en un pequeño repositorio de git.

@ZombieProtectionAgency ¿ es posible compartir este espacio de trabajo conmigo?

@bpasero Lo siento, definitivamente no pude compartirlo :( No he mirado, pero es posible que pueda encontrarlo en línea en algún lugar. Es solo un carrito de compras ASP VB.Net anticuado en su mayoría plano. La gran mayoría de los archivos son .vb con aspx, ascx y un pequeño puñado de archivos css.

Tengo exactamente el mismo error. VS Code simplemente se bloquea cada pocos minutos. Lo estoy usando con olmo. No choca cuando se deja encendido. Choca minutos después de que empiezo a terminar el archivo. Ha sido así durante los últimos tres días haciendo que VS Code sea inutilizable. ¿Cómo verifico lo que está pasando? Estoy usando la versión 0.10.10.

Otro pensamiento que tuve: tenemos un servicio que puede recibir resultados de varios puntos finales (git, tareas, extensiones) y esto es algo que puede suceder en segundo plano y sumarse. Hicimos algunas correcciones en esta área para GA que no están en versiones anteriores.

Si alguien con fallas nocturnas pudiera verificar brevemente si hay algún resultado registrado desde el fondo. Puede ver eso desde Ver> Alternar salida y luego cambiar a través de los canales desde el menú desplegable.

@bpasero
En la salida de 'Tareas' solo veo la salida que esperaría de mi propia tarea de compilación.
En la salida 'Git', veo algunos git fetch, intercalados con algunos git shows. Sin embargo, no estoy seguro de con qué frecuencia, ya que no hay una marca de tiempo. Sin embargo, no hay otra salida.

Hacemos búsqueda automática de vez en cuando, pero la salida principal que ve probablemente proviene del trabajo que realiza dentro de VS Code. Sería interesante si la salida se suma cuando VS Code está en segundo plano. ¿La tarea se ejecuta constantemente o solo cuando invoca explícitamente la tarea de compilación?

La tarea es justo cuando ctrl + shift + B y finaliza poco después. Sin embargo, he tenido bloqueos cuando no he ejecutado una tarea.

Obtengo dos programas de git idénticos cuando cambio entre archivos y sí, los git fetch se producen automáticamente una vez cada dos minutos.

Tenga en cuenta que no realizo ningún pago, etc. dentro de VSCode, uso SourceTree para todas las tareas relacionadas con git.

@bpasero Dejaré la ventana de salida

Nuestra última versión de información privilegiada ya está disponible y agradecería que la gente pudiera intentarlo en este tema: https://code.visualstudio.com/insiders

@bpasero Todavía tenía la compilación de información privilegiada anterior, ¿puedo ejecutar eso y hacer "buscar actualizaciones", o tengo que actualizar la compilación desde el enlace que proporcionó?

Intentaré responderle. Para ser honesto, veo menos VSCode
se bloquea hoy en día. Al menos no se bloquea todos los días.

Puedo hacer que se bloquee abriendo un archivo enorme con más de un millón de líneas
js minificados y desplazarse hacia arriba y hacia abajo repetidamente. Pero yo se que es
empujando los límites del editor.

Lo que sea que hayas estado agregando como salsa mágica me está funcionando.

El miércoles 16 de marzo de 2016 a las 12:29 p. M., Benjamin Pasero [email protected]
escribió:

Nuestra última construcción de información privilegiada ya está disponible y agradecería que la gente pudiera
Pruébelo en este problema: https://code.visualstudio.com/insiders

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -197503185

@gwynjudd , debería poder actualizar si el logotipo de VS Code aparece como logotipo verde:

@nojvek sí, eso está empujando un poco los límites. para el lanzamiento de marzo hicimos pruebas de memoria explícitas para encontrar áreas en las que podamos mejorar. la compilación de información privilegiada incluye algunas de esas correcciones (no todas, hicimos algunos cambios ayer y hoy que aún no están incluidos). así que solo curiosidad por saber si hay alguna diferencia para las personas que ven esto ...

@bpasero gracias lo he hecho y te dejaré saber como te va

@bpasero todavía

Si por favor, gracias.

Aquí hay una instantánea del montón inmediatamente después de iniciar el código (uso de memoria de aproximadamente 100 MB en ese momento)

Heap-20160318T115937.zip

Lo intentaré de nuevo en una o dos horas. El truco parece ser que llega a un punto en el que la memoria ha aumentado un poco, pero no tanto como para que al tomar la instantánea se produzca un fallo de memoria.

Vi el mismo tipo de resultados cuando intenté tomar una instantánea del montón (me quedé sin memoria), y no es divertido.

Siento que todavía hay algunos problemas de memoria en la última compilación de información privilegiada (para mac). Veré si puedo obtener otra instantánea del montón sin sacrificar mi computadora.

@bpasero lo siento, todavía no he podido obtener una instantánea del montón. O la memoria es muy baja, como la que capturé antes, o salta para decir alrededor de 500 MB o más y tomar la instantánea provoca un bloqueo.

Tengo que reiniciar vscode 1 o 2 veces al día porque el uso de memoria supera 1 GB y las cosas empiezan a sentirse lentas. Está usando la cantidad de memoria que usaría un IDE completo, por lo que definitivamente hay alguna fuga.

@ vincent-ly, ¿puedes compartir más detalles sobre el espacio de trabajo con el que ves esto?

@bpasero Hay alrededor de 30-40 archivos js / scss / html que usan un par de componentes de bower con gulp (sin el corredor de tareas vscode). Trabajo con 2 paneles de editor y uso con frecuencia la búsqueda de archivos, bastante estándar. El uso de memoria es inferior a 100 MB al inicio, pero aumenta con el tiempo, incluso cuando se minimiza.

¿Intellisense juega un papel importante? Tengo instaladas definiciones de tipo Angular y jQuery.

Puede probar nuestra versión de información privilegiada donde trabajamos en la reducción de la presión de la memoria para ver si eso lo mejora: http://code.visualstudio.com/download?insiders=true

¿Tiene extensiones instaladas?

@bpasero Solo fragmentos angulares
https://marketplace.visualstudio.com/items?itemName=johnpapa.Angular1

Probaré la compilación de información privilegiada e informaré, ¡gracias!

+1

Viendo el mismo problema en VSCode para Windows 0.10.11 . Por lo general, se bloquea todas las noches de manera constante cuando no está en uso. Dados los pasos para recopilar información, estaría encantado de ayudar.

Se ejecuta en un repositorio git de TypeScript con 28,438 archivos, 4,812 carpetas. También tiene observadores de tragos, con muchas definiciones de TypeSript.

Tengo instaladas las siguientes extensiones:

• Potencia Shell
• C#
• Kit de temas de materiales

@alanwright, ¿ podría intentarlo si todavía se reproduce con nuestra última versión de información privilegiada? (http://code.visualstudio.com/Download#insiders). Si es así, ¿puedes compartir el espacio de trabajo conmigo?

@bpasero Se reprodujo de la noche a la mañana con información privilegiada. Lo intenté tanto en nuestro alistamiento privado más grande como en nuestro alistamiento de código abierto, y solo el alistamiento privado más grande pareció causar el problema, que desafortunadamente no puedo compartir (aunque es interno de Microsoft, así que tal vez podamos darte acceso. Alanwri)

¿Hay algo que pueda hacer en mi máquina para capturar registros y compartirlos con ustedes?

Por favor comparte conmigo mi alias benjpas, ¡gracias! También agradecería algunos detalles sobre cómo usa VS Code en ese espacio de trabajo para aumentar la memoria.

También estoy chocando durante la noche y durante el día.

No parece estar particularmente relacionado con solo un espacio de trabajo, espacios de trabajo extremadamente pequeños de 3 a 20 archivos o espacios de trabajo enormes, que se notan principalmente cuando se tienen varias ventanas abiertas.

Repos que he usado que se estrelló.
1500+ archivos asp, js, .inc (asp)
70 + archivos asp.net core, js, cshtml
Este repositorio (https://github.com/gogits/gogs)

@ eByte23 ¿se ejecuta con o sin extensiones? en que plataforma estas ¿Intentaste con la liberación de información privilegiada?

@bpasero Win10 y OSX con C # como extensión.
He probado información privilegiada, pero no he notado si se bloqueó ya que hay un error de tabulación, así que dejé de usarlo, pero puedo dejarlo funcionando durante la noche para intentar reproducirlo.

@ eByte23 sí, por favor. ¿Qué error de tabulación?

@bpasero parece estar en las dos últimas versiones de información privilegiada con mostrar espacios en blanco y convertir pestañas en espacios en blanco con un archivo con pestañas existentes que parece seguir tabulando y no escribir espacios incluso en nuevas líneas.

No había tenido la oportunidad de hacer una prueba completa, pero lo haré ahora.

@ eByte23 Le sugiero que informe algo así como un problema separado si cree que es uno. introdujimos una nueva configuración editor.detectIndentation que por defecto es true . Tal vez puedas intentar establecerlo en false .

@bpasero Mi
Probé Insider Yesterday durante la noche y también falló.

@bpasero parece que ustedes podrían estar

Invertimos bastante en la solución de fugas de memoria para la versión 1.0, por lo que esperaría que la situación fuera mejor con 1.0. Pero todavía hay casos en los que sucede.

Podría tener una nueva teoría porque descubrí recientemente que las aplicaciones de Electron (nuestro marco de interfaz de usuario) se ralentizan tan pronto como su ventana pierde el foco o se mueve al fondo. Me pregunto si esta limitación podría tener un impacto en el consumo de memoria.

Cada vez que probé la reproducción, dejé la ventana de VS Code abierta con el enfoque del teclado, por lo que tal vez una diferencia sea dejarla ejecutar en segundo plano.

Hay una forma de deshabilitar la limitación en segundo plano para poder producir una compilación con una bandera para habilitar esto.

De lo contrario, también sería interesante escuchar a la gente si un accidente después de minimizar es el escenario típico.

Todos mis fallos ocurrieron cuando VSCode no tenía el foco. Por lo general, sucedieron después de dejarlo en segundo plano todo el día mientras navegaba por Internet o usaba Visual Studio

Secundo esto. Recientemente experimenté un accidente. Fue con un VS en
trasfondo cuando me había concentrado en lo sublime la mayor parte del día.

El sábado 16 de abril de 2016 a las 11:44 a. M., Toni [email protected] escribió:

Todos mis fallos ocurrieron cuando VSCode no tenía el foco. Generalmente ellos
sucedió después de dejarlo en segundo plano todo el día mientras navegaba por
internet o usando Visual Studio

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -210872544

Experimentó un bloqueo al usar la compilación interna no hace mucho tiempo. Había estado encendido durante 2 días. De repente se volvió lento. La selección de texto con el mouse dejó de funcionar. Shift-Right funcionó pero muy lentamente. La aplicación se bloqueó unos minutos después de perder el enfoque.

Esta es mi primera falla para la compilación interna, pero en cuanto a la compilación normal, actualicé a v1.0 y todavía falla cada pocos minutos después de abrirse, lo que la hace inutilizable. Ni siquiera tengo que hacer nada especial. Ábralo, edite un archivo (principalmente archivos .elm) o simplemente déjelo estar y simplemente se bloquea. Ni siquiera espera perder el enfoque primero.

1.0 se bloquea casi todas las noches.
Windows 10 Ent.
Complementos: Corrector ortográfico y gramatical, ESLint

Ok, un comunicado de información privilegiada está disponible con mi cambio incluido. Estaría feliz de que alguien lo probara: http://code.visualstudio.com/Download#insiders

Alguien :)?

Usándolo ahora. No he tenido un accidente desde ayer.

@bpasero Actualizaré ahora y lo dejaré funcionando durante la noche y veré cómo vamos Salud :)

@bpasero Lo instalé el viernes pero luego me fui por un fin de semana largo, también

@bpasero Tuvo un accidente ayer. Me quedé despierto durante 3 días antes de estrellarse.

@bpasero Sigo viendo el bloqueo ocasional en la mañana con la última versión de información privilegiada

Yo también.
Windows 8

@bpasero Insider 1.1.0 se acumula mejor, tomó casi una semana antes de que fallara.

Recogeré 1.1.0 ahora y veré cómo va

Parece que no puedo tomar una instantánea del montón sin que se bloquee cuando el uso de la memoria es superior a 150 MB.

Todas las mañanas, desbloqueo mi computadora para encontrar que VS Code se ha bloqueado durante la noche.

• Mac OS X 10.11.4 (15E65)
• VS Code 1.1.0-información privilegiada

Normalmente dejo archivos abiertos. Corro con extensiones. ¿Hay alguna configuración que pueda usar para ayudar a recopilar más información de diagnóstico?

Nuestra nueva versión de insiders ya está disponible (http://code.visualstudio.com/Download#insiders) e incluye nuestro trabajo para pestañas / pilas. Esto viene con una disposición más agresiva de recursos porque tan pronto como cierra un editor, nos deshacemos de sus recursos subyacentes.

Es curioso que la gente pueda hablar de esto por un tiempo e informar si las cosas mejoran.

Nota: los iniciados a partir de ahora se actualizan todas las noches (consulte http://code.visualstudio.com/blogs/2016/05/23/evolution-of-insiders)

@bpasero Actualicé todos mis dispositivos hoy, mira cómo avanzamos los próximos días

Sí, me he mudado principalmente a personas con información privilegiada debido a la terminal. Oh cuanto yo
quiéralo. He descubierto que el editor es mucho más ágil y ligero. Buen trabajo.

¿Hay alguna forma de que pueda reemplazar "código"? En la línea de comando para apuntar a
iniciados?

El miércoles 8 de junio de 2016, Elijah Bate [email protected] escribió:

@bpasero https://github.com/bpasero Hoy he actualizado todos mis dispositivos,
mira cómo avanzamos los próximos días

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -224539214,
o silenciar el hilo
https://github.com/notifications/unsubscribe/AA-JVM4KoGeXoc2SU5VeEYnxkZyPVWYMks5qJo13gaJpZM4Gnvn5
.

Todavía está sucediendo en 1.2.0 para mí. Ocurre todas las noches: se ejecuta en Windows 7 Enterprise SP1. Tengo la misma pregunta que @garthk

Normalmente dejo archivos abiertos. Corro con extensiones. ¿Hay alguna configuración que pueda usar para ayudar a recopilar más información de diagnóstico?

@northerncodemky Me refería a la versión 1.3.0 para personas con información privilegiada donde se incluye nuestro trabajo de pestañas / pilas (http://code.visualstudio.com/Download#insiders). No esperaría muchos cambios en 1.2.0.

@bpasero Aah ok - no

@bpasero se ve bien hasta ahora !!

Tuve la compilación de VSCode Insiders ejecutándose durante el fin de semana. Llegó el lunes por la mañana y vi un accidente.

Me pregunto si hay datos de caída / volcado de telemetría que se envían automáticamente cuando VSCode falla. Algo así como los informes de Watson.

Conseguí una máquina nueva la semana pasada. Cuando lo configuré, solo puse la versión de lanzamiento (no los internos); no he notado que se bloquee desde entonces.

@bpasero No he visto ningún

@bpasero con pestañas habilitadas, abrió el proyecto ac # y vscode está fallando un par de minutos después de la última actualización del hash de confirmación interna: 5474147bb83618975409dad7d8aa96151d7d1ea1.
NOTA: anteriormente no había habilitado pestañas hasta ahora

@ eByte23 ¿puedes verificar que esto está relacionado con tener las pestañas habilitadas o no al intentarlo sin pestañas?

@bpasero sigue ocurriendo cuando las pestañas están deshabilitadas, pero no se acerca a la gravedad con las pestañas habilitadas.

Pero es muy notable y reproducible cuando se trabaja con imágenes, haciendo clic entre imágenes grandes rápidamente tanto en información privilegiada como en v1.2.1

@ eByte23 Sugiero abrir un nuevo número sobre eso con todos los detalles que pueda proporcionar (por ejemplo, ¿crece la memoria?).

Seguro que puedo hacerlo. Aún no he investigado mucho al respecto, pero les daré algunos detalles más adelante.

VSCode 1.3.1 se bloquea aproximadamente dos veces al día para mí, una vez durante la noche (siempre) y, a veces, al azar durante el día. Simplemente se bloqueó ahora mientras lo tenía abierto en segundo plano, sin usarlo durante aproximadamente 2 horas. Además, al abrir vscode nuevamente, pierde mi espacio de trabajo y tengo que volver a abrir la carpeta del proyecto que tenía abierta antes del bloqueo. Las pestañas y las divisiones se conservan después de volver a abrir la carpeta.

Lo dejé abierto en segundo plano por un tiempo con cambios no guardados, regresé, comencé a escribir y vscode se congeló durante unos segundos y luego se bloqueó. perdió mi trabajo.

Espero que puedas entender mi frustración. Esto es inaceptable para un editor. Además, la sesión que restauró ni siquiera tenía las pestañas correctas abiertas, ni mi lugar en cada pestaña.

@DelvarWorld ¿ puede compartir más detalles sobre su entorno de trabajo? ¿Puede intentar ejecutar con las extensiones desactivadas para ver si eso ayuda?

Tengo este mismo problema en Linux Mint 17 Qiana (¡no recuerdo qué versión de ubuntu es esa!). Simplemente me congeló después de ~ 2 horas de inactividad. Me acordaré de verificar el uso de memoria / CPU la próxima vez que suceda, aunque nunca he notado una desaceleración general en otras aplicaciones, etc.cuando esto sucede.

Información de VSCode:

Versión 1.4.0
Confirmar 6276dcb0ae497766056b4c09ea75be1d76a8b679
Fecha 2016-08-04T16: 49: 32.489Z
Concha 0.37.6
Renderizador 49.0.2623.75
Nodo 5.10.0

Este problema ha desaparecido para mí (en 1.5.3, Windows 7). Dado que el último comentario es de hace 2 meses, ¿se puede resolver esto?

Tampoco he visto que esto me ocurra en mucho tiempo. He estado usando la versión actual durante meses. Luce bien

Mismo. No parece sobrecargarse en absoluto.

Ok, deberíamos continuar con los problemas individuales y evitar errores monstruosos como este que son difíciles de rastrear. Si alguien sigue viendo este problema, presente nuevos problemas con más detalles. POR FAVOR, evite secuestrar un problema existente 👍

También recuerdo haber visto esto antes y no lo había visto en años, así que esa es mi verificación.