Vscode: Сбой при работе в ночное время

Кажется, это происходит постоянно, каждую ночь, когда я оставляю компьютер включенным. Похоже, он не отвечает из-за максимальной загрузки процессора. Может быть, где-то есть какой-то бесконечный цикл, возможно, связанный с опросом репозитория файла или git?

Интересно, решит ли ОС перевести VSCode (на самом деле Electron) в состояние, в котором он вызывает этот сбой. Я связался с Электроном, если они понимают.

Ни разу не случалось на Atom fyi, по крайней мере, на 1.19.x (по памяти) и 1.2.4.

У меня аналогичная проблема, начиная с ноябрьского обновления (0.10.2 / 0.10.3?). Практически каждый день я входил в систему и обнаруживал, что все мои окна VSCode, оставленные на ночь, разбились (со стандартной неинформативной / извиняющейся ошибкой сбоя «Код Visual Studio разбился»).

Сегодня, после обновления 0.10.5, у меня случился первый сбой, пока я был там - к сожалению, не тогда, когда я активно его использовал.

Запуск VSCode в Windows 7 (64-разрядная версия), в первую очередь использование его в качестве JS-редактора в очень большом проекте - всего почти миллион строк (включая библиотеки, которые мне нужно искать, поэтому не исключены). Никаких проблем с производительностью при нормальном использовании, и я не заметил чрезмерного использования ресурсов, приводящего к сегодняшнему сбою.

Я был бы рад предоставить более подробные журналы ошибок / информацию, если кто-то может указать мне на них.

У меня та же основная проблема, что и у @ Elusive138 : когда я оставляю код работать на ночь (каждую ночь), утром обязательно получаю «Код Visual Studio потерпел крах».

Все еще репро для меня на vscode 0.10.5, Ubuntu 12.04

Я безуспешно пытался воспроизвести в Windows 10, Mac OS 10.11 и Ubuntu 15. Я подозреваю, что проблема с нехваткой памяти, но ни по одному из вышеперечисленного объем памяти сильно увеличился.

Может кто-нибудь попробовать воспроизвести это при следующих условиях:

• воспроизводится ли он при открытии только пустого экземпляра кода (Файл | Закрыть папку)
• воспроизводится ли он при открытии рабочей области, но не при открытии файла в редакторе

Ubuntu 12.04, vscode 0.10.5 не смогли воспроизвести, оставив его на выходных с пустым экземпляром.

Это вполне может быть небольшая утечка памяти, очевидная из-за относительно высокого использования памяти в этой системе.

Я вышел из компьютера примерно в 17:30, при этом коммит системной памяти медленно увеличивался - он составлял 15 402 МБ в 19:00. В 3:09 утра был наиболее близок к пределу системных фиксаций (17 682 МБ), а использование фиксации упало с 16 218 МБ до 15 217 МБ. Я подозреваю, что это могло быть причиной сбоя VSCode. Использование фиксации было стабильным до тех пор, пока ведение журнала не прекратилось около 6 утра (нет места на диске - эти счетчики производительности большие!).

К сожалению, я не включил все процессы VSCode, поэтому у меня нет журналирования для конкретных процессов. Я попробую это сегодня вечером.

Было бы очень полезно, если бы я мог узнать время сбоя. VSCode оставляет где-нибудь логи?

К сожалению, я не включил все процессы VSCode, поэтому у меня нет журналирования для конкретных процессов. Я попробую это сегодня вечером.

Это было бы очень полезно, спасибо!

В настоящее время vscode не записывается на диск.

@ Elusive138 можете ли вы поделиться рабочим пространством, на котором запущен vscode?

@bpasero К сожалению, нет. Однако он основан на Ext JS, и именно там находится большая часть (библиотечного) кода. Я попробую чистое рабочее пространство Ext JS после завершения этого другого тестирования и посмотрю, будет ли оно там повторяться.

@ Elusive138 да, было бы неплохо иметь образец для воспроизведения на нашей

Похоже, что один из процессов code.exe (код №3 в прилагаемом журнале) протекает. Фиксация началась примерно с 200 МБ в 17:30 и достигла 460 МБ к 9:00 следующего дня, с постоянным увеличением:

Количество обработок не увеличивается.

vscode_memleak.zip

На этот раз сбоя не было, возможно, потому, что у меня не было запущено так много других программ, интенсивно использующих память. Возможно, позже удастся проверить это на виртуальной машине с низким пределом фиксации.

Этот журнал был создан за ночь с 3 большими рабочими областями, открытыми в разных окнах. Я постараюсь сузить круг вопросов до рабочего пространства, которым я могу поделиться.

@ Elusive138 было бы полезно разобраться в деталях процесса утечки. Можете ли вы найти его PID, а затем распечатать его полные метаданные, используя ps aux | grep <pid> ?

А, может это на винде, не уверен :)?

@bpasero Командная строка:

"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

Другие детали:

Дерево процессов:

Это после еще одного полного дня использования. Как видите, использование памяти процессом за это время увеличилось линейно (в той же рабочей области).

Ах ... это даже не самое плохое.

4772 - это процесс, который просочился в мгновение ока. Другой, кажется, вырос из-за того, что я использовал в течение дня ... Думаю.

@ Elusive138, похоже, у вас открыто несколько окон с кодом, это правда?

@bpasero Да, в тесте прошлой ночью было открыто три окна с разными рабочими пространствами. Я попробую сегодня вечером с одним, на чистой рабочей области Ext JS, как упоминалось выше.

Звучит неплохо!

К сожалению, репродукции нет ... это странно. Что могло вызвать утечку в этом конкретном проекте?

Кстати говоря, это может отличаться от первоначальной проблемы @Tyriar . Его не отвечал, мой и gwynjudd вылетали с диалоговым окном об ошибке ..? В таком случае, возможно, нам стоит сделать новый выпуск ...

@ Elusive138 странно. воспроизводится ли он, если вы просто откроете это рабочее пространство, не открывая никаких JS-файлов?

Кроме того, возможно, мы сможем начать профилирование с помощью инструментов разработчика Chrome, где вы можете делать снимки кучи. Для этого просто сделайте снимок до и через некоторое время, чтобы увидеть, куда уходит эта память.

@bpasero О, я совсем забыл об этих инструментах для разработчиков. Я попробую это сегодня вечером.

@bpasero Снимки кучи Main.js , workerMain.js и workerMain.js (2) на самом деле не меняются. Может быть, максимум на 5 МБ.

Добавляя больше о своей ситуации, я попытался запустить его с открытой папкой (той, которая разбилась), но без рабочих файлов, и это не произошло в одночасье. Это происходит только тогда, когда папка открыта и есть активные рабочие файлы.

@ Elusive138 мы порождаем другие процессы, которые могут вызвать

@Tyriar, можешь

Причина, по которой я спрашиваю об открытии файла или нет, заключается в том, что, например, языковая служба JS запускается только после открытия файла JS. То же верно и для любой другой языковой службы. Поэтому, если эта проблема воспроизводится без открытия файла в редакторе, вполне вероятно, что утечка памяти не в какой-либо языковой службе, а где-то еще.

Еще одна вещь, которую стоит попробовать: запустить без какого-либо расширения, чтобы узнать, не протекает ли расширение. Для этого вы можете запустить --disable-extensions .

@bpasero Я уверен, что приведенная выше командная строка была для 4772, выделенного (дырявого) на скриншоте. Там написано --type=renderer .

Я снова оставлю его работать на выходных и посмотрю, что будет. Я не думаю, что провел чистый тест, пока не открыты файлы JS.

@bpasero Я считаю, что у меня не было открытого файла (справа), только рабочие файлы над деревом. Если я помню, когда закончу работу, я попробую проверить с открытым файлом и отметить язык.

Я не знаю наверняка, но, вероятно, когда мой разбился, это был не файл JavaScript, скорее C ++, Java или без языка. Обязательно проверю.

@Tyriar, если он воспроизводится только при наличии чего-то в рабочих файлах и при закрытых всех редакторах (сразу при запуске - это важно), мы можем что-то понять.

@bpasero Я могу попробовать открыть кучу инстансов при различных условиях, прежде чем уйти с работы в пятницу, и посмотреть, смогу ли я завершить все свои эксперименты за одну ночь. Если у вас нет причин полагать, что один случай зависания vscode сломает все остальные?

@Tyriar: да, полностью, если у вас открыто более одного окна, все это складывается в общую используемую память, и все они вылетают. Это связано с тем, что, когда вы открываете несколько окон, они по-прежнему используют один родительский процесс и один лимит памяти примерно в 1–1,5 ГБ. Чтобы понять, откуда исходит утечка, лучше всего измерить одно окно, изолированное при следующих условиях:

• никакое расширение не включено через --disable-extensions (расширение, которое потребляет много памяти или утечки, также может вызвать сбой)
• ни один файл не открывается при запуске (просто закрыть файл после запуска уже слишком поздно)
• нет рабочего файла под рабочими файлами

Кстати, единственное, что может повлиять на рабочие файлы, - это то, что для каждого рабочего файла, находящегося за пределами рабочей области, мы устанавливаем средство отслеживания файлов, чтобы отслеживать изменения. возможно, это вызывает утечку, хотя это было бы удивительно. Кроме того, мы не устанавливаем наблюдателя, если файл находится внутри открытого рабочего пространства, только для файлов вне его.

@bpasero Никаких утечек, когда нет открытых файлов (?). Сегодня вечером я попробую чистое рабочее место, предварительно открыв несколько.

На выходных я попробовал со следующей настройкой:

1. Запустить с Code --disable-extensions
2. Откройте файл JavaScript размером ~ 1300 строк

Память и процессор были примерно одинаковыми в пятницу вечером и в понедельник утром.

@Tyriar: это просто открытие пустого рабочего пространства с одним файлом или открытие сначала папки, а затем файла из нее?

@bpasero Открытие пустого рабочего пространства, я не открывал папку, и при запуске не было открыто ни одной папки

Хорошо, хорошо знать. Похоже, это связано с открытием (потенциально большой) папки. Тем не менее, чтобы узнать, достаточно ли просто открыть эту папку или открытие файла только запускает его.

@bpasero У меня была открыта большая папка, в которой не было открытых файлов в течение выходных, без заметного увеличения использования памяти. Я получу результаты теста на открытие больших папок и файлов с воспроизводимым / общим рабочим пространством примерно через 7 часов.

@bpasero папка, в которой у меня раньше возникали сбои, могла бы содержать 13000-14000 файлов, включая репозиторий git, который сам по себе был около 2000.

Думаю, я дважды проверю, что сбой все еще происходит в последней версии, так как я давно его не видел (из-за тестирования).

И я предполагаю, что это рабочая область JS?

@bpasero py, cpp, js, html, css

Хорошо, похоже, это воспроизводит медленно растущее использование памяти, если в меньшем масштабе: /ext/build/ext-all-debug.js .

(Да, это 7z внутри zip ... GitHub не позволяет мне загружать 7z или xz напрямую, а zip и gzip слишком большие)

@ Elusive138 на сколько он у тебя увеличивается в среднем? У меня было рабочее пространство с некоторыми файлами JS, открытыми в течение 2 часов без увеличения памяти.

@bpasero Извините, у меня снова проблемы с воспроизведением. Я думаю, что при более ранней попытке у меня было случайное репозиторий git, которого не было в архиве выше. Я дам вам знать, когда у меня будут более конкретные результаты.

Было бы действительно полезно, если бы можно было открыть несколько независимых экземпляров ... ограничение одним тестом в ночь - это довольно медленно. Вы случайно не переносите флаги Chromium для отдельных профилей?

Можно создать несколько версий кода, которые могут работать параллельно, хотя мы не документировали это. Если вы измените значения в https://github.com/Microsoft/vscode/blob/master/product.json так, чтобы они были разными, а затем построили из командной строки, вы можете запустить несколько отдельных экземпляров. Идентификаторы, которые должны быть уникальными:

• darwinBundleIdentifier
• win32MutexName
• nameShort
• nameLong
• dataFolderName (например, «dataFolderName»: «.oss-code-1»)

Windows 8.1. В коде утром открыл папку для репозитория git, содержащего 39 000 файлов.
Очень мало сделал с этим, несколько небольших правок в паре файлов.
К концу дня размер фиксации, о котором сообщил диспетчер задач, составил 672 164 КБ.
Он неуклонно рос весь день, даже когда меня не было в программе.

@gushie есть ли шанс, что я могу поделиться этим репо? также, о чем было сообщено об исходной памяти?

@bpasero Извините, мне не разрешено делиться самим репо, но если есть какие-либо подробности об этом, которые могут помочь, за исключением самого содержимого файла, дайте мне знать. Первоначально процесс начинается с примерно 110 МБ, затем быстро увеличивается до примерно 130 МБ, а затем возвращается к 90 МБ. С этого момента он будет неуклонно расти. (Есть 5 других процессов code.exe, размер которых варьируется от 4 МБ до 30 МБ, но они не сильно увеличиваются. Есть только одно окно кода)

Я не знаю, каков был окончательный размер фиксации со вчерашнего дня, поскольку процесс завершился сбоем, когда я вернулся к нему сегодня.

@gushie Я использовал системный монитор в процессах code.exe для отслеживания «частного размера».

Довольно неприятно, что мы не можем поделиться рабочими областями, с которыми у нас есть проблемы! Интересно, сталкивался ли кто-нибудь с этим с чем-то открытым. Ищу сходства: использовалось ли ваше репо с git-svn?

@bpasero Спасибо, если процесс, который я покинул, не воспроизведен, когда я вернусь в понедельник, я могу попробовать создать пару дополнительных копий. Хотя нужно будет выяснить, как отслеживать, какой из них… это может быть проблемой.

@ Elusive138 Мы используем инструменты Atlassian, поэтому SourceTree подключается к частному серверу Stash

Ах, это полностью отличается от моего. Был локальный репозиторий Git (с расширениями Git), подключенный к серверу SVN. Мой текущий тест - это репозиторий git, основанный на vscode ... надеюсь, он будет воспроизведен, и я могу поделиться им.

@gushie воспроизводит ли он, если вы просто открываете рабочее пространство, не открывая никаких файлов? попробуйте сначала закрыть все файлы и перезапустить, чтобы получить эту настройку. если это не воспроизводится, воспроизводится ли оно, если вы открываете рабочую область, открываете один файл JS и позволяете ему это делать?

@bpasero Вчера вечером я уже оставил его открытым с одним неотредактированным рабочим файлом, и, проверяя сегодня утром, использование памяти, похоже, не сильно изменилось. Я отредактировал и построил файл и оставлю его, чтобы посмотреть, что произойдет.

Обратите внимание, пока я не прочитал этот вопрос, я никогда не очищал рабочие файлы. (Мне действительно не было в этом необходимости, я обычно игнорировал эту панель и переключал файлы через проводник файлов проекта под ней или с помощью Ctrl + E).

Сбой снова, на этот раз после регулярного использования, но остался в этом состоянии:

• ~ 14000 файлов в папке открыта
• 5 активных файлов (.cc, .java, .h, .py, .json)
• В текстовом редакторе нет открытых файлов

ps aux вывод:

❯ 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

Как уже упоминалось, это произошло после регулярного использования, а не в безопасном режиме, поэтому _ могло_ быть связано с расширением?

Я оставил открытым один файл с небольшой правкой, только этот файл в рабочих файлах. В остальном нетронутый весь день. Объем памяти не увеличился по сравнению с исходным значением.

@Tyriar ну, процесс, который вы показываете, - это наша служба просмотра файлов, и на Linux / Mac мы используем для этого Chokidar (https://github.com/paulmillr/chokidar). Это будет означать, что у них есть утечка при просмотре файлов. Есть ли какая-то задача сборки, которая постоянно выполняется и меняет файлы?

@gushie это было без открытия папки?

@bpasero Я открыл папку. Очевидно, что есть какое-то действие, которое, кажется, запускает утечку памяти после первоначального открытия файла в папке. Я продолжу отслеживать и постараюсь сузить круг вопросов.

@bpasero Это был единственный связанный с vscode процесс, который я мог видеть в выходных данных. Возможно, он не был виден в выходных данных, потому что он уже был уничтожен из-за отсутствия ответа? Как показано, этот процесс использовал только 0,5% памяти и 0% ЦП. Судя по моим недавним открытиям, проблема, с которой я столкнулся, вероятно, не связана с сервисом JS.

Кстати, даже если мы не найдем причину этого до конца месяца, я внес изменение, чтобы диалоговое окно сбоя, которое вы получаете по умолчанию, выбирает действие для повторного открытия окна, чтобы вы могли продолжить работу с того места, где вы остановились. Это также хорошо для случая, когда у вас открыто несколько окон и только одно из них дает сбой.

(чего не хватает на будущее, так это возможность периодически сбрасывать состояние пользовательского интерфейса на диск, чтобы повторное открытие также восстановило вашу предыдущую рабочую среду)

@bpasero : +1: это было бы полезно.

VS вылетает каждое утро уже около месяца. Мое терпение иссякло.

Я надеюсь, что это рассматривается как ошибка PRI 0, потому что любой нормальный редактор не должен часто давать сбой.

Пожалуйста, дайте мне знать, как я могу выяснить, почему это происходит. Я видел, как это происходило и на других машинах.

@nojvek, можете ли вы поделиться со мной рабочим пространством, где это происходит?

Я не уверен, что вы имеете в виду под общим рабочим пространством. Это проект машинописного текста / HTML / CSS с небольшим количеством C ++. Около 1500 файлов и 80 000 строк кода.

Есть ли в VS способ показывать аварийные дампы?

@nojvek Я хотел бы иметь рабочую область, в которой я могу запускать код, чтобы воспроизвести эту проблему. Мы подозреваем, что это связано с утечкой памяти где-то, просто неясно, где. Если вы можете отправить мне почтовый индекс рабочей области или, возможно, URL-адрес git, если это открытый исходный код.

Бенджамин,

Это внутренний исходный код Microsoft, и я не думаю, что смогу вам его передать.

Если есть какой-нибудь инструмент для мониторинга памяти, я могу добавить, дайте мне знать.

Будет ли это работать, если я сделаю снимки памяти со встроенным отладчиком Chrome
в vscode каждые пару часов, чтобы посмотреть, что происходит?

В субботу, 23 января 2016 г., Бенджамин Пасеро [email protected]
написал:

@nojvek https://github.com/nojvek Я хотел бы иметь рабочее пространство,
Я могу запустить Code с, чтобы воспроизвести эту проблему. Мы подозреваем, что это связано с
утечка памяти где-то, просто непонятно где. Если вы можете отправить мне почтовый индекс
рабочей области или, возможно, URL-адрес git, если это открытый исходный код.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -174192367.

Да, снимки памяти помогут, если и только если эта утечка находится внутри основной части VS Code. Однако похоже, что по крайней мере в одном случае утечка произошла в одном из порождаемых нами процессов (наблюдателе за файлами). Возможно, вы могли бы определить с помощью проводника процессов, какой процесс постоянно увеличивается с точки зрения потребления памяти.

Если мне поможет предоставить исходный код: я работаю в Microsoft;)

Я поговорю с моим менеджером. Это в репозитории Windows, поэтому мне придется
будьте немного осторожны.

Из потока кажется, что chokidar используется для наблюдателя за файлами. Какое-то время
назад Я поигрался с исходным кодом. Это было немного спагетти.

Я посмотрю, смогу ли я загрузить chokidar в его собственное простое приложение узла, и посмотрю,
виновник.

Кстати, какие-то конкретные причины, по которым VS нужно использовать chokidar? Есть и другие
кроссплатформенные файловые наблюдатели, верно?

В воскресенье, 24 января 2016 г., Бенджамин Пасеро [email protected]
написал:

Да, снимки памяти помогут тогда и только тогда, когда эта утечка находится внутри основного
сторона VS Code. Однако кажется, что по крайней мере в одном случае утечка была
в одном из порождаемых нами процессов (наблюдатель за файлами). Может ты мог бы
определить с помощью проводника процессов, какой процесс постоянно увеличивается в
сроки потребления памяти.

Если мне поможет предоставить исходный код: я работаю в Microsoft;)

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -174269028.

Chokidar используется на Mac и Linux, если вы работаете в Windows, мы используем наблюдатель файлов C #. Я рад принять PR с работающим и производительным решением для кросс-файлового наблюдателя :)

Вы знаете, что начиная с узла 4.0 fs.watch стабилизирован как на Windows, так и на Mac. См. Https://github.com/Microsoft/TypeScript/issues/4643.

Typescript имеет довольно прочную кроссплатформенную логику просмотра файлов / каталогов. https://github.com/Microsoft/TypeScript/blob/931d162620c7e09377c12875834e1838c4cdd51b/src/compiler/sys.ts

Попробую получить локальную сборку VS-кода с изменениями и посмотреть, вылетает ли он по-прежнему. Если этого не произойдет, я обязательно пришлю PR.

Я знаю, что стало намного лучше, если использовать рекурсивный вызов часов в каталоге и, таким образом, избежать необходимости прикреплять прослушиватель часов к папке, но я думаю, что события по-прежнему иногда пропускают имя файла / папки, по крайней мере, в некоторых случаях. Я чувствую себя более уверенно, используя C # здесь.

Репродукцию удалось получить сегодня. У меня произошел сбой, прежде чем я собирался открыть консоль инструментов разработчика, чтобы сделать снимок памяти.

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

Кажется, что машинописный сервер занимает около 200 МБ.
Средство рендеринга заняло около 800 МБ, а затем отказало.

Когда у меня будет около 500 МБ использования, я попытаюсь сделать снимок памяти. Процесс --renderer - это процесс webkit, верно?

Это было через два дня с тех пор, как я в последний раз видел крушение. Похоже, что использование инструмента в течение 8-часового периода редактирования большого количества файлов TS ускоряет использование.

Отлично, процесс рендеринга - это основной процесс для редактора. Если вы сможете сделать снимок памяти там, это продвинет нас дальше. К сожалению, моментальный снимок не будет работать ни с одним другим процессом, но с ними все в порядке.

Однако нормально ли, что tscse (сервер машинописного текста) потребляет 200 МБ?

26 января 2016 г., 21:29, Бенджамин Пасеро [email protected]
написал:

Отлично, процесс рендеринга - это основной процесс для редактора. если ты
можем сделать снимок памяти там, это продвинет нас дальше. К сожалению,
снимок не будет работать ни с одним другим процессом, но они кажутся
будь в порядке.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -175408302.

Ага, очень легко.

Смешно! Я делал снимок кучи, и VS рухнул.

Я попробую еще раз и посмотрю, повезет ли мне завтра.

Есть ли способ указать vscode увеличить лимит памяти, чтобы он не падал при попытке сделать снимок кучи?

Я думаю, что происходит то, что создание снимка вызвало исключение нехватки памяти: - /. Невозможно изменить лимит памяти, он жестко запрограммирован в V8.

Может быть, попробовать сделать снимок пораньше, пока использование памяти не вырастет так сильно? Это постепенное увеличение?

Мне не удалось воспроизвести (без сбоев, разумное использование памяти) последние две недели или около того. Единственное отличие, о котором я могу думать, - это обновление расширения PowerShell с 0.1.0 до 0.3.1, но у меня все равно нет файлов PS в рабочей области, и он разбился с отключенными в то время расширениями.

Я получил успешный дамп размером около 300 МБ, используемый процессом --renderer. Вылетело через 10 секунд после того, как я сделал дамп.

Кажется, что основная часть использования находится в дереве DOM.

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

Надеюсь это поможет.

Хмммм, интересно, говорит ли профайлер настоящую правду. Я вижу все элементы дерева, и у нас может быть утечка в дереве, но я был бы удивлен, если бы эта утечка могла вызвать нехватку памяти за такой короткий период времени.

Сделал еще несколько дампов.

Похоже, открытие файлов .min.js вызывает огромный скачок памяти. Даже после закрытия файлов память вроде не падает. Между всеми дампами памяти кажется, что доминирует DOM.

Также не уверен, почему было два процесса рендеринга. Может быть, одним из них был chrome devtools. Но я очень близко подошел к 1 гигу.

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

Я сделал снимок экрана двух процессов, потребляющих ~ 500 МБ оперативной памяти.

Да, одна из них - инструменты разработки. Ожидается, что объем памяти увеличится при открытии файлов. Но я хотел бы понять, как VS-код, который работает в течение ночи без активности, увеличивает использование памяти до тех пор, пока не выйдет из строя.

Ну репродукция:
Старт против кода.
Откройте один или два файла js / ts в большой папке с большим количеством файлов .tsconfig.
Прокрутите / отредактируйте.
Закройте все рабочие файлы.
Положите его на ночь при температуре 200С.
Торт!

В пятницу, 29 января 2016 г., Бенджамин Пасеро [email protected]
написал:

Да, одна из них - инструменты разработки. Ожидается, что объем памяти увеличится при открытии
файлы. Но я хотел бы понять, как VS-код работает над
ночь без активности увеличивает использование памяти, пока не произойдет сбой.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -177087988.

@nojvek Нужны ли .tsconfig для воспроизведения? потому что в прошлом у меня были сбои, вообще не связанные с TS. Хотя я уже не могу их воспроизвести ...

У нашего проекта они просто есть. Может быть отвлекающим маневром.

В субботу, 30 января 2016 г., Боб [email protected] написал:

@nojvek https://github.com/nojvek Нужны ли .tsconfigs для
репро? потому что в прошлом у меня были сбои, не связанные с TS на
все. Хотя я уже не могу их воспроизвести ...

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -177198518.

Единственные файлы. * В нашей папке - это папка .git и .gitignore.

@nojvek , вы используете собственный машинописный сервер с проектом или готовый TS, который мы поставляем в версии 0.10.6? В версии 0.10.6 мы поставляем TypeScript 1.7.5.

@bpasero @nojvek, если это проблема памяти на стороне JS. Вы можете различать снимок кучи в Chrome.

1. Сделайте снимок.
2. Выполните действие, вызывающее утечку памяти.
3. Принудительная сборка мусора. В противном случае следующий снимок кучи будет включать объекты.
4. Сделайте еще один снимок.
5. Различают оба снимка.

Все можно сделать в Chrome Devtools, указанном выше. Сила сборки мусора находится на вкладке временной шкалы, значок мусора. И сравнение выполняется простым выбором его в проводнике снимков в меню фильтров.

Просто укажите, какие объекты сохраняются, и возможные пути сохранения (сразу под таблицей кучи). И это все данные, необходимые для решения этой проблемы.

Не нужно ждать целый день, чтобы собрать данные о сбое: wink:

В отправленной мной ссылке Dropbox было три снимка тепла, сделанных с интервалом в полчаса.
Я не занимался принудительной сборкой мусора. Будет уловка.

В воскресенье, 31 января 2016 г., Tingan Ho [email protected] написал:

@bpasero https://github.com/bpasero @nojvek https://github.com/nojvek
если это проблема памяти на стороне JS. Вы можете различать снимки кучи на
Хром.

1. Сделайте снимок.
2. Выполните действие, вызывающее утечку памяти.
3. Принудительная сборка мусора. В противном случае следующий снимок кучи будет
   включить объекты.
4. Сделайте еще один снимок.
5. Различают оба снимка.

Все можно сделать в Chrome Devtools, указанном выше. Сила мусора
сборка находится на вкладке шкалы времени, значок мусора. И разница
это можно сделать, просто выбрав его в проводнике снимков в меню фильтров.

Просто сообщите, какие объекты сохраняются и возможные пути сохранения (чуть ниже
таблица кучи). И это все данные, необходимые для решения этой проблемы.

Не нужно ждать целый день, чтобы собрать данные о сбое [изображение:
: wink:]

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -177462412.

У меня такая же проблема, VS Code постоянно дает сбой, не только ночью, даже после 30 минут простоя.
Я использую Windows 7, 64-битную и последнюю версию VS Code. Что касается самого проекта, это огромный js-проект с загруженными node_modules и bower_components. Всего в нем около 40К файлов.

Действия по воспроизведению:
1) Откройте папку проекта (с большим количеством файлов), откройте несколько файлов, чтобы они могли быть в списке рабочих файлов.
2) Откройте диспетчер задач.
3) Поместите курсор, чтобы сфокусировать какой-либо файл в VS Code
4) Наблюдайте, как всплывает память с течением времени.

Могут ли люди с рабочими пространствами JS, которые видят эту проблему, попробовать наши инсайдеры версии 0.10.7 (https://vscode-builds.azurewebsites.net/insider) с возможностью использования Salsa в качестве языковой службы JS: https://github.com /Microsoft/vscode-docs/blob/vnext/release-notes/latest.md#javascript --- предварительный просмотр сальсы

Благодаря!

+1 за этот вопрос. Также появляется в Windows. Это очень раздражает, и мне это не нравится.

@bpasero Я хотел бы опробовать новую сборку, но всякий раз, когда я пытаюсь получить доступ к предоставленной вами ссылке (https://vscode-builds.azurewebsites.net/insider), я получаю очень бесполезную страницу сообщения об ошибке со следующим текстом :

Войти в систему
Извините, но у нас возникли проблемы с входом в систему.
Мы получили неверный запрос.

Дополнительная техническая информация:
Идентификатор корреляции: e477dc1b-c193-4cf9-864b-1d3fdbba4f34
Отметка времени: 2016-02-03 19: 37: 17Z
AADSTS50020: учетная запись пользователя [email protected] от поставщика удостоверений https://sts.windows.net/5a7d8144-6966-4b1e-8147-de672a307ea0/ «не существует в клиенте Microsoft и не может получить доступ к приложению» 9d5f02f6-ffd9-4e80-92d5-e42c85e09bc9 'в этом арендаторе. Сначала необходимо добавить учетную запись в качестве внешнего пользователя в арендаторе. Выйдите из системы и войдите снова, используя другую учетную запись пользователя Azure Active Directory.

Я не могу загрузить сборку и опробовать ее из-за этой проблемы.

Извините, неправильная ссылка, используйте https://code.visualstudio.com/insiders

@bpasero спасибо У меня есть сборка инсайдеров, работающая с Salsa в качестве языковой службы JS. Я дам вам знать, как это будет на следующий день или около того

@bpasero , я попробовал выпуск инсайдеров, и проблема все еще существует, после одной ночи простоя VS Code потерпел крах.

@milenkovic @gwynjudd вам также нужно будет выполнить шаги, чтобы включить Salsa, как описано в https://github.com/Microsoft/vscode-docs/blob/vnext/release-notes/latest.md#javascript --- salsa- предварительный просмотр

@bpasero , Вы были правы, включение Salsa

Рад это слышать! Было бы интересно, если бы другие тоже могли это проверить, попробовав.

@bpasero Я включил сальсу и оставил ее работать на выходных. Сегодня утром он разбился.

Установлен машинописный текст

$ 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

Я установил settings.json как

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

и окружающая среда

$ setx VSCODE_TSJS 1

SUCCESS: Specified value was saved.

Я до сих пор не вижу сальсы в нижнем колонтитуле инсайдера VS code.

@nojvek Я сделал в основном то же, что и вы, и вижу сальсу в нижнем колонтитуле, но только когда файл .js открыт и виден в редакторе

@gwynjudd Я предполагаю, что у вас появилось диалоговое окно сбоя, и теперь с 0.10.8 вы смогли повторно открыть окно?

@bpasero да, я получил новое диалоговое окно сбоя и могу перезапустить

Гвин Джадд

-------- Исходное сообщение --------
От: Бенджамин Пасеро
Дата: 09.02.2016, 19:13 (GMT + 12: 00)
Кому: Microsoft / vscode
Копия: Гвин Джадд
Тема: Re: [vscode] Сбой при ночном запуске (# 508)

@gwyn juddhttps: //github.com/gwynjudd Я предполагаю, что у вас появилось диалоговое окно сбоя, и теперь с 0.10.8 вы смогли снова открыть окно?

Ответьте на это письмо напрямую или просмотрите его на Gi tHubhttps: //github.com/Microsoft/vscode/issues/508#issuecomment -181726111.

@gwynjudd - это рабочая область только для JS или другие типы файлов, такие как PHP?

@bpasero есть много типов файлов, включая typescript, java script, css, less, aspx, cs

Гвин Джадд

-------- Исходное сообщение --------
От: Бенджамин Пасеро
Дата: 09.02.2016, 22:49 (GMT + 12: 00)
Кому: Microsoft / vscode
Копия: Гвин Джадд
Тема: Re: [vscode] Сбой при ночном запуске (# 508)

@gwyn juddhttps: //github.com/gwynjudd - это рабочая область только для JS или другие типы файлов, такие как PHP?

Ответьте на это письмо напрямую или просмотрите его на Gi tHubhttps: //github.com/Microsoft/vscode/issues/508#issuecomment -181786273.

В новой сборке он каждое утро давал сбой, когда оставлял его работать на ночь. У меня установлены только эти расширения (в новой сборке, в сборке релиза у меня были разные расширения):

Сегодня утром, когда я пришел на работу, он не разбился. Я не делал ничего другого перед уходом с работы в пятницу.

Следует попытаться воспроизвести с помощью рабочего пространства Chromium с использованием Ubuntu, поскольку, похоже, у @Tyriar была такая настройка, когда это произошло.

Следуйте инструкциям здесь, чтобы получить код https://www.chromium.org/developers/how-tos/get-the-code

Я также заметил задержку в коде после некоторого времени его использования и возможные сбои. Я заметил, что когда он тормозит, я могу заставить его работать более плавно, если я нажму F1 и наберу «Окно перезагрузки». На данный момент это, кажется, проясняет проблему, и теперь я могу ее обойти. Мне определенно интересно увидеть это исправленным.

Читая этот поток, я также предполагаю, что это связано с процессом рендеринга, хотя я не проводил с ним никаких тестов, и, похоже, это происходит независимо от количества рабочих файлов в списке на панели проводника, независимо от того, или нет файл открыт, когда код загружен, возможно, размеры файлов, над которыми в настоящее время работают, и я не уверен, имеет ли это какое-либо отношение к git diff checker или нет, но я сомневаюсь, что это будет виновником .

Я также использую Mac OS X El Capitan 10.11.3 и на самом деле не видел проблемы в Windows, когда использовал его дома, но у меня нет огромного рабочего дерева для каких-либо проектов дома, только массивная папка, над которой я работаю на работе.

Я надеюсь, что обе проблемы связаны, но боюсь, что это не так: большинство людей здесь видят сбой кода, когда оставляют его запущенным без какого-либо взаимодействия с пользователем, что кажется очень подозрительным. Однако получение кода, который в конечном итоге вылетает из-за исключения нехватки памяти при его использовании в течение длительного времени, может быть вызвано другими утечками памяти. В идеале обе проблемы совпадают :)

Технически кажется, что он замедляется и дает сбой, даже если я его тоже не использую, но я не уверен, что и они испытывают то же самое в этом случае. В любом случае, симптомы кажутся по крайней мере похожими. Если обнаружится, что моя проблема не связана, я мог бы вместо этого создать отдельную проблему.

@cwadrupldijjit, если вы видите проблему со сбоем в ночное время, было бы полезно получить доступ к рабочей области, если это возможно.

Я посмотрю что я могу сделать. Я обычно укладываю Mac спать на ночь, чтобы в это время ничего не происходило. Я постараюсь оставить его на ночь и сообщу утром, если что-то случится. Я также буду держать вас в курсе, если вы получите доступ к моей рабочей области.

Звучит хорошо, спасибо!

К. Итак, я оставил экземпляр кода запущенным на ночь, и у меня не было проблем с его сбоями или немедленной задержкой. Я продолжил работу сегодня и даже сделал небольшой перерыв в использовании его, занимаясь другими делами, и он снова начал отставать. Кажется, что проблема не в его активном использовании, но похоже, что что-то еще вызвало ее в то время, когда я над этим работал.

Я запустил профилировщик, чтобы следить за ним, и я создам новую проблему, если будут другие результаты, отличные от описанных выше.

Я не проверял, есть ли у вас доступ к моему рабочему пространству, хотя, к сожалению, подозреваю, что не могу поделиться этим с вами.

Вчера я попытался запустить профилировщик, когда он становился особенно медленным, и когда я делал снимок кучи, у компьютера закончилась доступная оперативная память, и я почти ничего не мог сделать, даже принудительно закрыть код, поэтому мне пришлось перезапустить компьютер. Я постараюсь запустить его раньше, чем раньше, чтобы это не повторилось.

Это немного не по теме, но вы разместили ссылку на сборку для инсайдеров, которую я посетил. Я хотел загрузить версию для Windows (поскольку я использую ее дома), и всякий раз, когда я пытаюсь перейти по этой ссылке, она сначала перенаправляет на обычную страницу загрузки, но затем быстро перенаправляет меня на главную страницу, не инициируя загрузку. Фактически, он перезаписывает историю страницы загрузки, на которой я был, поэтому я даже не могу вернуться в историю, чтобы добраться до нее. Есть ли другой способ заставить инсайдеров построить?

@cwadrupldijjit

Это немного не по теме, но вы разместили ссылку на сборку для инсайдеров, которую я посетил. Я хотел загрузить версию для Windows (поскольку я использую ее дома), и всякий раз, когда я пытаюсь перейти по этой ссылке, она сначала перенаправляет на обычную страницу загрузки, но затем быстро перенаправляет меня на главную страницу, не инициируя загрузку.

Приносим извинения, но некоторые пользователи сообщили о какой-то странной проблеме в сборке для инсайдеров, и мы временно удалили ее, пока не разобрались с этой проблемой.

@egamma Я подумал, не могло ли это быть недоступным из-за этого. Тогда я буду следить, когда это сработает.

@Tyriar Я пробовал

Я не уверен, связано ли это, но я заметил, что VS Code имеет тенденцию к сбою в течение моего рабочего дня, если я открываю его и забываю об этом на некоторое время. Я работаю 11 часов и обычно открываю код утром. В какой-то момент в течение дня мой компьютер замедляется и начинает зависать, пока он не выйдет из строя или я не отключу его принудительно.

На всякий случай может помочь ...

Основной проект, который я открыл в VS Code, - это относительно немодифицированная версия корзины покупок под названием BVCart (версия 2004.7). У меня сейчас около 25-30 рабочих файлов, и даже просто открываю VS Code, не трогая его весь день, и это приводит к сбою.

Проект состоит из 1836 файлов и 130 папок общим объемом около 35 МБ, и он содержится в небольшом репозитории git.

@ZombieProtectionAgency, можно ли поделиться со мной этим рабочим пространством?

@bpasero Извините, я определенно не смог поделиться им :( Я не смотрел, но вы могли бы найти его где-нибудь в Интернете. Это просто в основном плоская старомодная корзина для покупок ASP VB.Net. Подавляющее большинство это файлы .vb с aspx, ascx и небольшая горстка файлов css.

У меня точно такая же ошибка. VS Code вылетает каждые несколько минут. Использую с вязом. Когда его оставляют включенным, он не конфликтует. Он сталкивается через несколько минут после того, как я начинаю заканчивать файл. Так было последние три дня, что делало VS Code непригодным для использования. Как мне проверить, что происходит? Пользуюсь версией 0.10.10.

Еще одна мысль, которая у меня возникла: у нас есть служба, которая может получать выходные данные из различных конечных точек (git, задачи, расширения), и это то, что может происходить в фоновом режиме и складываться. Мы сделали несколько исправлений в этой области для GA, которых не было в предыдущих выпусках.

Если кто-нибудь с ночными сбоями может просто кратко проверить, есть ли какие-либо выходные данные из фона? Вы можете увидеть это в меню «Просмотр»> «Переключить вывод», а затем переключаться между каналами в раскрывающемся списке.

@bpasero
В выводе «Задачи» я просто вижу вывод, который я ожидал бы от моей собственной задачи компиляции.
В выводе 'Git' я вижу несколько git fetch, перемежающихся с несколькими git show. Я не уверен, как часто, поскольку нет отметки времени. Но другого выхода нет.

Время от времени мы выполняем автоматическую выборку, но основной результат, который вы видите, вероятно, связан с работой, которую вы выполняете в VS Code. Было бы интересно, если бы результат складывался, когда VS Code находится в фоновом режиме. Задача выполняется постоянно или только тогда, когда вы явно вызываете задачу компиляции?

Задача возникает, когда я нажимаю ctrl + shift + B, и вскоре после этого заканчивается. Однако у меня были сбои, когда я не запускал задачу.

Когда я переключаюсь между файлами, я получаю два идентичных git-шоу, и да, git fetch происходит автоматически каждые пару минут.

Обратите внимание, что я не выполняю никаких проверок и т. Д. В VSCode, я использую SourceTree для всех задач, связанных с git.

@bpasero Я оставлю окно вывода сегодня и посмотрю, появится ли что-нибудь. В настоящее время он открыт около часа при нормальном использовании, и я ничего не вижу в задачах или представлениях git. Мы не используем git, поэтому я не ожидал увидеть что-либо в этом как правило.

Вышла наша последняя сборка для инсайдеров, и я был бы признателен, если бы люди могли попробовать решить эту проблему: https://code.visualstudio.com/insiders

@bpasero У меня все еще была предыдущая сборка для инсайдеров, могу я просто запустить ее и выполнить «проверку обновлений», или мне нужно обновить сборку по указанной вами ссылке?

Постараюсь вернуться к вам. Если честно, я вижу меньше VSCode
сейчас вылетает. По крайней мере, он не падает каждый день.

Я могу заставить его вылететь, открыв огромный файл с миллионами строк
minified js и многократной прокруткой вверх и вниз. Но я знаю что это
раздвигая границы редактора.

Все, что вы добавляли в качестве волшебного соуса, у меня работает.

В среду, 16 марта 2016 г., в 12:29, Бенджамин Пасеро [email protected]
написал:

Вышла наша последняя инсайдерская сборка, и я был бы признателен, если бы люди могли
попробуйте решить эту проблему: https://code.visualstudio.com/insiders

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -197503185

@gwynjudd вы сможете обновить, если логотип VS Code отображается как зеленый логотип:

@nojvek да, это немного раздвигает границы. для мартовского выпуска мы провели явное тестирование памяти, чтобы найти области, в которых мы можем улучшить. сборка для инсайдеров включает некоторые из этих исправлений (не все, вчера и сегодня мы внесли некоторые изменения, которых еще нет). так что просто любопытно, имеет ли это значение для людей, которые видят это ...

@bpasero спасибо, я сделал это, и я дам вам знать, как это происходит

@bpasero по- прежнему мартовской сборкой инсайдеров. Вы хотите, чтобы я попытался получить дамп кучи из инструментов разработчика во время обычного использования? Я могу попытаться следить за использованием памяти для кода и получить дамп, если кажется, что он растет

Да, пожалуйста, спасибо.

Вот снимок кучи сразу после запуска кода (в то время использовалось около 100 МБ памяти)

Куча-20160318T115937.zip

Я попробую еще раз через час или два. Кажется, что сложнее всего получить его в момент, когда объем памяти несколько увеличился, но не настолько, чтобы создание снимка заставило его вылететь из памяти.

Я увидел такие же результаты, когда попытался сделать снимок кучи (закончилась память), и это не весело.

Я чувствую, что в последней инсайдерской сборке (для Mac) все еще есть проблемы с памятью. Я посмотрю, смогу ли я получить еще один снимок кучи, не жертвуя своим компьютером.

@bpasero, извините, мне еще не удалось получить снимок кучи. Либо памяти очень мало, например, для той, которую я снял ранее, либо она выскакивает, чтобы сказать около 500 МБ или более, и захват снимка вызывает сбой.

Мне приходится перезапускать vscode 1-2 раза в день, потому что использование памяти превышает 1 ГБ, и все начинает казаться вялым. Он использует тот объем памяти, который использовала бы полноценная IDE, поэтому определенно происходит некоторая утечка.

@ vincent-ly, не могли бы вы поделиться более подробной информацией о рабочем пространстве, в котором вы это видите?

@bpasero Существует около 30-40 файлов js / scss / html, которые используют пару компонентов bower с gulp (без средства запуска задач vscode). Я работаю с двумя панелями редактора и часто использую поиск файлов, довольно стандартный. Использование памяти при запуске составляет менее 100 МБ, но со временем оно увеличивается, даже когда оно минимизировано.

Имеет ли значение intellisense? У меня установлены определения типов Angular и jQuery.

Вы можете попробовать нашу инсайдерскую сборку, в которой мы работали над уменьшением нагрузки на память, чтобы увидеть, улучшит ли это ее: http://code.visualstudio.com/download?insiders=true

У вас установлены расширения?

@bpasero Просто угловые фрагменты
https://marketplace.visualstudio.com/items?itemName=johnpapa.Angular1

Я попробую инсайдерскую сборку и доложу, спасибо!

+1

Увидеть ту же проблему в VSCode для Windows 0.10.11 . Обычно он вылетает каждую ночь, когда не используется. Учитывая шаги по сбору информации, я буду рад помочь.

Запуск в репозитории TypeScript git с 28 438 файлами и 4812 папками. Также есть наблюдатели за gulp со многими определениями TypeSript.

У меня установлены следующие расширения:

• PowerShell
• C #
• Материал темы

@alanwright, не могли бы вы попробовать, если он все еще воспроизводится с нашей последней инсайдерской сборкой (http://code.visualstudio.com/Download#insiders). Если да, можете ли вы поделиться со мной рабочим пространством?

@bpasero Воспроизведено за ночь с помощью инсайдерской сборки. Я пробовал как в нашем частном более крупном зачислении, так и в нашем зачислении с открытым исходным кодом, и только более крупное частное зачисление, похоже, вызвало проблему, которой я, к сожалению, не могу поделиться (это внутреннее решение Microsoft, поэтому, может быть, мы сможем предоставить вам доступ? Мой псевдоним Alanwri)

Могу ли я что-нибудь сделать на своей машине, чтобы записывать журналы и делиться с вами?

Пожалуйста, поделитесь со мной моим псевдонимом benjpas, спасибо! Также были бы признательны за некоторые подробности того, как вы используете VS Code в этой рабочей области, чтобы вызвать увеличение памяти.

Я также получаю сбои в ночное время и в течение дня.

Похоже, что это не имеет особого отношения только к рабочему пространству, чрезвычайно маленьким рабочим пространствам 3-20 файлов или огромным рабочим пространствам, которые обычно замечаются при открытии нескольких окон.

Репо, которое я использовал, разбился.
1500+ файлов asp, js, .inc (asp)
70+ файлов asp.net core, js, cshtml
Это репо (https://github.com/gogits/gogs)

@ eByte23 вы работаете с расширениями или без них? на какой платформе ты? вы пробовали с выпуском инсайдеров?

@bpasero Win10 и OSX с C # в качестве расширения.
Пробовали инсайдеры, но не заметили, разбился ли он, так как есть ошибка табуляции, поэтому я прекратил его использовать, но могу оставить его работать на ночь, чтобы попытаться воспроизвести.

@ eByte23 да, пожалуйста. какая ошибка табуляции?

@bpasero, похоже, находится в последних двух выпусках инсайдера с отображаемыми пробелами и конвертирует вкладки в пробелы с файлом с существующими вкладками, похоже, продолжает табуляцию и не записывать пробелы даже в новых строках.

У меня не было возможности провести полное тестирование, но я сделаю это сейчас.

@ eByte23 Я предлагаю вам сообщить о подобном как о отдельной проблеме, если вы думаете, что это одна из них. мы ввели новый параметр editor.detectIndentation который по умолчанию равен true . Может быть, вы можете попробовать установить его на false .

@bpasero Плохо, что вы абсолютно правы, установив для этого параметра значение false, и моя проблема решена.
Я проверил Insider Yesterday за ночь, и он тоже разбился.

@bpasero похоже, что вы, ребята, могли бы получить верх над этим, с моей точки зрения, кажется, в целом становится лучше с последними сборками

Мы довольно много вложили в исправление утечки памяти для версии 1.0, поэтому я ожидал, что с версией 1.0 ситуация улучшится. Но есть еще случаи, когда это случается.

У меня может быть новая теория, потому что я недавно обнаружил, что приложения Electron (наша структура пользовательского интерфейса) блокируются, как только их окно теряет фокус или перемещается на задний план. Интересно, может ли это регулирование повлиять на потребление памяти.

Всякий раз, когда я тестировал воспроизведение, я оставлял окно VS Code открытым с фокусом на клавиатуре, поэтому, возможно, одно отличие состоит в том, чтобы позволить ему работать в фоновом режиме.

Есть способ отключить фоновое регулирование, чтобы я мог создать сборку с флагом для включения этого.

В противном случае было бы интересно услышать от людей, является ли сбой после минимизации типичным сценарием.

Все мои сбои происходили, когда VSCode не фокусировался. Как правило, они происходили после того, как он оставался в фоновом режиме на весь день при просмотре Интернета или использовании Visual Studio.

Я поддерживаю это. Недавно я попал в аварию. Это было с VS в
фон, когда большую часть дня я сосредоточился на возвышенном.

В субботу, 16 апреля 2016 г., в 11:44, Тони [email protected] написал:

Все мои сбои происходили, когда VSCode не фокусировался. Обычно они
произошло после того, как он оставался в фоновом режиме на весь день при просмотре
Интернет или с помощью Visual Studio

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -210872544

Не так давно произошел сбой при использовании инсайдерской сборки. Пробыл 2 дня. Вдруг стало медленно. Выделение текста мышью перестало работать. Shift-Right работал, но очень медленно. Приложение вылетело через несколько минут после потери фокуса.

Это мой первый сбой инсайдерской сборки, но что касается обычной сборки, я обновился до версии 1.0, и она все еще вылетает каждые несколько минут или около того после открытия, что делает ее непригодной для использования. Мне даже не нужно делать ничего особенного. Откройте его, отредактируйте файл (в основном файлы .elm) или просто оставьте его, и он просто выйдет из строя. Даже не ждет, чтобы сначала потерять фокус.

1.0 вылетает почти каждую ночь.
Windows 10 Ent.
Плагины: проверка орфографии и грамматики, ESLint

Хорошо, выпущен релиз для инсайдеров с моими изменениями. Был бы рад, если бы кто-нибудь попробовал: http://code.visualstudio.com/Download#insiders

Кто угодно :)?

Используем это сейчас. Со вчерашнего дня не было сбоев.

@bpasero Сейчас я

@bpasero Я установил его в пятницу, но потом уехал на длинные выходные, мой рабочий компьютер был перезагружен, так что мне не о чем сообщить.

@bpasero Вчера произошла авария. Не спал 3 дня до сбоя.

@bpasero Я все еще вижу случайные

Я тоже.
Windows 8

@bpasero Insider 1.1.0 работает лучше, потребовалась почти неделя, прежде чем он рухнул.

Сейчас возьму 1.1.0 и посмотрю, как пойдет

Кажется, я не могу сделать снимок кучи без сбоя, когда использование памяти превышает 150 МБ.

Каждое утро я разблокирую свой компьютер и обнаруживаю, что VS Code вылетел за ночь.

• Mac OS X 10.11.4 (15E65)
• VS Code 1.1.0-инсайдер

Я обычно оставлял файлы открытыми. Я бегаю с расширениями. Могу ли я использовать какие-либо настройки для сбора дополнительной диагностической информации?

Наш новый релиз для инсайдеров уже вышел (http://code.visualstudio.com/Download#insiders) и включает нашу работу для вкладок / стеков. Это связано с более агрессивной утилизацией ресурсов, потому что как только вы закрываете редактор, мы избавляемся от его основных ресурсов.

Любопытно, могут ли люди какое-то время заниматься этим самостоятельно и сообщать, если что-то улучшится.

Примечание: отныне инсайдеры получают обновления каждую ночь (см. Http://code.visualstudio.com/blogs/2016/05/23/evolution-of-insiders)

@bpasero Я продвинемся в следующие несколько дней

Да, я в основном перешел на инсайдеров из-за терминала. О, сколько я
любить это. Я обнаружил, что редактор стал намного шустрее и легче. Отличная работа.

Есть ли способ заменить "код". В командной строке указать на
инсайдеры?

В среду, 8 июня 2016 г., Элайджа Бейт [email protected] написал:

@bpasero https://github.com/bpasero Сегодня я
посмотрим, как мы продвинемся в следующие несколько дней

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -224539214,
или отключить поток
https://github.com/notifications/unsubscribe/AA-JVM4KoGeXoc2SU5VeEYnxkZyPVWYMks5qJo13gaJpZM4Gnvn5
.

Для меня все еще происходит на 1.2.0. Происходит каждую ночь - работает на Windows 7 Enterprise SP1. У меня тот же вопрос, что и у @garthk

Я обычно оставлял файлы открытыми. Я бегаю с расширениями. Могу ли я использовать какие-либо настройки для сбора дополнительной диагностической информации?

@n Northerncodemky Я имел в виду инсайдерскую версию 1.3.0, в которую включены наши вкладки / стеки (http://code.visualstudio.com/Download#insiders). Я не ожидал больших изменений в 1.2.0.

@bpasero Ааа, ладно - не

@bpasero пока хорошо выглядит !!

На выходных у меня была сборка VSCode Insiders. Приехал в понедельник утром и увидел аварию.

Мне интересно, есть ли какие-либо данные сбоя / дампа телеметрии, которые автоматически отправляются при сбое VSCode? Вроде как отчеты Ватсона.

На прошлой неделе я получил новую машину. Когда я его настраивал, я ставил только сборку релиза (не инсайдеров) - с тех пор я не заметил, чтобы он падал.

@bpasero Я не видел сбоев с

@bpasero с включенными вкладками, открытый проект c # и vscode выдает ошибку через пару минут после последнего обновления хэша инсайдерской фиксации: 5474147bb83618975409dad7d8aa96151d7d1ea1.
ПРИМЕЧАНИЕ: я раньше не включал вкладки.

@ eByte23 можете ли вы убедиться, что это связано с включенными вкладками или нет, попробовав без вкладок?

@bpasero все еще происходит, когда вкладки отключены, но не где-то рядом с серьезностью при включенных вкладках.

Но он сильно заметен и воспроизводится при работе с изображениями, быстрое переключение между большими изображениями как в Insider, так и в v1.2.1

@ eByte23 Я предлагаю открыть новый выпуск по этому вопросу с максимально подробной информацией (например, увеличивается ли объем памяти?).

Конечно можно. Я еще не провел серьезного расследования по этому поводу, но я получу некоторые подробные сведения для вас чуть позже.

VSCode 1.3.1 вылетает у меня примерно два раза в день, один раз за ночь (всегда), а иногда и случайно в течение дня. Он просто вылетел сейчас, когда я открывал его в фоновом режиме, я не использовал его около 2 часов. Также при повторном открытии vscode он теряет мое рабочее пространство, и мне приходится повторно открывать папку проекта, которую он открывал до сбоя. Вкладки и разделения сохраняются после повторного открытия папки.

Я какое-то время оставался открытым в фоновом режиме с несохраненными изменениями, вернулся, начал печатать, и vscode завис на несколько секунд, а затем разбился. он потерял мою работу.

Надеюсь, вы понимаете мое разочарование. Это недопустимо для редактора. Кроме того, в сеансе, который он восстановил, даже не были открыты правильные вкладки, и не было моего места на каждой вкладке.

@DelvarWorld, можешь ли ты рассказать подробнее о своей рабочей среде? можно попробовать запустить с отключенными расширениями, чтобы посмотреть, поможет ли это?

У меня такая же проблема с Linux Mint 17 Qiana (не могу вспомнить, какая это версия ubuntu!). Он у меня просто завис через ~ 2 часа бездействия. Я не забуду проверить использование памяти / процессора в следующий раз, когда это произойдет, хотя я никогда не замечал общего замедления работы других приложений и т. Д., Когда это происходит.

Информация о VSCode:

Версия 1.4.0
Фиксация 6276dcb0ae497766056b4c09ea75be1d76a8b679
Дата 2016-08-04T16: 49: 32.489Z
Оболочка 0.37.6
Рендерер 49.0.2623.75
Узел 5.10.0

Эта проблема исчезла для меня (в версии 1.5.3, Windows 7) - учитывая, что последний комментарий был сделан 2 месяца назад, возможно, это решено?

Я тоже много лет не видел, чтобы это происходило со мной. Текущую версию использую уже несколько месяцев. Выглядит неплохо

Одна и та же. Совершенно не похоже на перегрузку.

Хорошо, мы должны продолжить рассмотрение отдельных проблем и избегать таких чудовищных ошибок, как эта, которую трудно отследить. Если кто-то по-прежнему сталкивается с этой проблемой, сообщите о новых проблемах с более подробной информацией. ПОЖАЛУЙСТА, избегайте взлома существующей проблемы 👍

Я также помню, что видел это раньше, и не видел его много лет, так что это мое подтверждение.