Vscode: Bater durante a noite em execução

Isso parece acontecer de forma consistente todas as noites que deixo o computador ligado. Parece que ele não está respondendo devido ao limite máximo da CPU. Talvez algum loop infinito esteja em algum lugar, talvez relacionado ao arquivo ou ao polling do repositório git?

Eu me pergunto se o sistema operacional decide colocar o VSCode (Electron na verdade) em um estado em que está causando esse travamento. Eu pinguei o Electron se eles tiverem uma pista.

Nunca aconteceu no Atom fyi, pelo menos no 1.19.x (da memória) e 1.2.4.

Tenho um problema semelhante, desde a atualização de novembro (0.10.2 / 0.10.3?). Quase todos os dias, eu logava para descobrir que minhas janelas VSCode deixadas durante a noite haviam travado (com o erro padrão de falha não informativo / apologético, "Visual Studio Code travou").

Hoje, após a atualização 0.10.5, tive meu primeiro travamento enquanto estava lá - infelizmente, não enquanto o estava usando ativamente.

Executando o VSCode no Windows 7 (64 bits), principalmente usando-o como um editor JS em um projeto muito grande - quase um milhão de linhas no total (incluindo libs que preciso pesquisar, portanto, não são excluídos). Sem problemas de desempenho no uso normal e não percebi nenhum uso excessivo de recursos que levou à falha de hoje.

Terei todo o gosto em fornecer registos / informações de erros mais detalhados se alguém puder indicá-los.

Estou tendo o mesmo problema básico de @ Elusive138 , quando deixo o código em execução durante a noite (todas as noites), pela manhã sem falha recebo "O código do Visual Studio travou".

Ainda repros para mim no vscode 0.10.5, Ubuntu 12.04

Tentei reproduzir no Windows 10, Mac OS 10.11 e Ubuntu 15 sem sorte. Estou suspeitando de um problema de falta de memória, mas para nenhum dos itens acima a memória estava aumentando muito.

Alguém pode tentar reproduzir isso com as seguintes condições:

• ele se reproduz ao abrir apenas uma instância vazia de código (Arquivo | Fechar pasta)
• reproduz ao abrir uma área de trabalho, mas não abre nenhum arquivo no editor

Ubuntu 12.04, vscode 0.10.5 não conseguiu reproduzir, deixando-o no fim de semana com uma instância vazia.

Pode muito bem ser um vazamento de memória sutil, evidenciado pela utilização de memória relativamente alta neste sistema.

Saí do computador por volta das 17h30, com a confirmação da memória do sistema aumentando lentamente - era 15.402 MB às 19h. Às 3h09 foi a abordagem mais próxima do limite de confirmação do sistema (17.682 MB) e o uso de confirmação caiu de 16.218 MB para 15.217 MB. Eu suspeito que foi aqui que o VSCode caiu. O uso do commit era estável por aí até que o registro parou por volta das 6h (sem espaço em disco - esses contadores de desempenho são grandes!)

Infelizmente, não incluí todos os processos VSCode, portanto, não tenho o registro específico do processo. Vou tentar isso esta noite.

Seria muito útil se eu conseguisse a hora da queda. O VSCode deixa registros em qualquer lugar?

Infelizmente, não incluí todos os processos VSCode, portanto, não tenho o registro específico do processo. Vou tentar isso esta noite.

Isso seria super útil, obrigado!

Atualmente o vscode não faz login no disco.

@ Elusive138 você pode compartilhar o espaço de trabalho no qual o vscode foi executado?

@bpasero Infelizmente não. É baseado em Ext JS, porém, e é onde está a maior parte do código (biblioteca). Vou tentar um espaço de trabalho Ext JS limpo depois que esse outro teste for concluído e ver se ele será reprojetado lá.

@ Elusive138 sim, seria bom ter uma amostra para reproduzir do nosso lado.

Um dos processos code.exe (código # 3 no log, em anexo) parece estar vazando. O commit começou por volta de 200 MB às 17h30 e atingiu 460 MB por volta das 9h do dia seguinte, com um aumento constante:

A contagem de identificadores não aumenta.

vscode_memleak.zip

Não houve travamento dessa vez, talvez porque eu não tivesse tantos outros programas que usam muita memória em execução. Pode ser capaz de testar isso em uma VM com um limite de confirmação baixo mais tarde.

Este registro foi criado durante a noite com 3 grandes espaços de trabalho abertos em janelas diferentes. Vou tentar restringi-lo a um espaço de trabalho que eu possa compartilhar.

@ Elusive138 , seria útil entender os detalhes do processo que vaza. Você pode encontrar seu PID e imprimir seus metadados completos usando ps aux | grep <pid> ?

Ah, talvez seja no Windows, não tenho certeza :)?

@bpasero A linha de comando é:

"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

Outros detalhes:

A árvore do processo:

Isso depois de mais um dia inteiro de uso. Como você pode ver, o uso de memória do processo parece ter aumentado linearmente naquele tempo (mesmo espaço de trabalho).

Ah ... este não é nem mesmo o realmente ruim.

4772 foi o processo que vazou durante a noite. O outro parece ter subido devido ao meu uso durante o dia ... eu acho.

@ Elusive138 parece que você tem várias janelas abertas com o Code, é verdade?

@bpasero Sim, o teste da noite passada teve três janelas abertas com diferentes espaços de trabalho. Vou tentar hoje à noite com apenas um, em um espaço de trabalho Ext JS limpo, conforme mencionado acima.

Parece bom!

Infelizmente, sem reprodução ... isso é estranho. O que poderia estar causando um vazamento naquele projeto específico?

Falando nisso, pode ser diferente do problema inicial do @Tyriar . O dele não respondeu, o meu e o gwynjudd estão travados com a caixa de diálogo de erro ..? Nesse caso, talvez devêssemos fazer um novo problema ...

@ Elusive138 estranho. ele se reproduz se você apenas abrir aquele espaço de trabalho sem abrir nenhum arquivo JS?

Além disso, talvez possamos começar a criar o perfil disso usando as ferramentas de desenvolvedor do Chrome, onde você pode fazer instantâneos de heap. Para isso, basta fazer um instantâneo antes e depois de algum tempo para ver para onde vai essa memória.

@bpasero Oh, esqueci completamente essas ferramentas de desenvolvimento. Vou tentar esta noite.

@bpasero Instantâneos de pilha de Main.js , workerMain.js e workerMain.js (2) realmente não mudam. Por talvez 5 MB no máximo.

Adicionando mais na minha situação, tentei executá-lo com uma pasta aberta (a que travou), mas sem arquivos de trabalho e não aconteceu durante a noite. Portanto, isso só acontece quando uma pasta está aberta e há arquivos de trabalho ativos.

@ Elusive138 ,

@Tyriar pode ser mais específico sobre o que você quer dizer com isso. é que você não abriu nenhum arquivo no editor ou que literalmente tinha a seção de arquivos de trabalho vazia?

O motivo pelo qual estou perguntando sobre a abertura de um arquivo ou não é que, por exemplo, o serviço de linguagem JS só começa quando você abre um arquivo JS. O mesmo se aplica a qualquer outro serviço linguístico. Portanto, se esse problema for reproduzido sem abrir um arquivo no editor, é provável que o vazamento de memória não esteja em nenhum serviço de idioma, mas em outro lugar.

Outra coisa que vale a pena tentar: execute sem nenhuma extensão para ver se talvez uma extensão esteja vazando. Você pode executar com --disable-extensions para fazer isso.

@bpasero Tenho certeza que a linha de comando fornecida acima era para 4772, a destacada (vazada) na imagem. Diz --type=renderer .

Vou deixá-lo funcionando no fim de semana novamente e ver o que acontece. Acho que ainda não fiz um teste limpo sem nenhum arquivo JS aberto.

@bpasero creio não ter nenhum arquivo aberto (à direita), apenas arquivos funcionando acima da árvore. Se eu me lembrar quando terminar o trabalho, tentarei verificar com um arquivo aberto e observarei o idioma.

Não sei ao certo, mas provavelmente não era um arquivo JavaScript quando o meu travou, mais provavelmente C ++, Java ou nenhuma linguagem. Vou verificar.

@Tyriar se reproduz apenas por ter algo em arquivos de trabalho e com todos os editores fechados (desde o início - isso é importante), podemos estar no

@bpasero Posso tentar abrir várias instâncias em condições variadas antes de sair do trabalho na sexta-feira e ver se consigo tirar todas as minhas experiências do caminho em uma noite. A menos que você tenha motivos para acreditar que uma instância de suspensão do vscode quebraria todas as outras.

@Tyriar sim, totalmente, se você tiver mais de uma janela aberta, tudo isso aumenta a memória total que está sendo usada e todas elas travariam. Isso ocorre porque, quando você abre várias janelas, elas ainda compartilham todos os processos pai e um limite de memória de algo como 1-1,5 GB. Para realmente entender de onde vem o vazamento, seria melhor medir 1 janela isolada sob estas condições:

• nenhuma extensão habilitada via --disable-extensions (uma extensão que consome muita memória ou vazamentos também causaria um travamento)
• nenhum arquivo aberto na inicialização (apenas fechando um arquivo após a inicialização já é tarde demais)
• nenhum arquivo de trabalho em arquivos de trabalho

btw, a única coisa para arquivos de trabalho que pode ter um impacto é que para cada arquivo de trabalho que não está dentro da área de trabalho, instalamos um observador de arquivos para observar as alterações. talvez isso cause o vazamento, seria surpreendente. Além disso, não instalamos um inspetor se o arquivo estiver dentro da área de trabalho aberta, apenas para arquivos externos.

@bpasero Sem vazamentos quando não há arquivos abertos (?). Vou tentar limpar o espaço de trabalho hoje à noite, depois de me certificar de abrir alguns.

Tentei no fim de semana com a seguinte configuração:

1. Lance com Code --disable-extensions
2. Abra um arquivo JavaScript de aproximadamente 1300 linhas

A memória e a CPU eram aproximadamente as mesmas na sexta à noite e na segunda de manhã.

@Tyriar era apenas abrir um espaço de trabalho vazio com um arquivo ou abrir primeiro uma pasta e depois um arquivo dela?

@bpasero Abrindo um espaço de trabalho vazio, não abri uma pasta e nenhuma pasta estava aberta quando abri

OK bom saber. Portanto, isso parece estar relacionado a ter uma pasta (potencialmente grande) aberta. Ainda falta saber se apenas abrir essa pasta é suficiente ou ter um arquivo aberto apenas aciona.

@bpasero Eu tinha uma grande pasta aberta sem arquivos abertos no fim de semana, sem aumento perceptível no uso de memória. Em cerca de 7 horas, terei os resultados de um teste de abertura de pasta e arquivo grande com uma área de trabalho reproduzível / compartilhável.

@bpasero a pasta na qual experimentei travamentos antes teria de 13.000 a 14.000 arquivos, isso inclui o repositório git que estava em torno de 2.000 sozinho.

Acho que vou verificar se o travamento ainda acontece na versão mais recente, pois já faz um tempo que não o vejo (devido aos testes).

E presumo que seja um espaço de trabalho JS?

@bpasero py, cpp, js, html, css

Ok, isso parece reproduzir o uso de memória que aumenta lentamente, se em uma escala menor: /ext/build/ext-all-debug.js aberto.

(Sim, é um 7z dentro de um zip ... GitHub não me permite fazer upload de um 7z ou xz diretamente, e zip e gzip são muito grandes)

@ Elusive138 quanto isso aumenta para você no avg? Tive o espaço de trabalho com alguns arquivos JS abertos por 2 horas agora sem nenhum aumento na memória.

@bpasero Desculpe, estou tendo problemas para reproduzir novamente. Acho que tive um repositório git perdido em uma tentativa anterior, que não foi incluído no arquivo acima. Avisarei quando tiver resultados mais concretos.

Seria muito útil se fosse possível abrir várias instâncias independentes ... ser limitado a um teste por noite é muito lento. Por acaso você carrega os sinalizadores do Chromium para perfis separados?

É possível construir várias versões de código que podem ser executadas em paralelo, embora não tenhamos documentado isso. Se você alterar os valores em https://github.com/Microsoft/vscode/blob/master/product.json para que sejam diferentes e, em seguida, construir a partir da linha de comando, você pode iniciar várias instâncias distintas. Os identificadores que devem ser únicos são:

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

Windows 8.1. Em Code, abriu uma pasta para um repositório git contendo 39.000 arquivos pela manhã.
Fiz muito pouco com ele, algumas pequenas edições em alguns arquivos.
Ao final do dia, o tamanho do commit relatado pelo Gerenciador de tarefas era de 672.164 mil.
Ele cresceu constantemente durante todo o dia, mesmo quando eu não estava no programa.

@gushie alguma chance deste

@bpasero Desculpe, não tenho permissão para compartilhar o repositório em si, mas se houver algum detalhe sobre ele que possa ajudar, excluindo o conteúdo do arquivo em si, me avise. O processo começa inicialmente em torno de 110 MB, cresce rapidamente para cerca de 130 MB antes de voltar aos 90 MB. Então, ele crescerá de forma constante a partir deste ponto. (Existem 5 outros processos code.exe que variam de 4 MB a 30 MB, mas estes não aumentam notavelmente. Existe apenas uma janela de código)

Não sei qual era o tamanho do commit final de ontem, pois o processo havia travado quando voltei a ele hoje.

@gushie Tenho usado o Monitor de desempenho nos processos code.exe para monitorar o "Tamanho privado".

É muito chato não podermos compartilhar os espaços de trabalho com os quais temos problemas! Eu me pergunto se alguém encontrou isso com algo de código aberto. Procurando por semelhanças: seu repo já foi usado com git-svn?

@bpasero Obrigado, se o processo que eu deixei não foi reproduzido quando eu voltar na segunda-feira, posso tentar construir algumas cópias adicionais. Precisaria descobrir como controlar qual é qual, embora ... isso pode ser um problema.

@ Elusive138 Usamos ferramentas Atlassian, então SourceTree conectando-se a um servidor Stash privado

Ah, isso é completamente diferente do meu. Era um repositório Git local (com extensões Git) conectando-se a um servidor SVN. Meu teste atual é com um repositório git baseado no vscode ... espero que ele repro e eu possa compartilhá-lo.

@gushie se reproduz se você apenas abrir o espaço de trabalho sem abrir nenhum arquivo? tente primeiro fechar todos os arquivos e reinicie para obter esta configuração. se isso não reproduz, reproduz se você abrir o espaço de trabalho e abrir um arquivo JS e deixá-lo assim?

@bpasero Eu já tinha deixado aberto com apenas um único arquivo de trabalho não editado ontem à noite, e verificando esta manhã o uso de memória não parece ter mudado muito. Agora editei e fiz uma compilação no arquivo e vou deixar isso para ver o que acontece.

Observe que, até ler esta edição, eu nunca havia apagado os arquivos de trabalho. (Eu realmente não precisava, geralmente ignorei este painel e troquei os arquivos por meio do explorador de arquivos do projeto abaixo dele ou com Ctrl + E).

Quebrou novamente, desta vez após o uso regular, mas foi deixado neste estado:

• ~ 14000 pasta de arquivos aberta
• 5 arquivos de trabalho ativos (.cc, .java, .h, .py, .json)
• Nenhum arquivo aberto no editor de texto

ps aux output:

❯ 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

Conforme mencionado, isso ocorreu após o uso regular e não no modo de segurança, então _poderia_ ser devido a uma extensão?

Deixei um único arquivo com uma pequena edição aberta, apenas esse arquivo nos arquivos de trabalho. Caso contrário, intocado o dia todo. A memória não aumentou de seu valor inicial.

@Tyriar bem, o processo que você está mostrando é nosso serviço de observação de arquivos e no Linux / Mac usamos Chokidar para isso (https://github.com/paulmillr/chokidar). Isso indicaria que eles têm um vazamento ao assistir os arquivos. Existe alguma tarefa de construção em execução e alteração constantes de arquivos?

@gushie foi isso sem abrir uma pasta?

@bpasero Eu estava com a pasta aberta. Obviamente, existe alguma ação que parece iniciar os vazamentos de memória além da abertura inicial de um arquivo dentro da pasta. Vou continuar a monitorar e tentar restringi-lo.

@bpasero Esse foi o único processo relacionado ao vscode que pude ver na saída. É possível que não estivesse visível na saída porque já estava encerrado devido à falta de resposta? Como mostrado, esse processo estava usando apenas 0,5% da memória e 0% da CPU. Acho que, de acordo com minhas descobertas recentes, o problema que estou enfrentando provavelmente não é devido a um serviço JS.

A propósito, mesmo se não encontrarmos o motivo para isso até o final do mês, eu empurrei uma alteração para que a caixa de diálogo de travamento que você obtém por padrão selecione uma ação para reabrir a janela para que você possa continuar a trabalhar de onde parou. Isso também é bom para o caso em que você tem várias janelas abertas e apenas uma delas trava.

(uma coisa está faltando e para o futuro é ser capaz de liberar periodicamente o estado da IU para o disco para que a reabertura também restaure seu ambiente de trabalho anterior)

@bpasero : +1: isso seria útil.

O VS tem travado todas as manhãs há cerca de um mês. Eu cheguei ao fim da minha paciência.

Espero que isso esteja sendo tratado como um bug PRI 0 porque qualquer editor são não deve travar com tanta frequência.

Informe como posso descobrir por que isso está acontecendo. Já vi isso acontecer em outras máquinas também.

@nojvek você pode compartilhar comigo o espaço de trabalho onde isso acontece?

Não tenho certeza do que você entende por compartilhar espaço de trabalho. É um projeto typescript / HTML / CSS com um pouco de c ++. Cerca de 1.500 arquivos e 80.000 linhas de código.

Existe uma maneira no VS de mostrar crashdumps?

@nojvek , gostaria de ter um espaço de trabalho com o qual possa executar o código para reproduzir este problema. Suspeitamos que esteja relacionado a um vazamento de memória em algum lugar, mas não está claro onde. Se você pode me enviar um zip do espaço de trabalho ou talvez a URL do git se for de código aberto.

Benjamin,

É um código-fonte interno da Microsoft e não acho que posso dar a você.

Se houver alguma ferramenta de monitoramento de memória que eu possa adicionar, me avise.

Funcionaria se eu tirar instantâneos da memória com o depurador do Chrome integrado
em vscode a cada duas horas para ver o que está acontecendo?

No sábado, 23 de janeiro de 2016, Benjamin Pasero [email protected]
escrevi:

@nojvek https://github.com/nojvek Eu gostaria de ter um espaço de trabalho que
Posso executar o código com para reproduzir esse problema. Suspeitamos que esteja relacionado a um
vazamento de memória em algum lugar, só não está claro onde. Se você pode me enviar um zip
do espaço de trabalho ou talvez a URL git se for de código aberto.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -174192367.

Sim, os instantâneos da memória ajudarão se e somente se esse vazamento estiver dentro do lado principal do VS Code. No entanto, parece que pelo menos em um caso o vazamento foi em um dos processos que geramos (o inspetor de arquivos). Talvez você possa identificar usando o explorador de processos, que processo está constantemente aumentando em termos de consumo de memória.

Se ajudar a me fornecer o código-fonte: eu trabalho para a Microsoft;)

Vou dar uma palavrinha com meu empresário. Isso está no repositório do Windows, então terei que
tenha um pouco de cuidado.

Pela discussão, parece que o chokidar é usado para o observador de arquivos. Um tempo
de volta eu brinquei com o código-fonte. Foi um pouco de espaguete.

Vou ver se consigo carregar chokidar em seu próprio aplicativo de nó simples e ver se é
o culpado.

Btw quaisquer razões específicas porque vs precisa usar chokidar? Ha outro
observadores de arquivos de plataforma cruzada, certo?

No domingo, 24 de janeiro de 2016, Benjamin Pasero [email protected]
escrevi:

Sim, os instantâneos de memória ajudarão se e somente se esse vazamento estiver dentro do principal
lado do Código VS. No entanto, parece que pelo menos em um caso o vazamento foi
em um dos processos que geramos (o observador de arquivos). Talvez você possa
identificar usando o explorador de processos, que processo está constantemente aumentando em
termos de consumo de memória.

Se ajudar a me fornecer o código-fonte: eu trabalho para a Microsoft;)

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -174269028.

Chokidar é usado no Mac e Linux, se você estiver no Windows, usamos um observador de arquivos C #. Estou feliz em aceitar um PR com uma solução de observador de arquivo cruzado funcional e de alto desempenho :)

Você sabe que, a partir do nó 4.0, o fs.watch está estabilizado no Windows e no Mac. Consulte: https://github.com/Microsoft/TypeScript/issues/4643.

Typescript tem uma lógica de monitoramento de arquivo / diretório de plataforma cruzada bastante sólida. https://github.com/Microsoft/TypeScript/blob/931d162620c7e09377c12875834e1838c4cdd51b/src/compiler/sys.ts

Vou tentar obter um build local do código VS com uma alteração e ver se ele ainda trava. Se não, definitivamente enviarei um PR.

Eu sei que ficou muito melhor usando a chamada de observação recursiva no diretório e, assim, evitando ter que anexar um ouvinte de observação por pasta, mas acho que os eventos às vezes ainda perdem o nome do arquivo / pasta, pelo menos em alguns casos. Eu me sinto mais confiante usando C # aqui.

Consegui uma reprodução hoje. Acabei de travar antes de abrir o console de ferramentas do desenvolvedor para tirar um instantâneo da memória.

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

Parece que o servidor de digitação está ocupando cerca de 200 MB.
O renderizador consumiu cerca de 800 MB e então travou.

Quando tiver cerca de 500 MB de uso, tentarei fazer um instantâneo da memória. O processo --renderer é o processo do webkit certo?

Isso foi depois de dois dias desde a última vez que vi um acidente. Parece que usar a ferramenta por um período de 8 horas editando muitos arquivos TS aumenta o uso mais rápido.

Legal, o processo de renderização é o processo principal para o editor. Se você puder fazer um instantâneo da memória lá, isso nos levará mais longe. Infelizmente, o instantâneo não funcionaria para nenhum outro dos processos, mas esses parecem estar ok'ish.

É normal que o tscse (servidor typescript) consuma 200 MB?

Na terça - feira, 26 de janeiro de 2016 às 21h29, Benjamin Pasero
escrevi:

Legal, o processo de renderização é o processo principal para o editor. Se vocês
pode fazer um instantâneo da memória lá, isso nos traria mais longe. Infelizmente, o
instantâneo não funcionaria para qualquer outro dos processos, mas aqueles parecem
seja ok'ish.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -175408302.

Sim, muito facilmente.

Ri muito! Eu estava no processo de obter um instantâneo do heap e o VS travou.

Vou tentar de novo e ver se tenho melhor sorte amanhã.

Existe uma maneira de dizer ao vscode para aumentar seu limite de memória para que ele não trave ao tentar obter um instantâneo de heap?

Acho que o que acontece é que, ao tirar o instantâneo, você causou uma exceção de falta de memória: - /. Não há como alterar o limite de memória, ele é codificado no V8.

Talvez tente tirar o instantâneo um pouco mais cedo, antes que o uso de memória aumente tanto? É um aumento gradual?

Não fui capaz de reproduzir (sem travamentos, uso de memória razoável) nas últimas duas semanas ou mais. A única diferença que consigo pensar é a atualização da extensão do PowerShell de 0.1.0 para 0.3.1 - mas eu não tenho nenhum arquivo PS no espaço de trabalho de qualquer maneira, e travou com as extensões desativadas no momento.

Eu obtive um despejo bem-sucedido de cerca de 300 MB usado pelo processo --renderer. Ele travou 10 segundos depois que tirei o lixo.

Parece que a maior parte do uso está na árvore DOM.

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

Espero que isto ajude.

Hmmmm, eu me pergunto se o criador de perfil está dizendo a verdade real aqui. Vejo todos os elementos da árvore e podemos também ter um vazamento na árvore, mas ficaria surpreso se esse vazamento pudesse causar falta de memória em um período tão curto de tempo.

Eu dei mais algumas lixeiras.

Parece que a abertura de arquivos .min.js causa um grande salto na memória. Mesmo depois de fechar os arquivos, a memória não parece diminuir. Entre todos os despejos de memória, parece que o DOM é o dominador.

Também não sei por que havia dois processos de renderização. Pode ser um deles foi o cromo devtools. Mas cheguei muito perto de 1 show.

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

Eu fiz uma captura de tela dos dois processos consumindo cerca de 500 MB de RAM.

Sim, um é devtools. Espera-se que a memória aumente quando você abre arquivos. Mas eu gostaria de entender como um código do VS que está sendo executado durante a noite sem atividade aumenta o uso de memória até travar.

Bem, a reprodução é:
Comece vs código.
Abra um ou dois arquivos js / ts em uma pasta grande com muitos arquivos .tsconfig.
Faça alguma rolagem / edição.
Feche todos os arquivos de trabalho.
Coloque-o no mesmo a 200c durante a noite.
Bolo!

Na sexta-feira, 29 de janeiro de 2016, Benjamin Pasero [email protected]
escrevi:

Sim, um é devtools. Espera-se que a memória aumente quando você abre
arquivos. Mas eu gostaria de entender como um código VS que está atropelando
noite sem atividade aumenta o uso da memória até travar.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -177087988.

@nojvek Os .tsconfig s são necessários para a reprodução? porque eu tive travamentos no passado sem nada relacionado ao TS. Embora eu não possa nem reproduzi-los mais ...

Nosso projeto simplesmente os possui. Pode ser uma pista falsa.

No sábado, 30 de janeiro de 2016, Bob [email protected] escreveu:

@nojvek https://github.com/nojvek Os .tsconfigs são necessários para
repro? porque eu tive travamentos no passado sem nada relacionado ao TS em
todos. Embora eu não possa nem reproduzi-los mais ...

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -177198518.

Os únicos arquivos. * Que temos em nossa pasta são a pasta .git e .gitignore

@nojvek, você está usando um servidor de

@bpasero @nojvek se for um problema de memória no lado JS. Você pode diferenciar o instantâneo heap no Chrome.

1. Tire uma foto instantânea.
2. Execute a ação que causa vazamento de memória.
3. Forçar coleta de lixo. Caso contrário, o próximo instantâneo de heap incluirá os objetos.
4. Tire outra foto.
5. Diferencie ambos os instantâneos.

Tudo pode ser feito no Chrome Devtools acima. A força da coleta de lixo está na guia da linha do tempo, o ícone de lixo. E a comparação é feita simplesmente escolhendo-o no explorador de instantâneos no menu de filtro.

Apenas relate quais objetos são retidos e possíveis caminhos de retenção (logo abaixo da tabela de heap). E esses são todos os dados necessários para corrigir esse problema.

Não precisa esperar um dia inteiro para coletar dados sobre uma falha: wink:

O link do Dropbox que enviei tinha três fotos instantâneas tiradas com meia hora de intervalo.
Eu não fiz a coleta forçada de lixo. Vai dar um truque.

No domingo, 31 de janeiro de 2016, Tingan Ho [email protected] escreveu:

@bpasero https://github.com/bpasero @nojvek https://github.com/nojvek
se for um problema de memória no lado JS. Você pode diferenciar o instantâneo do heap em
Cromada.

1. Tire uma foto instantânea.
2. Execute a ação que causa vazamento de memória.
3. Forçar coleta de lixo. Caso contrário, o próximo instantâneo de heap
   incluem os objetos.
4. Tire outra foto.
5. Diferencie ambos os instantâneos.

Tudo pode ser feito no Chrome Devtools acima. A força do lixo
coleção está na guia da linha do tempo, o ícone de lixo. E o diferencial é
feito apenas escolhendo-o no explorador de instantâneos no menu de filtro.

Apenas relatar quais objetos são retidos e possíveis caminhos retidos (logo abaixo
a tabela heap). E esses são todos os dados necessários para corrigir esse problema.

Não precisa esperar um dia inteiro para coletar dados sobre uma falha [imagem:
:piscadela:]

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -177462412.

Eu tenho o mesmo problema, o VS Code está constantemente travando, não apenas durante a noite, mesmo após 30min de inatividade.
Estou usando o Windows 7 de 64 bits e a versão mais recente do VS Code. Em relação ao projeto em si, é um grande projeto js, ​​com node_modules e bower_components também carregados. Ao todo são cerca de 40K de arquivos.

Passos para reproduzir:
1) Abra a pasta do projeto (com muitos arquivos), abra vários arquivos para que eles possam estar na lista de Arquivos de Trabalho.
2) Abra o gerenciador de tarefas.
3) Coloque o cursor para focar algum arquivo no VS Code
4) Observe como a memória aumenta com o tempo.

As pessoas com espaços de trabalho JS vendo este problema podem dar aos nossos insiders 0.10.7 uma tentativa (https://vscode-builds.azurewebsites.net/insider) com a opção de usar Salsa como serviço de linguagem JS: https://github.com /Microsoft/vscode-docs/blob/vnext/release-notes/latest.md#javascript --- salsa-preview

Obrigado!

1 para este problema. Também aparecendo no Windows. É totalmente irritante e eu não gosto disso.

@bpasero Eu gostaria de experimentar a nova compilação, mas sempre que tento acessar o link que você forneceu (https://vscode-builds.azurewebsites.net/insider), recebo uma página de mensagem de erro muito inútil com o seguinte texto :

Assinar em
Desculpe, mas estamos com problemas para fazer seu login.
Recebemos um pedido incorreto.

Informações técnicas adicionais:
ID de correlação: e477dc1b-c193-4cf9-864b-1d3fdbba4f34
Timestamp: 2016-02-03 19: 37: 17Z
AADSTS50020: A conta de usuário ' [email protected] ' do provedor de identidade ' https://sts.windows.net/5a7d8144-6966-4b1e-8147-de672a307ea0/ ' não existe no locatário 'Microsoft' e não pode acessar o aplicativo ' 9d5f02f6-ffd9-4e80-92d5-e42c85e09bc9 'nesse locatário. A conta precisa ser adicionada como um usuário externo no locatário primeiro. Saia e entre novamente com uma conta de usuário diferente do Azure Active Directory.

Não consigo fazer o download da compilação e testá-la devido a esse problema.

Desculpe, link errado, use https://code.visualstudio.com/insiders

@bpasero thanks Eu tenho os insiders construindo rodando com Salsa como serviço de linguagem JS. Eu vou te dizer como vai no dia seguinte ou depois

@bpasero , tentei o lançamento

@milenkovic @gwynjudd você também terá que seguir as etapas para habilitar Salsa conforme descrito em https://github.com/Microsoft/vscode-docs/blob/vnext/release-notes/latest.md#javascript --- salsa- antevisão

@bpasero , Você estava certo, ativar o Salsa corrigiu o problema. Deixei o VS Code aberto no fim de semana e ainda não travou.

Bom ouvir isso! Seria interessante se outras pessoas também pudessem verificar isso tentando.

@bpasero Eu habilitei a salsa e deixei rodando no fim de semana. Esta manhã havia quebrado.

Texto datilografado 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

Eu defini settings.json para ser

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

e o ambiente

$ setx VSCODE_TSJS 1

SUCCESS: Specified value was saved.

Eu ainda não vejo salsa no rodapé do VS code insider.

@nojvek Eu fiz basicamente o que você fez e vejo Salsa no rodapé, mas apenas quando um arquivo .js está aberto e visível no editor

@gwynjudd Suponho que você tenha obtido a caixa de diálogo de travamento e agora com a saída 0.10.8 conseguiu reabrir a janela?

@bpasero sim, recebi a nova caixa de diálogo de travamento e poderia reiniciar

Gwyn Judd

-------- Mensagem original --------
De: Benjamin Pasero
Data: 02/09/2016 19:13 (GMT + 12: 00)
Para: Microsoft / vscode
Cc: Gwyn Judd
Assunto: Re: [vscode] Falha ao executar durante a noite (# 508)

@gwyn juddhttps: //github.com/gwynjudd Presumo que você tenha recebido a caixa de diálogo de travamento e agora com 0.10.8 de saída conseguiu reabrir a janela?

Responda a este e-mail diretamente ou visualize-o em Gi tHubhttps: //github.com/Microsoft/vscode/issues/508#issuecomment -181726111.

@gwynjudd este é um espaço de trabalho apenas JS ou outros tipos de arquivo como PHP incluídos?

@bpasero, existem muitos tipos de arquivo, incluindo typescript, java script, css, less, aspx, cs

Gwyn Judd

-------- Mensagem original --------
De: Benjamin Pasero
Data: 02/09/2016 22:49 (GMT + 12: 00)
Para: Microsoft / vscode
Cc: Gwyn Judd
Assunto: Re: [vscode] Falha ao executar durante a noite (# 508)

@gwyn juddhttps: //github.com/gwynjudd este é um espaço de trabalho somente JS ou outros tipos de arquivo como PHP incluídos?

Responda a este e-mail diretamente ou visualize-o em Gi tHubhttps: //github.com/Microsoft/vscode/issues/508#issuecomment -181786273.

Com a nova compilação, ele travava todas as manhãs ao deixá-lo funcionando durante a noite. Eu tenho apenas estas extensões instaladas (na nova compilação, na compilação de lançamento eu tinha extensões diferentes):

Esta manhã, quando cheguei ao trabalho, não havia quebrado. Não fiz nada diferente antes de sair do trabalho na sexta-feira.

Devia tentar reproduzir com o espaço de trabalho do Chromium usando Ubuntu, pois parece que @Tyriar tinha uma configuração parecida com essa quando aconteceu.

Siga as instruções aqui para obter o código https://www.chromium.org/developers/how-tos/get-the-code

Também notei um atraso no código após algum tempo de uso e eventuais travamentos. Percebi que, quando fica lento, consigo fazer com que ele funcione mais suavemente se pressionar F1 e digitar 'Atualizar janela'. Isso parece esclarecer o problema por enquanto e, por enquanto, posso contorná-lo. Estou definitivamente interessado em ver isso corrigido.

Ao ler este tópico, também estou supondo que é devido ao processo de renderização, embora eu não tenha feito nenhum teste com ele, e parece acontecer independentemente da quantidade de arquivos de trabalho na lista no painel do explorador, seja ou não um arquivo é aberto quando o código é carregado, talvez os tamanhos dos arquivos atualmente sendo trabalhados, e não tenho certeza se isso tem alguma coisa a ver com o verificador de diferenças git ou não, mas duvido que seja o culpado .

Eu também estou no Mac OS X El Capitan 10.11.3 e não tinha realmente visto o problema no Windows quando o usei em casa, mas não tenho uma enorme árvore de trabalho para nenhum projeto em casa, apenas o pasta enorme em que trabalho no trabalho.

Espero que os dois problemas estejam relacionados, mas temo que não: a maioria das pessoas aqui vê o Code travando ao ser deixado em execução sem qualquer interação do usuário, o que parece muito suspeito. No entanto, fazer o código travar com uma exceção de falta de memória ao usá-lo por um longo tempo pode ser causado por outros vazamentos de memória. Idealmente, os dois problemas são iguais :)

Tecnicamente, ele parece ficar lento e travar, mesmo se eu não o estiver usando também, mas não tenho certeza se eles também têm a mesma experiência, nesse caso. De qualquer forma, os sintomas parecem pelo menos semelhantes. Se for descoberto que meu problema não está relacionado, posso criar um problema separado.

@cwadrupldijjit se você observar o problema de travamento durante a noite, seria útil obter acesso ao espaço de trabalho, se possível.

Verei o que posso fazer. Normalmente coloco o mac para dormir à noite, então nada acontece durante esse período. Vou tentar mantê-lo ligado à noite e avisar você pela manhã se algo acontecer. Também vou mantê-lo informado se puder acessar meu espaço de trabalho.

Parece bom, obrigado!

K. Então, deixei a instância do código em execução durante a noite e não tive nenhum problema com ela travar ou parecer imediatamente lento. Continuei trabalhando hoje e até dei uma pequena pausa de usá-lo enquanto fazia outras coisas, e ele começou a ficar lento novamente. Quase parece que talvez o problema não seja de usá-lo ativamente, mas também parece que outra coisa o acionou durante o tempo em que estou trabalhando nisso.

Vou executar o profiler para ficar de olho nele e criar um novo problema se houver outras descobertas diferentes das explicadas acima.

Não verifiquei se você pode acessar minha área de trabalho, embora, infelizmente, não consiga compartilhar isso com você.

Eu tentei executar o profiler ontem quando ele estava ficando particularmente lento e quando eu estava tirando um instantâneo do heap, o computador esgotou a memória RAM disponível e eu quase não pude fazer nada, nem mesmo forçar o fechamento do código, então tive que reiniciar o computador. Vou tentar executá-lo mais cedo do que antes para evitar que isso aconteça novamente.

Este é um pouco fora do tópico, mas você postou o link para a construção de insiders, que eu visitei. Eu queria baixar a versão do windows (como eu uso em casa), e sempre que tento acessar esse link, ele redireciona primeiro para a página de download normal, mas então imediatamente me redireciona para a página principal sem iniciar um download. Na verdade, ele sobrescreve o histórico da página de download em que eu estava, então não consigo nem voltar no histórico para acessá-lo. Existe alguma outra maneira de construir os insiders?

@cwadrupldijjit

Este é um pouco fora do tópico, mas você postou o link para a construção de insiders, que eu visitei. Eu queria baixar a versão do windows (como eu uso em casa), e sempre que tento acessar esse link, ele redireciona primeiro para a página de download normal, mas então imediatamente me redireciona para a página principal sem iniciar um download.

Desculpe por isso, mas alguns usuários relataram alguns problemas estranhos na compilação dos insiders e nós a retiramos temporariamente até entendermos o problema.

@egamma Eu me perguntei se ele poderia estar inacessível por causa disso. Vou ficar de olho para quando funcionar, então.

@Tyriar Tentei o espaço de trabalho chromium durante a noite no Linux, Windows e Mac e não consegui reproduzir um travamento. Você poderia tentar novamente, por favor?

Não tenho certeza se isso está relacionado, mas percebi que o VS Code tende a travar durante meu dia de trabalho se eu o abrir e esquecer por algum tempo. Estou no trabalho por 11 horas e geralmente abro o código logo de manhã. Em algum ponto durante o dia, meu computador ficará lento e começará a travar até travar ou eu forçar o encerramento.

Caso isso possa ajudar ...

O projeto principal que abri no VS Code é uma versão relativamente não modificada de um carrinho de compras chamado BVCart (versão 2004.7). Tenho cerca de 25-30 arquivos funcionando agora e até mesmo abrir o VS Code e não tocá-lo o dia todo leva a um travamento.

O projeto tem 1836 arquivos e 130 pastas totalizando cerca de 35 MB e está contido em um pequeno repositório git.

@ZombieProtectionAgency é possível compartilhar este espaço de trabalho comigo?

@bpasero Desculpe, definitivamente não consegui compartilhá-lo :( Não olhei, mas talvez você consiga encontrá-lo on-line em algum lugar. É apenas um carrinho de compras ASP VB.Net antigo e quase plano. A grande maioria de os arquivos são .vb com aspx, ascx e um pequeno punhado de arquivos css.

Estou tendo exatamente o mesmo erro. O VS Code trava a cada poucos minutos. Estou usando com olmo. Ele não entra em conflito quando é deixado ligado. Ele entra em conflito poucos minutos depois que eu começo a encerrar o arquivo. Tem sido assim nos últimos três dias, tornando o VS Code inutilizável. Como posso verificar o que está acontecendo? Estou usando a versão 0.10.10.

Outro pensamento que tive: temos um serviço que pode receber saída de vários endpoints (git, tarefas, extensões) e isso é algo que pode acontecer em segundo plano e somar. Fizemos algumas correções nessa área para o GA que não estão nas versões anteriores.

Se alguém com travamentos noturnos pudesse verificar brevemente se há alguma saída registrada em segundo plano? Você pode ver isso em Exibir> Alternar saída e, em seguida, alternar entre os canais no menu suspenso.

@bpasero
Na saída de 'Tarefas', estou apenas vendo a saída que esperaria de minha própria tarefa de compilação.
Na saída 'Git', estou vendo alguns git fetch's intercalados com alguns git show's. Eu não tenho certeza com que freqüência, pois não há um carimbo de data / hora. Nenhuma outra saída.

Fazemos busca automática de vez em quando, mas o resultado principal que você vê provavelmente é do trabalho que você faz no VS Code. Seria interessante se a saída somasse quando o VS Code estivesse em segundo plano. A tarefa está em execução constante ou apenas quando você invoca explicitamente a tarefa de compilação?

A tarefa é apenas quando eu ctrl + shift + B e termina logo em seguida. No entanto, tive travamentos quando não executei uma tarefa.

Eu recebo dois git show's idênticos quando eu alterno entre os arquivos e sim, o git fetch ocorre automaticamente uma vez a cada dois minutos.

Observe que eu não faço checkouts etc dentro do VSCode, eu uso o SourceTree para todas as tarefas relacionadas ao git.

@bpasero Vou deixar a janela de saída aberta hoje e ver se algo aparece. Atualmente, ele está aberto há mais ou menos uma hora de uso normal e não vejo nada nas tarefas ou visualizações do git. Não usamos git, então não esperaria ver nada nele como regra geral.

Nossa versão mais recente de insiders foi lançada e eu agradeceria se as pessoas pudessem experimentá-la neste problema: https://code.visualstudio.com/insiders

@bpasero Eu ainda tinha a compilação dos insiders anteriores, posso apenas executar isso e fazer "verificar se há atualizações" ou preciso atualizar a compilação a partir do link que você forneceu?

Vou tentar entrar em contato com você. Para ser honesto, estou vendo menos o VSCode
trava hoje em dia. Pelo menos não falha todos os dias.

Posso travar abrindo um arquivo enorme com milhões de linhas extras
js minimizado e rolando para cima e para baixo repetidamente. Mas eu sei o que é
empurrando os limites do editor.

O que quer que você tenha adicionado como molho mágico está funcionando para mim.

Na quarta-feira, 16 de março de 2016 às 12h29, Benjamin Pasero [email protected]
escrevi:

Nossa última versão de insiders foi lançada e eu apreciaria se as pessoas pudessem
experimente este problema: https://code.visualstudio.com/insiders

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -197503185

@gwynjudd você deve ser capaz de atualizar se o logotipo do VS Code aparece como logotipo verde:

@nojvek sim, isso está forçando um pouco os limites. para o lançamento de março, fizemos testes de memória explícita para encontrar áreas onde podemos melhorar. a construção de insiders inclui algumas dessas correções (não todas, fizemos algumas alterações ontem e hoje que ainda não foram lançadas). então apenas curiosidade se isso faz alguma diferença para as pessoas que veem isso ...

@bpasero obrigado, eu fiz isso e vou deixar você saber como foi

@bpasero ainda teve a mesma falha durante a noite com a construção dos insiders da marcha. Você quer que eu tente obter um despejo de heap das ferramentas de desenvolvedor durante o uso normal? Posso tentar ficar de olho no uso da memória para o código e fazer um dump se parecer que está aumentando

Sim, por favor, obrigado.

Aqui está um instantâneo de heap imediatamente após o lançamento do código (uso de memória de cerca de 100 MB naquele momento)

Heap-20160318T115937.zip

Vou tentar novamente em uma ou duas horas. A parte complicada parece ser chegar em um ponto em que a memória aumentou um pouco, mas não tanto a ponto de fazer com que ele falhe sem memória.

Eu vi o mesmo tipo de resultados quando tentei tirar um instantâneo de heap (ficou sem memória), e não é divertido.

Sinto que ainda há alguns problemas de memória na última compilação de insiders (para mac). Vou ver se consigo obter outro instantâneo de heap sem sacrificar meu computador.

@bpasero, desculpe, ainda não consegui obter um instantâneo do heap. A memória está muito baixa, como a que capturei antes, ou salta para cerca de 500 MB ou mais e capturar o instantâneo causa um travamento.

Tenho que reiniciar o vscode 1-2 vezes ao dia porque o uso de memória ultrapassa 1 GB e as coisas começam a ficar lentas. Ele está usando a quantidade de memória que um IDE completo usaria, então definitivamente há algum vazamento acontecendo.

@ vincent-ly você pode compartilhar mais detalhes sobre o espaço de trabalho com o qual você vê isso?

@bpasero Existem cerca de 30-40 arquivos js / scss / html que usam alguns componentes do bower com gulp (sem o executor de tarefas vscode). Eu trabalho com 2 painéis de editor e frequentemente uso a pesquisa de arquivos, bastante padrão. O uso de memória fica abaixo de 100 MB na inicialização, mas aumenta com o tempo, mesmo quando minimizado.

O intellisense desempenha um fator? Tenho definições de tipo Angular e jQuery instaladas.

Você pode experimentar nossa versão interna, onde trabalhamos para reduzir a pressão de memória para ver se isso a torna melhor: http://code.visualstudio.com/download?insiders=true

Você tem extensões instaladas?

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

Vou tentar a compilação interna e apresentar um relatório, obrigado!

+1

Vendo o mesmo problema no VSCode para Windows 0.10.11 . Normalmente, ele trava todas as noites de forma consistente quando não está em uso. Procedimentos dados para coletar informações eu ficaria feliz em ajudar.

Executando em um repositório git TypeScript com 28.438 arquivos, 4.812 pastas. Tem observadores de gole também, com muitos defs TypeSript.

Tenho as seguintes extensões instaladas:

• PowerShell
• C #
• Material Theme Kit

@alanwright poderia tentar se ele ainda reproduz com nossa última versão

@bpasero É reproduzido durante a noite com construção

Há algo que eu possa fazer em minha máquina para capturar logs e compartilhar com você?

Por favor, compartilhe comigo no meu alias benjpas, obrigado! Também gostaria de receber alguns detalhes de como você usa o VS Code nesse espaço de trabalho para aumentar a memória.

Eu também estou tendo problemas durante a noite e durante o dia.

Não parece estar relacionado apenas a um espaço de trabalho, espaços de trabalho extremamente pequenos de 3 a 20 arquivos ou espaços de trabalho enormes, predominantemente notados quando várias janelas estão abertas.

Repos eu usei que caiu.
Mais de 1500 arquivos asp, js, .inc (asp)
Mais de 70 arquivos asp.net core, js, cshtml
Este repo (https://github.com/gogits/gogs)

@ eByte23 você trabalha com ou sem extensões? em que plataforma você está? você tentou com o lançamento de insiders?

@bpasero Win10 e OSX com C # como extensão.
Tentei usuários internos, mas não notei se ele travou, pois há um bug de tabulação, então parei de usá-lo, mas posso deixá-lo funcionando durante a noite para tentar reproduzi-lo.

@ eByte23 sim, por favor. que bug de tabulação?

@bpasero parece estar nas duas últimas versões do insider com exibição de espaço em branco e converter abas em espaço em branco com um arquivo com abas existentes que parece manter tabulação e não escrever espaços, mesmo em novas linhas.

Eu não tive a chance de fazer o teste completo, mas vou fazer isso agora.

@ eByte23 Eu sugiro que você relate algo assim como um problema separado, se você achar que é um. introduzimos uma nova configuração editor.detectIndentation cujo padrão é true . Talvez você possa tentar defini-lo como false .

@bpasero Meu mal, você está totalmente correto definindo essa configuração como false corrigiu meu problema.
Testei o Insider ontem durante a noite e também travou.

@bpasero parece que vocês podem estar superando este, da minha perspectiva, parece que está ficando melhor com as últimas compilações

Investimos um pouco na correção de vazamento de memória para a versão 1.0, então eu esperaria que a situação fosse melhor com a 1.0. Mas ainda há casos em que isso acontece.

Posso ter uma nova teoria porque descobri recentemente que os aplicativos Electron (nossa estrutura de IU) ficam estrangulados assim que sua janela perde o foco ou passa para o segundo plano. Eu me pergunto se essa limitação pode ter um impacto no consumo de memória.

Sempre que testei a reprodução, deixei a janela do VS Code aberta com o foco do teclado, então talvez uma diferença seja deixá-la rodar em segundo plano.

Existe uma maneira de desabilitar a limitação de plano de fundo para que eu pudesse produzir uma construção com um sinalizador para habilitar isso.

Caso contrário, também seria interessante ouvir as pessoas se uma falha após minimizar é o cenário típico.

Todos os meus travamentos aconteceram quando o VSCode não tinha foco. Geralmente aconteciam depois de deixá-lo em segundo plano o dia todo enquanto navegava na internet ou usava o Visual Studio

Eu apoio isso. Recentemente, experimentei um acidente. Foi com um VS em
fundo quando eu me concentrei em sublime durante a maior parte do dia.

No sábado, 16 de abril de 2016 às 11h44, Toni [email protected] escreveu:

Todos os meus travamentos aconteceram quando o VSCode não tinha foco. Geralmente eles
aconteceu depois de deixá-lo em segundo plano o dia todo enquanto navegava no
Internet ou usando Visual Studio

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -210872544

Houve um travamento ao usar a compilação interna há pouco tempo. Estava ligado há 2 dias. De repente, ficou lento. Selecionar texto com o mouse parou de funcionar. Shift-Right funcionou, mas muito lentamente. O aplicativo travou alguns minutos depois de perder o foco.

Este é meu primeiro travamento para a compilação interna, mas quanto à compilação normal, atualizei para a v1.0 e ele ainda trava a cada poucos minutos ou depois de aberto, tornando-o inutilizável. Eu nem preciso fazer nada de especial. Abra-o, edite um arquivo (principalmente arquivos .elm) ou apenas deixe estar e ele simplesmente travará. Nem espera para perder o foco primeiro.

1.0 trava quase todas as noites.
Windows 10 Ent.
Plug-ins: verificador ortográfico e gramatical, ESLint

Ok, um lançamento interno foi lançado com minha alteração incluída. Ficaria feliz se alguém tentasse: http://code.visualstudio.com/Download#insiders

Qualquer um :)?

Usando agora. Não tive um acidente desde ontem.

@bpasero Vou atualizar agora e deixá-lo rodando durante a noite e ver como vamos! Felicidades :)

@bpasero Eu instalei na sexta-feira, mas depois fui embora por um longo fim de semana, também meu PC de trabalho foi reiniciado, então não tenho nada para relatar.

@bpasero Teve um acidente ontem. Fiquei acordado por 3 dias antes de cair.

@bpasero Ainda estou vendo falhas ocasionais pela manhã com as últimas

Eu também.
Windows 8

@bpasero Insider 1.1.0 acumula melhor, levou quase uma semana para

Vou pegar 1.1.0 agora e ver como vai

Não consigo tirar um instantâneo de heap sem travar quando o uso de memória é superior a 150 MB.

Todas as manhãs, eu desbloqueio meu computador para descobrir que o VS Code travou durante a noite.

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

Normalmente deixo arquivos abertos. Eu corro com extensões. Posso usar alguma configuração para ajudar a reunir mais informações de diagnóstico?

Nosso novo lançamento de insiders já foi lançado (http://code.visualstudio.com/Download#insiders) e inclui nosso trabalho para guias / pilhas. Isso vem com um descarte de recursos mais agressivo porque, assim que você fecha um editor, nos livramos de seus recursos subjacentes.

Curioso se as pessoas pudessem se hospedar nisto por um tempo e relatar se as coisas melhorarem.

Observação: os insiders de agora em diante são atualizados todas as noites (consulte http://code.visualstudio.com/blogs/2016/05/23/evolution-of-insiders)

@bpasero Eu atualizei todos os meus dispositivos hoje, veja como vamos nos próximos dias

Sim, mudei principalmente para insiders por causa do terminal. Ai quanto eu
adoro. Achei o editor muito mais ágil e leve. Ótimo trabalho.

Existe alguma maneira de substituir "código". Na linha de comando para apontar para
insiders?

Na quarta-feira, 8 de junho de 2016, Elijah Bate [email protected] escreveu:

@bpasero https://github.com/bpasero Eu atualizei todos os meus dispositivos hoje,
ver como vamos nos próximos dias

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -224539214,
ou silenciar o tópico
https://github.com/notifications/unsubscribe/AA-JVM4KoGeXoc2SU5VeEYnxkZyPVWYMks5qJo13gaJpZM4Gnvn5
.

Ainda acontecendo no 1.2.0 para mim. Acontece todas as noites - rodando no Windows 7 Enterprise SP1. Eu tenho a mesma pergunta que @garthk

Normalmente deixo arquivos abertos. Eu corro com extensões. Posso usar alguma configuração para ajudar a reunir mais informações de diagnóstico?

@nortecodemky Eu estava me referindo ao lançamento 1.3.0 dos insiders, onde nosso trabalho de guias / pilhas está incluído (http://code.visualstudio.com/Download#insiders). Eu não esperaria muitas mudanças no 1.2.0.

@bpasero Aah ok - não registrou a data e hora em seu comentário. Vou mudar em algum momento hoje para ver se isso melhora as coisas. E obtenha alguns novos recursos para inicializar :)

@bpasero parece bom até agora !!

Mandei construir o VSCode Insiders no fim de semana Cheguei na segunda de manhã e vi um acidente.

Estou me perguntando se há algum dado de falha / despejo de telemetria que é enviado automaticamente quando o VSCode falha. Mais ou menos como relatórios de watson.

Comprei uma nova máquina na semana passada. Quando o configurei, coloquei apenas o build de lançamento (não os internos) - não o notei travar desde então.

@bpasero Eu não vi nenhuma falha desde 1.3, executando o Windows 10 Insider build> = 14367

@bpasero com as guias habilitadas, abriu o projeto ac # e o vscode está travando alguns minutos após a última atualização do hash de confirmação interna: 5474147bb83618975409dad7d8aa96151d7d1ea1.
NOTA: Eu não tinha habilitado as guias até agora

@ eByte23 você pode verificar se isso está relacionado a ter as guias habilitadas ou não tentando sem as guias?

@bpasero ainda acontece quando as abas são desabilitadas, mas nem perto da gravidade com as abas habilitadas.

Mas é altamente perceptível e reproduzível ao trabalhar com imagens, clicando entre imagens grandes rapidamente no insider e v1.2.1

@ eByte23 Eu sugiro abrir uma nova edição com o máximo de detalhes que você puder fornecer (por exemplo, a memória cresce?).

Claro que pode fazer. Eu não fiz uma grande investigação sobre isso ainda, mas vou obter alguns detalhes em profundidade para você um pouco mais tarde.

O VSCode 1.3.1 trava cerca de duas vezes por dia para mim, uma vez durante a noite (sempre) e às vezes aleatoriamente durante o dia. Ele travou agora enquanto eu o estava aberto em segundo plano, sem usá-lo por cerca de 2 horas. Além disso, ao abrir o vscode novamente, ele perde meu espaço de trabalho e tenho que reabrir a pasta do projeto que estava aberta antes da falha. As guias e divisões são preservadas após a reabertura da pasta.

Eu deixei aberto em segundo plano por um tempo com alterações não salvas, voltei, comecei a digitar e o vscode congelou por alguns segundos e depois travou. ele perdeu meu trabalho.

Espero que você possa entender minha frustração. Isso é inaceitável para um editor. Além disso, a sessão que ele restaurou não tinha as guias certas abertas, nem meu lugar em cada guia.

@DelvarWorld você pode compartilhar mais detalhes sobre seu ambiente de trabalho? você pode tentar executar com extensões desabilitadas para ver se isso ajuda?

Eu tenho esse mesmo problema no Linux Mint 17 Qiana (não consigo lembrar qual versão do ubuntu é!). Ele simplesmente congelou para mim após cerca de 2 horas de inatividade. Vou me lembrar de verificar o uso de memória / CPU na próxima vez que isso acontecer, embora eu nunca tenha notado uma desaceleração geral em outros aplicativos, etc, quando isso acontecer.

Informação de VSCode:

Versão 1.4.0
Commit 6276dcb0ae497766056b4c09ea75be1d76a8b679
Data 2016-08-04T16: 49: 32.489Z
Shell 0.37.6
Renderer 49.0.2623.75
Nó 5.10.0

Esse problema foi embora para mim (no 1.5.3, Windows 7) - dado que o último comentário foi há 2 meses, talvez isso tenha sido resolvido?

Eu não vejo isso acontecer comigo há anos também. Estou usando a versão atual há meses. Parece bom

Mesmo. Não parece sobrecarregar.

Ok, devemos continuar em questões individuais e evitar bugs monstruosos como esse que são difíceis de rastrear. Se alguém ainda estiver vendo esse problema, registre novos problemas com mais detalhes. POR FAVOR, evite sequestrar um problema existente 👍

Também me lembro de ter visto isso antes e não tinha visto há anos, então, essa é a minha verificação.