Vscode: Tabrakan saat berlari semalaman

Ini sepertinya terjadi secara konsisten setiap malam saya meninggalkan komputer berjalan. Sepertinya tidak responsif karena CPU sedang maksimal. Mungkin beberapa loop tak terbatas ada di suatu tempat, mungkin ada hubungannya dengan file atau git repo polling?

Saya ingin tahu apakah OS memutuskan untuk menempatkan VSCode (sebenarnya Elektron) ke dalam keadaan di mana ia menyebabkan crash ini. Saya telah melakukan ping ke Electron jika mereka memiliki petunjuk.

Tidak pernah terjadi pada Atom fyi, setidaknya pada 1.19.x (dari memori) dan 1.2.4.

Saya memiliki masalah serupa, sejak pembaruan November (0.10.2 / 0.10.3?). Hampir setiap hari saya log in untuk menemukan jendela VSCode saya yang dibiarkan semalaman semuanya macet (dengan error crash tidak informatif / apologetik standar, "Visual Studio Code has crashed").

Hari ini, setelah pembaruan 0.10.5, saya mengalami crash pertama kali saat berada di sana - sayangnya tidak saat saya aktif menggunakannya.

Menjalankan VSCode pada Windows 7 (64-bit), terutama menggunakannya sebagai editor JS pada proyek yang sangat besar - total hampir satu juta baris (termasuk lib yang perlu saya cari, jadi tidak dikecualikan). Tidak ada masalah kinerja dalam penggunaan normal dan saya tidak melihat adanya penggunaan sumber daya yang berlebihan yang menyebabkan crash hari ini.

Dengan senang hati saya akan memberikan log / info kesalahan yang lebih mendetail jika seseorang dapat mengarahkan saya ke mereka.

Saya mendapatkan masalah dasar yang sama dengan @ Elusive138 , ketika saya membiarkan kode berjalan semalaman (setiap malam), di pagi hari tanpa gagal saya mendapatkan "Visual Studio Code has crashed".

Masih repro untuk saya di vscode 0.10.5, Ubuntu 12.04

Saya mencoba mereproduksi di Windows 10, Mac OS 10.11 dan Ubuntu 15 tanpa hasil. Saya mencurigai masalah kehabisan memori tetapi untuk tidak satu pun di atas, memori meningkat banyak.

Adakah yang bisa mencoba mereproduksi ini dengan kondisi berikut:

• apakah itu mereproduksi ketika membuka hanya contoh kode kosong (File | Tutup Folder)
• apakah itu mereproduksi saat membuka ruang kerja tetapi tidak membuka file apa pun di editor

Ubuntu 12.04, vscode 0.10.5 tidak dapat mereproduksi meninggalkannya selama akhir pekan dengan instance kosong.

Ini mungkin saja kebocoran memori halus, yang terlihat dari penggunaan memori yang relatif tinggi pada sistem ini.

Saya meninggalkan komputer sekitar pukul 17.30, dengan system memory commit perlahan-lahan meningkat - 15.402 MB pada pukul 19.00. Pada 3:09 AM adalah pendekatan yang paling mendekati batas komit sistem (17.682 MB), dan penggunaan komit turun dari 16.218 MB menjadi 15.217 MB. Saya menduga ini mungkin tempat VSCode rusak. Penggunaan komit stabil di sekitar sana sampai logging berhenti sekitar jam 6 pagi (dari ruang disk - penghitung kinerja itu besar!).

Sayangnya saya tidak menyertakan semua proses VSCode jadi saya tidak memiliki logging khusus proses. Saya akan mencobanya malam ini.

Akan sangat berguna jika saya bisa mendapatkan waktu crash. Apakah VSCode meninggalkan log di mana saja?

Sayangnya saya tidak menyertakan semua proses VSCode jadi saya tidak memiliki logging khusus proses. Saya akan mencobanya malam ini.

Itu akan sangat berguna, terima kasih!

Saat ini vscode tidak masuk ke disk.

@ Elusive138 dapatkah Anda berbagi ruang kerja yang Anda biarkan vscode berjalan?

@bpasero Sayangnya tidak. Ini didasarkan pada Ext JS, dan di situlah sebagian besar kode (perpustakaan) berada. Saya akan mencoba ruang kerja Ext JS yang bersih setelah pengujian lain ini selesai, dan melihat apakah ada repro di sana.

@ Elusive138 ya sebaiknya memiliki sampel untuk direproduksi di pihak kami.

Salah satu proses code.exe (kode # 3 di log, terlampir) tampaknya bocor. Komit dimulai sekitar 200 MB pada pukul 17.30, dan mencapai 460 MB pada pukul 09.00 pada hari berikutnya, dengan peningkatan konstan:

Jumlah pegangan tidak naik.

vscode_memleak.zip

Tidak ada crash kali ini, mungkin karena saya tidak memiliki banyak program intensif memori yang berjalan. Mungkin dapat mengujinya di VM dengan batas komit rendah nanti.

Log ini dibuat dalam semalam dengan 3 ruang kerja besar yang terbuka di jendela berbeda. Saya akan mencoba mempersempitnya ke ruang kerja yang dapat saya bagikan.

@ Elusive138 akan sangat membantu untuk memahami detail proses yang bocor. Dapatkah Anda menemukan PID-nya dan kemudian mencetak meta data lengkapnya menggunakan ps aux | grep <pid> ?

Ah, mungkin ini di Windows, tidak yakin :)?

@bpasero Baris perintahnya adalah:

"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

Rincian lainnya:

Pohon proses:

Ini setelah penggunaan sehari penuh. Seperti yang Anda lihat, penggunaan memori proses tampaknya telah meningkat secara linier dalam waktu itu (ruang kerja yang sama).

Ah ... ini bahkan bukan yang buruk.

4772 adalah proses yang bocor dalam semalam. Yang lainnya tampaknya telah meningkat karena saya gunakan pada siang hari ... Saya pikir.

@ Elusive138 ini sepertinya Anda memiliki beberapa jendela yang terbuka dengan Kode apakah itu benar?

@bpasero Ya, ujian tadi malam memiliki tiga jendela terbuka dengan ruang kerja berbeda. Saya akan mencobanya malam ini hanya dengan satu, di ruang kerja Ext JS yang bersih seperti yang disebutkan di atas.

Kedengarannya bagus!

Sayangnya, tidak ada teguran ... ini aneh. Apa yang dapat menyebabkan kebocoran dalam proyek tertentu itu?

Ngomong-ngomong, ini mungkin berbeda dari masalah awal @Tyriar . Miliknya tidak responsif, milik saya dan gwynjudd macet dengan dialog kesalahan ..? Dalam hal ini mungkin kita harus membuat masalah baru ...

@ Elusive aneh. apakah itu mereproduksi jika Anda hanya membuka ruang kerja itu tanpa membuka file JS?

Selain itu, mungkin kita dapat mulai membuat profil ini menggunakan alat pengembang chrome tempat Anda dapat melakukan pengambilan gambar tumpukan. Untuk itu, lakukan saja snapshot sebelum dan sesudah beberapa saat untuk melihat kemana perginya memori tersebut.

@bpasero Oh, saya benar-benar lupa tentang devtools itu. Saya akan mencobanya malam ini.

@bpasero Cuplikan Heap Main.js , workerMain.js dan workerMain.js (2) tidak benar-benar berubah. Mungkin paling banyak 5 MB.

Menambahkan lebih banyak tentang situasi saya, saya mencoba menjalankannya dengan folder terbuka (yang macet) tetapi tidak ada file yang berfungsi dan itu tidak terjadi dalam semalam. Jadi itu hanya terjadi ketika folder terbuka dan ada file yang berfungsi aktif.

@ Elusive138 kami menelurkan proses lain yang dapat menyebabkan tekanan memori dan proses tersebut tidak akan muncul di profil heap. Namun dari salah satu posting Anda sebelumnya, tampaknya Anda telah mengidentifikasi memori tinggi yang berasal dari proses renderer dan yang seharusnya muncul di bawah snap shot heap. Apakah Anda yakin Anda melihat memori tinggi untuk proses penyaji dan bukan untuk turunannya? karena penyaji adalah induk dari proses lain yang dimunculkan, misalnya proses untuk melihat file.

@Tyriar, bisakah Anda lebih spesifik apa yang Anda maksud dengan itu. apakah Anda tidak membuka file apa pun di editor atau Anda benar-benar memiliki bagian file yang berfungsi kosong?

Alasan saya bertanya tentang membuka file atau tidak adalah karena misalnya layanan bahasa JS hanya dimulai setelah Anda membuka file JS. Hal yang sama berlaku untuk layanan bahasa lainnya. Jadi jika masalah ini muncul kembali tanpa membuka file di editor, kemungkinan besar kebocoran memori tidak ada di layanan bahasa apa pun, tetapi di tempat lain.

Hal lain yang patut untuk dicoba: Jalankan tanpa ekstensi apa pun untuk melihat apakah mungkin ekstensi bocor. Anda dapat menjalankan dengan --disable-extensions untuk melakukannya.

@bpasero Saya yakin baris perintah yang disediakan di atas adalah untuk 4772, yang disorot (bocor) di tangkapan layar. Itu mengatakan --type=renderer .

Saya akan membiarkannya berjalan selama akhir pekan lagi dan melihat apa yang terjadi. Saya tidak berpikir saya telah melakukan tes bersih tanpa file JS yang terbuka.

@bpasero Saya yakin saya tidak membuka file (di sebelah kanan), hanya file yang berfungsi di atas pohon. Jika saya ingat ketika saya selesai bekerja, saya akan mencoba memeriksa dengan file terbuka dan catat bahasanya.

Saya tidak tahu pasti tetapi mungkin itu bukan file JavaScript ketika milik saya macet, kemungkinan besar C ++, Java atau tanpa bahasa. Saya pasti akan memeriksanya.

@Tyriar jika mereproduksi hanya dengan memiliki sesuatu di bawah file yang berfungsi dan dengan semua editor ditutup (langsung dari startup - itu penting), kami mungkin akan melakukan sesuatu.

@bpasero Saya mungkin mencoba membuka banyak contoh dalam kondisi yang berbeda-beda sebelum meninggalkan pekerjaan pada hari Jumat dan melihat apakah saya dapat menyelesaikan semua eksperimen saya dalam satu malam. Kecuali Anda memiliki alasan untuk percaya satu contoh vscode gantung akan merusak yang lainnya?

@Tyriar ya sepenuhnya, jika Anda memiliki lebih dari satu jendela yang terbuka, semuanya menambah total memori yang digunakan dan semuanya akan macet. Ini karena ketika Anda membuka banyak jendela, mereka masih berbagi semua satu proses induk dan satu batas memori sekitar 1-1,5 GB. Untuk benar-benar memahami dari mana asal kebocoran, sebaiknya mengukur 1 jendela yang terisolasi dalam kondisi berikut:

• tidak ada ekstensi yang diaktifkan melalui --disable-extensions (ekstensi yang menghabiskan banyak memori atau kebocoran juga akan menyebabkan crash)
• tidak ada file yang dibuka saat startup (hanya menutup file setelah startup sudah terlambat)
• tidak ada file yang berfungsi di bawah file yang berfungsi

btw satu-satunya hal untuk file kerja yang mungkin berdampak adalah bahwa untuk setiap file kerja yang tidak berada di dalam ruang kerja kami menginstal pengamat file untuk melihat perubahan. mungkin ini yang menyebabkan kebocoran, akan mengejutkan sekalipun. Selain itu, kami tidak menginstal pengamat jika file tersebut berada di dalam ruang kerja yang dibuka, hanya untuk file di luar.

@bpasero Tidak ada kebocoran jika tidak ada file yang terbuka (?). Saya akan mencoba ruang kerja bersih malam ini setelah memastikan untuk membuka beberapa.

Saya mencoba selama akhir pekan dengan pengaturan berikut:

1. Luncurkan dengan Code --disable-extensions
2. Buka file JavaScript ~ 1300 baris

Memori dan CPU kurang lebih sama pada Jumat malam dan Senin pagi.

@Tyriar Apakah ini hanya membuka ruang kerja kosong dengan satu file atau membuka folder terlebih dahulu, lalu file darinya?

@bpasero Membuka ruang kerja kosong, saya tidak membuka folder dan tidak ada folder yang terbuka saat saya meluncurkan

Baiklah senang mengetahuinya. Jadi ini tampaknya terkait dengan membuka folder (berpotensi besar). Masih untuk mencari tahu apakah hanya membuka folder ini sudah cukup atau membuka file hanya akan memicunya.

@bpasero Saya membuka folder besar tanpa file yang terbuka selama akhir pekan, tanpa peningkatan penggunaan memori yang nyata. Saya akan mendapatkan hasil tes besar-folder-dan-buka-file dengan semoga ruang kerja yang dapat direproduksi / dibagikan dalam waktu sekitar 7 jam.

@bpasero folder di mana saya mengalami crash sebelumnya akan menjadi 13000-14000 file yang kuat, ini termasuk git repo yang sekitar 2000 dengan sendirinya.

Saya kira saya akan memeriksa ulang apakah crash masih terjadi di versi terbaru berikutnya karena sudah lama sejak saya melihatnya (karena pengujian).

Dan saya berasumsi ini adalah ruang kerja JS?

@bpasero py, cpp, js, html, css

Oke, tampaknya ini mereproduksi penggunaan memori yang naik perlahan, jika dalam skala yang lebih kecil: VSCodeTest.zip . Saya membuka /ext/build/ext-all-debug.js .

(Ya, ini adalah 7z di dalam zip ... GitHub tidak mengizinkan saya mengunggah 7z atau xz secara langsung, dan zip dan gzip terlalu besar)

@ Elusive138 berapa peningkatannya untuk Anda di rata-rata? Saya memiliki ruang kerja dengan beberapa file JS yang terbuka selama 2 jam sekarang tanpa ada peningkatan memori.

@bpasero Maaf, saya kesulitan mereproduksi lagi. Saya rasa saya memiliki repo git yang tersesat dalam upaya sebelumnya, yang tidak termasuk dalam arsip di atas. Saya akan memberi tahu Anda jika saya mendapatkan hasil yang lebih konkret.

Akan sangat membantu jika memungkinkan untuk membuka beberapa instance independen ... dibatasi untuk satu pengujian dalam semalam cukup lambat. Apakah Anda kebetulan membawa seluruh bendera Chromium untuk profil terpisah?

Dimungkinkan untuk membangun beberapa versi Kode yang dapat berjalan secara paralel, meskipun kami belum mendokumentasikannya. Jika Anda mengubah nilai di https://github.com/Microsoft/vscode/blob/master/product.json sehingga berbeda dan kemudian membuat dari baris perintah, Anda dapat memulai beberapa contoh berbeda. Pengenal yang harus unik adalah:

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

Windows 8.1. Di Code, buka folder untuk repositori git yang berisi 39.000 file di pagi hari.
Melakukan sangat sedikit, beberapa pengeditan kecil di beberapa file.
Di penghujung hari, Ukuran Komit yang dilaporkan oleh Pengelola Tugas adalah 672.164 ribu.
Itu tumbuh dengan mantap sepanjang hari, bahkan ketika saya tidak ada dalam program.

@gushie, apakah ada kemungkinan repo ini dapat dibagikan dengan saya? juga, apa memori awal yang dilaporkan?

@bpasero Maaf, saya tidak diizinkan untuk membagikan repo itu sendiri tetapi jika ada detail tentangnya yang mungkin membantu, tidak termasuk konten file itu sendiri, beri tahu saya. Proses awalnya dimulai sekitar 110MB, dengan cepat berkembang menjadi sekitar 130MB sebelum kembali ke 90MB. Ini kemudian akan tumbuh dengan mantap dari titik ini dan seterusnya. (Ada 5 proses code.exe lain yang bervariasi dari 4MB hingga 30MB tetapi ini tidak berkembang secara signifikan. Hanya ada satu Jendela Kode)

Saya tidak tahu apa Ukuran Komit terakhir dari kemarin karena prosesnya macet ketika saya kembali ke sana hari ini.

@gushie Saya telah menggunakan Monitor Kinerja pada proses code.exe untuk memantau "Ukuran Pribadi".

Cukup menjengkelkan karena kami tidak dapat berbagi ruang kerja yang bermasalah! Saya ingin tahu apakah ada yang mengalami ini dengan sesuatu yang open-source. Mencari kesamaan: apakah repo Anda pernah digunakan dengan git-svn?

@bpasero Terima kasih, jika proses yang saya tinggalkan belum ditegur ketika saya kembali pada hari Senin, saya mungkin mencoba membuat beberapa salinan tambahan. Akan perlu mencari cara untuk melacak mana yang, meskipun .. yang mungkin menjadi masalah.

@ Elusive138 Kami menggunakan alat Atlassian, jadi SourceTree terhubung ke server Stash pribadi

Ah, itu sangat berbeda dariku. Apakah repo Git lokal (w / Git Extensions) yang terhubung ke server SVN. Pengujian saya saat ini adalah dengan git repo berdasarkan vscode ... semoga itu akan repro dan saya dapat membagikannya.

@gushie apakah itu mereproduksi jika Anda hanya membuka ruang kerja tanpa membuka file apa pun? coba tutup dulu semua file dan mulai ulang untuk mendapatkan pengaturan ini. jika itu tidak mereproduksi, apakah itu mereproduksi jika Anda membuka ruang kerja dan membuka satu file JS dan membiarkannya seperti itu?

@bpasero Saya telah membiarkannya terbuka hanya dengan satu file kerja yang belum diedit tadi malam, dan memeriksa pagi ini penggunaan memori tampaknya tidak banyak berubah. Sekarang saya telah mengedit dan melakukan build pada file tersebut, dan akan membiarkan ini untuk melihat apa yang terjadi.

Catatan sampai saya membaca masalah ini, saya belum pernah membersihkan file yang berfungsi. (Saya tidak benar-benar membutuhkannya, saya biasanya mengabaikan panel ini dan mengganti file melalui penjelajah file proyek di bawahnya, atau dengan Ctrl + E).

Macet lagi, kali ini setelah penggunaan biasa tetapi dibiarkan dalam keadaan ini:

• ~ 14000 folder file terbuka
• 5 file kerja aktif (.cc, .java, .h, .py, .json)
• Tidak ada file yang terbuka di editor teks

ps aux keluaran:

❯ 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

Seperti yang disebutkan, meskipun ini terjadi setelah penggunaan biasa dan tidak dalam mode aman sehingga _bisa_ karena ekstensi?

Saya meninggalkan satu file dengan edit kecil terbuka, hanya file itu di file kerja. Kalau tidak, tak tersentuh sepanjang hari. Memori tidak meningkat dari nilai awalnya.

@Tyriar baik proses yang Anda tunjukkan adalah layanan menonton file kami dan di Linux / Mac kami menggunakan Chokidar untuk itu (https://github.com/paulmillr/chokidar). Ini akan menunjukkan bahwa mereka mengalami kebocoran saat menonton file. Apakah ada tugas build yang terus berjalan dan mengubah file?

@gushie apakah ini tanpa membuka folder?

@bpasero Aku membuka foldernya. Jelas ada beberapa tindakan yang tampaknya memicu kebocoran memori di luar pembukaan awal file di dalam folder. Saya akan terus memantau dan mencoba mempersempitnya.

@bpasero Itu adalah satu-satunya proses terkait vscode yang dapat saya lihat di keluaran, mungkin saja tidak terlihat di keluaran karena sudah dimatikan karena tidak responsif? Seperti yang ditunjukkan bahwa proses tersebut hanya menggunakan 0,5% memori dan 0% CPU. Saya pikir dari penemuan saya baru-baru ini, masalah yang saya alami mungkin bukan karena layanan JS.

Btw bahkan jika kami tidak menemukan alasan untuk ini hingga akhir bulan, saya mendorong perubahan sehingga dialog macet yang Anda dapatkan secara default memilih tindakan untuk membuka kembali jendela sehingga Anda dapat terus bekerja di tempat yang Anda tinggalkan. Ini juga bagus untuk kasus di mana Anda memiliki banyak jendela yang terbuka dan hanya satu yang macet.

(satu hal yang hilang dan untuk masa mendatang adalah dapat secara berkala menghapus status UI ke disk sehingga membuka kembali juga memulihkan lingkungan kerja Anda sebelumnya)

@bpasero : +1: itu akan membantu.

VS telah crash setiap pagi selama sekitar satu bulan sekarang. Saya telah sampai pada akhir kesabaran saya.

Saya harap ini diperlakukan sebagai bug PRI 0 karena editor yang waras tidak akan sering crash.

Tolong beritahu saya bagaimana saya bisa mengetahui mengapa hal ini terjadi. Saya telah melihat ini terjadi di komputer lain juga.

@nojvek dapatkah Anda berbagi dengan saya ruang kerja tempat hal ini terjadi?

Saya tidak yakin apa yang Anda maksud dengan berbagi ruang kerja. Ini adalah proyek skrip / HTML / CSS dengan sedikit c ++. Sekitar ~ 1500 file dan 80.000 baris kode.

Apakah ada cara di VS untuk menampilkan crashdumps?

@nojvek Saya ingin memiliki ruang kerja tempat saya dapat menjalankan Kode untuk mereproduksi masalah ini. Kami menduga ini terkait dengan kebocoran memori di suatu tempat, hanya tidak jelas di mana. Jika Anda dapat mengirimkan saya zip dari ruang kerja atau mungkin URL git jika itu open source.

Benjamin,

Kode sumber internal Microsoft dan saya rasa saya tidak dapat memberikannya kepada Anda.

Jika ada beberapa alat pemantauan memori yang dapat saya tambahkan beri tahu saya.

Apakah akan berhasil jika saya mengambil snapshot memori dengan debugger chrome yang disematkan
di vscode setiap beberapa jam untuk melihat apa yang terjadi?

Pada hari Sabtu, 23 Januari 2016, Benjamin Pasero [email protected]
menulis:

@nojvek https://github.com/nojvek Saya ingin memiliki ruang kerja yang
Saya dapat menjalankan Kode dengan untuk mereproduksi masalah ini. Kami menduga ini terkait dengan a
kebocoran memori di suatu tempat, hanya tidak jelas di mana. Jika Anda dapat mengirimkan saya zip
ruang kerja atau mungkin URL git jika itu open source.

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -174192367.

Ya snapshot memori akan membantu jika dan hanya jika kebocoran ini ada di dalam sisi utama VS Code. Namun, tampaknya setidaknya dalam satu kasus kebocoran ada di salah satu proses yang kami buat (pengamat file). Mungkin Anda dapat mengidentifikasi menggunakan penjelajah proses, proses mana yang terus meningkat dalam hal konsumsi memori.

Jika membantu memberi saya kode sumber: Saya bekerja untuk Microsoft;)

Saya akan berbicara dengan manajer saya. Ini ada di repo Windows jadi saya harus melakukannya
berhati-hatilah.

Dari utas tersebut tampaknya chokidar digunakan untuk pengamat file. Sementara waktu
kembali saya bermain dengan kode sumber. Itu sedikit spageti.

Saya akan melihat apakah saya dapat memuat chokidar pada aplikasi node sederhananya sendiri dan melihat apakah itu
pelakunya.

Btw ada alasan khusus mengapa vs perlu menggunakan chokidar? Ada lainnya
pengamat file lintas platform kan?

Pada hari Minggu, 24 Januari 2016, Benjamin Pasero [email protected]
menulis:

Ya snapshot memori akan membantu jika dan hanya jika kebocoran ini ada di dalam utama
sisi VS Code. Namun, tampaknya setidaknya dalam satu kasus kebocoran itu
di salah satu proses yang kami buat (pengamat file). mungkin kamu bisa
mengidentifikasi menggunakan penjelajah proses, yang prosesnya terus meningkat
hal konsumsi memori.

Jika membantu memberi saya kode sumber: Saya bekerja untuk Microsoft;)

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -174269028.

Chokidar digunakan di Mac dan Linux, jika Anda menggunakan Windows, kami menggunakan pengamat file C #. Saya senang menerima PR dengan solusi pengamat lintas file yang berfungsi dan berkinerja baik :)

Anda tahu pada node 4.0, fs.watch distabilkan pada windows dan mac. Lihat: https://github.com/Microsoft/TypeScript/issues/4643.

Typecript memiliki logika menonton file / direktori lintas platform yang cukup solid. https://github.com/Microsoft/TypeScript/blob/931d162620c7e09377c12875834e1838c4cdd51b/src/compiler/sys.ts

Saya akan mencoba untuk mendapatkan build lokal dari kode VS dengan perubahan dan melihat apakah masih macet. Jika tidak maka saya pasti akan mengirim PR.

Saya tahu itu menjadi jauh lebih baik dengan menggunakan panggilan arloji rekursif pada direktori dan dengan demikian menghindari keharusan melampirkan pendengar arloji per folder, tapi saya pikir kejadian kadang-kadang masih kehilangan nama file / folder, setidaknya dalam beberapa kasus. Saya merasa lebih confi menggunakan C # di sini.

Saya berhasil mendapat teguran hari ini. Saya baru saja mengalami crash sebelum saya membuka konsol alat Pengembang untuk mengambil snapshot memori.

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

Sepertinya server skrip membutuhkan waktu sekitar 200MB.
Penyaji menghabiskan sekitar 800MB dan kemudian macet.

Ketika saya mendapatkan sekitar 500MB penggunaan, saya akan mencoba untuk mengambil snapshot memori. Proses --renderer adalah proses webkit kan?

Ini setelah dua hari sejak terakhir kali saya melihat tabrakan. Tampaknya menggunakan alat ini selama 8 jam mengedit banyak file TS yang menambah penggunaan lebih cepat.

Bagus, proses renderer adalah proses utama editor. Jika Anda dapat melakukan snapshot memori di sana, itu akan membawa kita lebih jauh. Sayangnya snapshot tidak akan berfungsi untuk proses lainnya, tetapi tampaknya tidak masalah.

Apakah normal untuk tscse (server skrip) untuk mengkonsumsi 200MB?

Pada hari Selasa, 26 Jan 2016 jam 21:29, Benjamin Pasero [email protected]
menulis:

Bagus, proses renderer adalah proses utama editor. Jika kamu
dapat melakukan snapshot memori di sana itu akan membawa kita lebih jauh. Sayangnya
snapshot tidak akan berfungsi untuk proses lainnya, tetapi tampaknya berhasil
baiklah.

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -175408302.

Ya, sangat mudah.

Lol! Saya sedang dalam proses mengambil cuplikan heap dan VS macet.

Saya akan mencoba lagi dan melihat apakah saya lebih beruntung besok.

Apakah ada cara untuk memberi tahu vscode untuk meningkatkan batas memorinya sehingga tidak macet saat mencoba mengambil cuplikan heap?

Saya pikir apa yang terjadi adalah bahwa mengambil snapshot Anda menyebabkan pengecualian memori: - /. Tidak ada cara untuk mengubah batas memori, itu adalah hardcode di V8.

Mungkin mencoba mengambil snapshot sedikit lebih awal, sebelum penggunaan memori meningkat begitu tinggi? Apakah itu peningkatan bertahap?

Saya tidak dapat mereproduksi (tidak ada kerusakan, penggunaan memori yang wajar) selama dua minggu terakhir ini. Satu-satunya perbedaan yang dapat saya pikirkan adalah ekstensi PowerShell diperbarui dari 0.1.0 menjadi 0.3.1 - tetapi saya tidak memiliki file PS di ruang kerja, dan itu macet dengan ekstensi yang dinonaktifkan pada saat itu.

Saya berhasil mendapatkan dump sekitar 300MB yang digunakan oleh proses --renderer. Itu jatuh 10 detik setelah saya membuangnya.

Tampaknya sebagian besar penggunaan ada di pohon DOM.

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

Semoga ini membantu.

Hmmmm, saya ingin tahu apakah profiler mengatakan yang sebenarnya di sini. Saya melihat semua elemen pohon dan kami mungkin juga mengalami kebocoran di pohon, tetapi saya akan terkejut bahwa kebocoran ini dapat menyebabkan kehabisan memori dalam waktu yang singkat.

Saya mengambil beberapa kesedihan lagi.

Tampaknya membuka file .min.js menyebabkan lompatan besar dalam memori. Bahkan setelah menutup file, memori sepertinya tidak turun. Di antara semua dump memori, tampaknya DOM adalah dominatornya.

Juga tidak yakin mengapa ada dua proses perender. Mungkin salah satunya adalah chrome devtools. Tapi saya sangat dekat dengan 1 pertunjukan.

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

Saya mengambil tangkapan layar dari dua proses yang memakan ~ 500MB ram.

Ya, salah satunya adalah devtools. Diharapkan memori naik saat Anda membuka file. Tetapi saya ingin memahami bagaimana VS Code yang berjalan sepanjang malam tanpa aktivitas meningkat dalam penggunaan memori hingga macet.

Nah repro tersebut adalah:
Mulai kode vs.
Buka satu atau dua file js / ts di folder besar dengan banyak file .tsconfig.
Lakukan beberapa scrolling / editing.
Tutup semua file yang berfungsi.
Taruh di genap pada suhu 200c semalaman.
Kue!

Pada hari Jumat, 29 Januari 2016, Benjamin Pasero [email protected]
menulis:

Ya, salah satunya adalah devtools. Diharapkan memori naik saat Anda membukanya
file. Tapi saya ingin memahami bagaimana VS Code itu berjalan
malam tanpa aktivitas meningkat dalam penggunaan memori sampai macet.

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -177087988.

@nojvek Apakah .tsconfig s diperlukan untuk repro? Karena saya pernah mengalami crash di masa lalu tanpa ada yang berhubungan dengan TS sama sekali. Meskipun aku bahkan tidak bisa menegur itu lagi ...

Proyek kami kebetulan memilikinya. Bisa jadi ikan haring merah.

Pada hari Sabtu, 30 Januari 2016, Bob [email protected] menulis:

@nojvek https://github.com/nojvek Apakah .tsconfigs diperlukan untuk
teguran? Karena saya pernah mengalami crash di masa lalu tanpa apa pun yang berhubungan dengan TS
semua. Meskipun aku bahkan tidak bisa menegur itu lagi ...

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -177198518.

Satu-satunya file. * Yang kita miliki di folder kita adalah folder .git dan .gitignore

@nojvek, apakah Anda menggunakan server skrip jenis kustom dengan proyek tersebut, atau TS out of the box yang kami kirimkan dalam 0.10.6? Yang kami kirimkan di 0.10.6 adalah TypeScript 1.7.5

@bpasero @nojvek jika ini adalah masalah memori di sisi JS. Anda dapat membedakan cuplikan heap di Chrome.

1. Ambil sebuah foto.
2. Lakukan tindakan yang menyebabkan kebocoran memori.
3. Paksa pengumpulan sampah. Jika tidak, cuplikan heap berikutnya akan menyertakan objek.
4. Jepret lagi.
5. Diff keduanya snapshot.

Semuanya bisa dilakukan di Chrome Devtools di atas. Kekuatan pengumpulan sampah ada di tab garis waktu, ikon sampah. Dan perbedaan dilakukan dengan hanya memilihnya pada penjelajah snapshot pada menu filter.

Cukup laporkan objek mana yang dipertahankan dan jalur yang mungkin dipertahankan (tepat di bawah tabel heap). Dan itu semua data yang dibutuhkan untuk memperbaiki masalah ini.

Tidak perlu menunggu sepanjang hari untuk mengumpulkan data tentang crash: wink:

Tautan Dropbox yang saya kirim memiliki tiga foto panas yang diambil dengan selang waktu setengah jam.
Saya tidak melakukan pengumpulan sampah paksa. Akan memberikan trik itu.

Pada hari Minggu, 31 Januari 2016, Tingan Ho [email protected] menulis:

@bpasero https://github.com/bpasero @nojvek https://github.com/nojvek
jika ini adalah masalah memori di sisi JS. Anda dapat membedakan bidikan heap snap
Chrome.

1. Ambil sebuah foto.
2. Lakukan tindakan yang menyebabkan kebocoran memori.
3. Paksa pengumpulan sampah. Jika tidak, cuplikan heap berikutnya akan
   termasuk objeknya.
4. Jepret lagi.
5. Diff keduanya snapshot.

Semuanya bisa dilakukan di Chrome Devtools di atas. Kekuatan sampah
koleksi ada di tab garis waktu, ikon sampah. Dan perbedaannya adalah
dilakukan hanya dengan memilihnya pada penjelajah snapshot pada menu filter.

Cukup laporkan objek mana yang dipertahankan dan kemungkinan mempertahankan jalur (tepat di bawah
tabel heap). Dan itu semua data yang dibutuhkan untuk memperbaiki masalah ini.

Tidak perlu menunggu sepanjang hari untuk mengumpulkan data tentang kerusakan [image:
:mengedipkan:]

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -177462412.

Saya memiliki masalah yang sama, VS Code terus-menerus mogok, tidak hanya dalam semalam, bahkan setelah 30 menit dalam keadaan diam.
Saya menggunakan Windows 7, 64bit dan versi terbaru dari VS Code. Mengenai proyek itu sendiri, itu adalah proyek js yang sangat besar, dengan node_modules dan bower_components juga dimuat. Benar-benar memiliki sekitar 40K file.

Langkah-langkah untuk mereproduksi:
1) Buka folder project (dengan banyak file), buka beberapa file agar bisa masuk daftar Working Files.
2) Buka pengelola tugas.
3) Letakkan kursor untuk memfokuskan beberapa file di VS Code
4) Perhatikan saat memori meningkat selama waktu.

Dapatkah orang-orang dengan ruang kerja JS yang melihat masalah ini memberikan percobaan 0.10.7 insiders kami (https://vscode-builds.azurewebsites.net/insider) dengan opsi untuk menggunakan Salsa sebagai layanan bahasa JS: https://github.com /Microsoft/vscode-docs/blob/vnext/release-notes/latest.md#javascript --- salsa-preview

Terima kasih!

1 untuk masalah ini. Juga muncul di Windows. Ini benar-benar menjengkelkan dan saya tidak menyukainya.

@bpasero Saya ingin mencoba versi baru, tetapi setiap kali saya mencoba mengakses tautan yang Anda berikan (https://vscode-builds.azurewebsites.net/insider), saya mendapatkan halaman pesan kesalahan yang sangat tidak membantu dengan teks berikut :

Masuk
Maaf, tapi kami kesulitan memasukkan Anda.
Kami menerima permintaan yang buruk.

Informasi teknis tambahan:
ID Korelasi: e477dc1b-c193-4cf9-864b-1d3fdbba4f34
Stempel waktu: 03-02-2016 19: 37: 17Z
AADSTS50020: Akun pengguna ' [email protected] ' dari penyedia identitas ' https://sts.windows.net/5a7d8144-6966-4b1e-8147-de672a307ea0/ ' tidak ada di penyewa 'Microsoft' dan tidak dapat mengakses aplikasi ' 9d5f02f6-ffd9-4e80-92d5-e42c85e09bc9 'dalam penyewa tersebut. Akun tersebut perlu ditambahkan sebagai pengguna eksternal di penyewa terlebih dahulu. Keluar dan masuk lagi dengan akun pengguna Azure Active Directory yang berbeda.

Saya tidak dapat mengunduh build dan mencobanya karena masalah ini.

Ah maaf, salah link, mohon gunakan https://code.visualstudio.com/insiders

@bpasero terima kasih Saya memiliki orang dalam yang membangun berjalan dengan Salsa sebagai layanan bahasa JS. Saya akan memberi tahu Anda bagaimana kelanjutannya pada hari berikutnya atau lebih

@bpasero , saya mencoba rilis orang dalam dan masalah masih ada, setelah satu malam di idle VS Code macet.

@milenkovic @gwynjudd Anda juga harus mengikuti langkah-langkah untuk mengaktifkan Salsa seperti yang dijelaskan di https://github.com/Microsoft/vscode-docs/blob/vnext/release-notes/latest.md#javascript --- salsa- pratinjau

@bpasero , Anda benar, mengaktifkan Salsa untuk memperbaiki masalah. Saya meninggalkan VS Code dibuka selama akhir pekan dan masih tidak crash.

Senang untuk mendengarnya! Akan menarik jika orang lain dapat memverifikasi ini juga dengan mencoba.

@bpasero Saya telah mengaktifkan salsa dan membiarkannya berjalan selama akhir pekan. Pagi ini pesawat itu jatuh.

Skrip jenis diinstal

$ 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

Saya telah menetapkan settings.json menjadi

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

dan pengaturan lingkungan

$ setx VSCODE_TSJS 1

SUCCESS: Specified value was saved.

Saya masih tidak melihat salsa di footer orang dalam kode VS.

@nojvek Saya pada dasarnya melakukan apa yang Anda lakukan, dan saya melihat Salsa di footer, tetapi hanya ketika file .js terbuka dan terlihat di editor

@gwynjudd Saya berasumsi bahwa Anda mendapat dialog macet dan sekarang dengan 0.10.8 keluar dapat membuka kembali jendela?

@bpasero ya Saya mendapat dialog macet baru dan dapat memulai ulang

Gwyn Judd

-------- Pesan asli --------
Dari: Benjamin Pasero
Tanggal: 02/09/2016 19:13 (GMT + 12: 00)
Kepada: Microsoft / vscode
Cc: Gwyn Judd
Subjek: Re: [vscode] Crash saat berjalan semalaman (# 508)

@gwyn juddhttps: //github.com/gwynjudd Saya berasumsi bahwa Anda mendapatkan dialog crash dan sekarang dengan 0.10.8 out dapat membuka kembali jendela?

Balas email ini secara langsung atau lihat di Gi tHubhttps: //github.com/Microsoft/vscode/issues/508#issuecomment -181726111.

@gwynjudd apakah ini hanya ruang kerja JS atau jenis file lain seperti PHP yang disertakan?

@bpasero ada banyak jenis file termasuk skrip tipe, skrip java, css, less, aspx, cs

Gwyn Judd

-------- Pesan asli --------
Dari: Benjamin Pasero
Tanggal: 02/09/2016 22:49 (GMT + 12: 00)
Kepada: Microsoft / vscode
Cc: Gwyn Judd
Subjek: Re: [vscode] Crash saat berjalan semalaman (# 508)

@gwyn juddhttps: //github.com/gwynjudd apakah ini hanya ruang kerja JS atau jenis file lain seperti PHP yang disertakan?

Balas email ini secara langsung atau lihat di Gi tHubhttps: //github.com/Microsoft/vscode/issues/508#issuecomment -181786273.

Dengan bangunan baru itu telah macet setiap pagi saat meninggalkannya berjalan semalaman. Saya hanya menginstal ekstensi ini (di build baru, dalam rilis build saya memiliki ekstensi yang berbeda):

Pagi ini ketika saya mulai bekerja, tidak ada yang jatuh. Saya tidak melakukan sesuatu yang berbeda sebelum saya pulang kerja pada hari Jumat.

Harus mencoba mereproduksi dengan ruang kerja Chromium menggunakan Ubuntu karena tampaknya @Tyriar memiliki pengaturan seperti itu ketika itu terjadi.

Ikuti petunjuk di sini untuk mendapatkan kode https://www.chromium.org/developers/how-tos/get-the-code

Saya juga melihat kelambatan dalam Kode setelah beberapa waktu menggunakannya, dan akhirnya macet. Saya perhatikan bahwa ketika menjadi lambat, saya bisa membuatnya berjalan lebih lancar jika saya menekan F1 dan mengetik 'Reload Window'. Tampaknya itu menyelesaikan masalah untuk saat ini dan kemudian saya dapat mengatasinya untuk saat ini. Saya pasti tertarik untuk melihat ini diperbaiki.

Dari membaca utas ini, saya juga menebak itu karena proses render, meskipun saya belum melakukan pengujian apa pun dengannya, dan tampaknya terjadi terlepas dari jumlah file yang berfungsi dalam daftar di panel explorer, apakah atau tidak sebuah file terbuka saat Kode dimuat, mungkin ukuran file yang saat ini sedang dikerjakan, dan saya tidak yakin apakah itu ada hubungannya dengan pemeriksa git diff atau tidak, tapi saya ragu itu akan menjadi pelakunya .

Saya juga menggunakan Mac OS X El Capitan 10.11.3 dan belum benar-benar melihat masalah pada Windows saat saya menggunakannya di rumah, tetapi saya tidak memiliki pohon kerja yang sangat besar untuk proyek apa pun di rumah, hanya folder besar tempat saya bekerja di tempat kerja.

Saya berharap kedua masalah tersebut terkait, tetapi saya khawatir keduanya tidak akan terjadi: Kebanyakan orang di sini melihat Kode mogok saat membiarkannya berjalan tanpa interaksi pengguna, yang tampaknya sangat mencurigakan. Membuat Kode pada akhirnya macet dengan pengecualian kehabisan memori saat menggunakannya untuk waktu yang lama mungkin disebabkan oleh kebocoran memori lainnya. Idealnya kedua masalah itu sama :)

Secara teknis, sepertinya lambat dan macet bahkan jika saya tidak menggunakannya juga, tetapi saya tidak yakin apakah mereka juga mengalami hal yang sama, dalam kasus itu. Bagaimanapun, gejalanya paling tidak tampak serupa. Jika ternyata masalah saya tidak terkait, saya dapat membuat masalah terpisah.

@cwadrupldijjit jika Anda melihat masalah mogok dalam semalam, akan sangat membantu untuk mendapatkan akses ke ruang kerja jika memungkinkan.

Saya akan lihat apa yang dapat saya lakukan. Saya biasanya menidurkan Mac di malam hari, jadi tidak ada yang terjadi selama waktu itu. Saya akan mencoba menyimpannya di malam hari dan memberi tahu Anda di pagi hari jika terjadi sesuatu. Saya juga akan terus mengabari Anda jika Anda dapat mengakses ruang kerja saya.

Kedengarannya bagus, terima kasih!

K. Jadi saya membiarkan contoh kode berjalan semalaman, dan tidak memiliki masalah dengan itu macet atau langsung merasa lamban. Saya melanjutkan pekerjaan hari ini, dan bahkan mengambil sedikit jeda dari menggunakannya saat melakukan hal-hal lain, dan itu mulai lamban lagi. Sepertinya mungkin masalahnya bukan karena menggunakannya secara aktif, tetapi juga terdengar seperti ada hal lain yang memicunya selama saya mengerjakannya.

Saya akan menjalankan profiler untuk mengawasinya, dan saya akan membuat masalah baru jika ada temuan lain yang berbeda dari yang dijelaskan di atas.

Saya belum memeriksa untuk melihat apakah Anda dapat memiliki akses ke ruang kerja saya, meskipun sayangnya saya tidak dapat membagikannya dengan Anda.

Saya mencoba menjalankan profiler kemarin ketika itu menjadi sangat lambat dan ketika saya mengambil snapshot heap, komputer memaksimalkan RAM yang tersedia, dan saya hampir tidak dapat melakukan apa pun sama sekali, bahkan tidak menutup paksa Kode, jadi saya harus memulai ulang komputer. Saya akan mencoba menjalankannya lebih cepat dari sebelumnya untuk menghindari hal itu terjadi lagi.

Ini sedikit di luar topik, tetapi Anda memposting tautan untuk insiders build, yang saya kunjungi. Saya ingin mengunduh versi windows (seperti yang saya gunakan di rumah), dan setiap kali saya mencoba untuk mendapatkan tautan itu, itu mengalihkan pertama ke halaman unduhan biasa, tetapi kemudian segera mengarahkan saya ke halaman utama tanpa memulai pengunduhan. Nyatanya, itu menimpa riwayat halaman unduhan yang saya buka, jadi saya bahkan tidak bisa kembali ke riwayat untuk membukanya. Apakah ada cara lain agar saya bisa membuat orang dalam membangun?

@bayu_joo

Ini sedikit di luar topik, tetapi Anda memposting tautan untuk insiders build, yang saya kunjungi. Saya ingin mengunduh versi windows (seperti yang saya gunakan di rumah), dan setiap kali saya mencoba untuk mendapatkan tautan itu, itu mengalihkan pertama ke halaman unduhan biasa, tetapi kemudian segera mengarahkan saya ke halaman utama tanpa memulai pengunduhan.

Maaf tentang ini, tetapi beberapa pengguna melaporkan beberapa masalah aneh di insiders build dan kami menghapusnya untuk sementara hingga kami memahami masalah ini.

@egamma Saya bertanya-tanya apakah itu mungkin tidak dapat diakses karena itu. Aku akan mengawasi kapan itu berhasil.

@Tyriar Saya mencoba ruang kerja chromium semalaman di Linux, Windows dan Mac dan tidak dapat mereproduksi crash. Bisakah Anda mencobanya lagi?

Saya tidak yakin apakah ini terkait tetapi saya perhatikan bahwa VS Code cenderung macet selama hari kerja saya jika saya membukanya dan melupakannya untuk sementara waktu. Saya bekerja selama 11 jam dan saya biasanya membuka kode hal pertama di pagi hari. Pada suatu saat di siang hari komputer saya akan melambat dan mulai macet sampai macet atau saya mematikannya secara paksa.

Kalau-kalau itu bisa membantu ...

Proyek utama yang saya buka di VS Code adalah versi keranjang belanja yang relatif tidak dimodifikasi yang disebut BVCart (versi 2004.7). Saya memiliki sekitar 25-30 file kerja saat ini dan bahkan hanya membuka VS Code dan tidak menyentuhnya sepanjang hari menyebabkan crash.

Proyek ini terdiri dari 1836 file dan 130 folder dengan total sekitar 35MB dan terdapat dalam repositori git kecil.

@ZombieProtectionAgency apakah mungkin untuk membagikan ruang kerja ini dengan saya?

@bpasero Maaf, saya pasti tidak bisa membagikannya :( Saya belum melihat, tetapi Anda mungkin dapat menemukannya secara online di suatu tempat. Ini hanyalah keranjang belanja ASP VB.Net model lama yang datar. Sebagian besar file tersebut adalah .vb dengan aspx, ascx, dan beberapa file css.

Saya mengalami kesalahan yang sama persis. VS Code hanya mogok setiap beberapa menit. Saya menggunakannya dengan elm. Itu tidak bentrok saat dibiarkan. Ini bentrok dalam beberapa menit setelah saya mulai mengakhiri file. Sudah seperti ini selama tiga hari terakhir membuat VS Code tidak dapat digunakan. Bagaimana cara memeriksa apa yang sedang terjadi? Saya menggunakan versi 0.10.10.

Pemikiran lain yang saya miliki: Kami memiliki layanan yang dapat menerima keluaran dari berbagai titik akhir (git, tugas, ekstensi) dan ini adalah sesuatu yang dapat terjadi di latar belakang dan bertambah. Kami melakukan beberapa perbaikan di area ini untuk GA yang tidak ada di rilis sebelumnya.

Jika ada orang yang mengalami crash dalam semalam hanya dapat memeriksa sebentar apakah ada output yang dicatat dari latar belakang? Anda dapat melihatnya dari View> Toggle Output dan kemudian beralih melalui saluran dari dropdown.

@bpasero
Dalam keluaran 'Tasks' saya hanya melihat keluaran yang saya harapkan dari tugas kompilasi saya sendiri.
Dalam keluaran 'Git' saya melihat beberapa pengambilan git yang adil, diselingi dengan beberapa pertunjukan git. Saya tidak yakin seberapa sering karena tidak ada cap waktu. Tidak ada keluaran lain.

Kami melakukan pengambilan otomatis sesekali tetapi output utama yang Anda lihat mungkin dari pekerjaan yang Anda lakukan dalam VS Code. Akan menarik jika output bertambah ketika VS Code ada di latar belakang. Apakah tugas berjalan terus-menerus atau hanya jika Anda secara eksplisit menjalankan tugas kompilasi?

Tugasnya hanya ketika saya ctrl + shift + B dan berakhir tidak lama kemudian. Saya mengalami crash namun ketika saya tidak menjalankan tugas.

Saya mendapatkan dua pertunjukan git yang identik ketika saya beralih antar file dan ya pengambilan git terjadi secara otomatis setiap beberapa menit.

Perhatikan bahwa saya tidak melakukan pembayaran apa pun dll dalam VSCode, saya menggunakan SourceTree untuk semua tugas terkait git.

@bpasero Saya akan membiarkan jendela keluaran hari ini dan melihat apakah ada yang muncul. Saat ini telah terbuka selama satu jam atau lebih penggunaan normal dan saya tidak melihat apa pun di tugas atau tampilan git. Kami tidak menggunakan git, jadi saya tidak berharap melihat apa pun di dalamnya sebagai aturan umum.

Insiders build terbaru kami sudah keluar dan saya akan sangat menghargai jika orang-orang dapat mencobanya pada masalah ini: https://code.visualstudio.com/insiders

@bpasero Saya masih memiliki insiders build sebelumnya, dapatkah saya menjalankannya dan melakukan "check for updates", atau apakah saya harus mengupdate build dari link yang Anda berikan?

Akan mencoba dan kembali kepada Anda. Sejujurnya saya melihat lebih sedikit dari VSCode
crash saat ini. Setidaknya itu tidak macet setiap hari.

Saya bisa membuatnya crash dengan membuka file besar dengan jutaan baris plus
meminimalkan js dan menggulir ke atas dan ke bawah berulang kali. Tapi saya tahu apa itu
mendorong batas editor.

Apa pun yang telah Anda tambahkan karena saus ajaib berhasil untuk saya.

Pada hari Rabu, 16 Maret 2016 jam 12.29, Benjamin Pasero [email protected]
menulis:

Insiders terbaru kami telah dibuat dan saya akan menghargai jika orang bisa
cobalah tentang masalah ini: https://code.visualstudio.com/insiders

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -197503185

@gwynjudd Anda seharusnya dapat memperbarui jika logo VS Code muncul sebagai logo hijau:

@nojvek ya itu mendorong batas sedikit. untuk rilis Maret kami melakukan pengujian memori eksplisit untuk menemukan area yang dapat kami tingkatkan. build orang dalam mencakup beberapa perbaikan tersebut (tidak semua, kami melakukan beberapa perubahan kemarin dan hari ini yang belum masuk). jadi hanya ingin tahu apakah ada bedanya bagi orang yang melihat ini ...

@bpasero terima kasih saya telah melakukan itu dan saya akan memberi tahu Anda bagaimana kelanjutannya

@bpasero masih mengalami kecelakaan yang sama dalam semalam dengan pembuatan orang dalam pawai. Apakah Anda ingin saya mencoba mendapatkan heap dump dari alat pengembang selama penggunaan normal? Saya dapat mencoba mengawasi penggunaan memori untuk kode dan mengambil dump jika tampaknya akan naik

Ya, terima kasih.

Ini adalah cuplikan heap segera setelah meluncurkan kode (penggunaan memori sekitar 100MB pada saat itu)

Heap-20160318T115937.zip

Saya akan mencoba lagi dalam satu atau dua jam. Bagian yang sulit tampaknya adalah mendapatkan itu pada titik di mana memori telah meningkat agak, tetapi tidak terlalu banyak sehingga mengambil snapshot memicunya untuk crash keluar dari memori.

Saya melihat hasil yang sama ketika mencoba mengambil cuplikan heap (kehabisan memori), dan itu tidak menyenangkan.

Saya merasa masih ada beberapa masalah memori di insiders build terbaru (untuk mac). Saya akan melihat apakah saya bisa mendapatkan snapshot heap lain tanpa mengorbankan komputer saya.

@bpasero maaf saya belum berhasil mendapatkan snapshot heap. Entah memorinya sangat rendah seperti yang saya tangkap sebelumnya, atau melonjak hingga sekitar 500MB atau lebih dan mengambil snapshot memicu crash.

Saya harus me-restart vscode 1-2 kali sehari karena penggunaan memori naik lebih dari 1GB dan semuanya mulai terasa lamban. Ini menggunakan jumlah memori yang akan dimiliki IDE sepenuhnya, jadi pasti ada kebocoran yang terjadi.

@ vincent-ly dapatkah Anda membagikan lebih banyak detail tentang ruang kerja yang Anda gunakan untuk melihat ini?

@bpasero Ada sekitar 30-40 file js / scss / html yang menggunakan beberapa komponen bower dengan gulp (tanpa runner tugas vscode). Saya bekerja dengan 2 panel editor dan sering menggunakan pencarian file, cukup standar. Penggunaan memori di bawah 100mb saat memulai, tetapi bertambah seiring waktu, bahkan saat diminimalkan.

Apakah Intellisense berperan? Saya telah menginstal definisi tipe Angular dan jQuery.

Anda dapat mencoba insider build kami tempat kami bekerja pada tekanan memori yang dikurangi untuk melihat apakah itu membuatnya lebih baik: http://code.visualstudio.com/download?insiders=true

Apakah Anda sudah memasang ekstensi?

@bpasero Hanya cuplikan sudut
https://marketplace.visualstudio.com/items?itemName=johnpapa.Angular1

Saya akan mencoba orang dalam membangun dan melaporkan kembali, terima kasih!

+1

Melihat masalah yang sama di VSCode untuk Windows 0.10.11 . Ini biasanya macet setiap malam secara konsisten saat tidak digunakan. Mengingat langkah-langkah untuk mengumpulkan info, saya akan dengan senang hati membantu.

Berjalan pada repo git TypeScript dengan 28.438 File, 4.812 Folder. Memiliki pengamat gulp juga, dengan banyak def TypeSript.

Saya telah memasang ekstensi berikut:

• PowerShell
• C #
• Kit Tema Material

@alanwright dapatkah Anda mencoba jika masih mereproduksi dengan insider build terbaru kami (http://code.visualstudio.com/Download#insiders). Jika ya, dapatkah Anda berbagi ruang kerja dengan saya?

@bpasero Direproduksi sepanjang malam dengan insider build. Saya mencoba di pendaftaran pribadi kami yang lebih besar dan pendaftaran sumber terbuka kami, dan hanya pendaftaran pribadi yang lebih besar yang tampaknya menyebabkan masalah, yang sayangnya tidak dapat saya bagikan (ini adalah internal Microsoft jadi mungkin kami dapat memberi Anda akses? Nama alias saya adalah alanwri)

Apakah ada yang dapat saya lakukan di mesin saya untuk menangkap log dan berbagi dengan Anda?

Silakan berbagi dengan saya di alias saya benjpa, terima kasih! Juga akan menghargai beberapa detail bagaimana Anda menggunakan VS Code pada ruang kerja itu untuk menyebabkan peningkatan memori.

Saya juga mengalami crash sepanjang malam dan siang hari.

Tampaknya tidak hanya terkait dengan ruang kerja, file 3-20 ruang kerja yang sangat kecil atau ruang kerja yang sangat besar, terutama terlihat saat membuka banyak jendela.

Repos saya telah menggunakan yang jatuh.
1500+ file asp, js, .inc (asp)
70 + file asp.net core, js, cshtml
Repo ini (https://github.com/gogits/gogs)

@ eByte23 apakah Anda menjalankan dengan atau tanpa ekstensi? di platform apa kamu? apakah Anda mencoba dengan rilis orang dalam?

@bpasero Win10 & OSX dengan C # sebagai ekstensi.
Telah mencoba orang dalam tetapi belum mencatat jika macet karena ada bug tab sehingga saya berhenti menggunakannya tetapi saya dapat membiarkannya berjalan sepanjang malam untuk mencoba repro.

@ eByte ya silahkan. bug tabbing apa?

@bpasero tampaknya berada di dua rilis terakhir dari orang dalam dengan tampilan spasi aktif dan mengonversi tab ke ruang putih dengan file dengan tab yang ada tampaknya tetap tabbing dan tidak menulis spasi bahkan pada baris baru.

Saya tidak memiliki kesempatan untuk melakukan pengujian penuh tetapi saya akan melakukannya sekarang.

@ eByte23 Saya sarankan Anda melaporkan hal seperti itu sebagai masalah terpisah jika menurut Anda itu adalah salah satunya. kami memperkenalkan pengaturan baru editor.detectIndentation yang defaultnya adalah true . Mungkin Anda dapat mencoba menyetelnya ke false .

@bpasero Saya buruk Anda benar-benar benar mengatur pengaturan itu menjadi salah memperbaiki masalah saya.
Saya menguji Insider Yesterday semalam dan itu juga macet.

@bpasero sepertinya kalian mungkin mendapatkan yang terbaik dari yang satu ini, dari sudut pandang saya tampaknya menjadi lebih baik secara umum dengan build terbaru

Kami menginvestasikan cukup banyak dalam perbaikan kebocoran memori untuk rilis 1.0, jadi saya berharap situasinya akan lebih baik dengan 1.0. Tapi masih ada kasus dimana itu terjadi.

Saya mungkin memiliki teori baru karena saya baru-baru ini menemukan bahwa aplikasi Elektron (kerangka kerja UI kami) menjadi terhambat segera setelah jendela mereka kehilangan fokus atau berpindah ke latar belakang. Saya ingin tahu apakah pelambatan ini dapat berdampak pada konsumsi memori.

Setiap kali saya menguji untuk mereproduksi, saya membiarkan jendela VS Code terbuka dengan fokus keyboard, jadi mungkin satu perbedaan adalah membiarkannya berjalan di latar belakang.

Ada cara untuk menonaktifkan pelambatan latar belakang sehingga saya bisa membuat build dengan bendera untuk mengaktifkannya.

Kalau tidak, akan menarik juga untuk mendengar dari orang-orang jika kecelakaan setelah meminimalkan adalah skenario yang khas.

Semua crash saya terjadi ketika VSCode tidak memiliki fokus. Umumnya itu terjadi setelah membiarkannya di latar belakang sepanjang hari saat menjelajah internet atau menggunakan Visual Studio

Saya mendukung ini. Saya baru saja mengalami kecelakaan. Itu dengan VS di
latar belakang ketika saya fokus pada luhur hampir sepanjang hari.

Pada hari Sabtu, 16 Apr 2016 jam 11:44, Toni [email protected] menulis:

Semua crash saya terjadi ketika VSCode tidak memiliki fokus. Umumnya mereka
terjadi setelah membiarkannya di latar belakang sepanjang hari saat menjelajah
internet atau menggunakan Visual Studio

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -210872544

Mengalami crash saat menggunakan insider build belum lama ini. Telah berlangsung selama 2 hari. Tiba-tiba menjadi lambat. Memilih teks dengan mouse berhenti bekerja. Shift-Kanan bekerja tetapi sangat lambat. Aplikasi macet beberapa menit setelah kehilangan fokus.

Ini adalah crash pertama saya untuk insider build tetapi untuk build normal, saya meningkatkan ke v1.0 dan masih macet setiap beberapa menit atau lebih setelah membukanya sehingga tidak dapat digunakan. Saya bahkan tidak perlu melakukan sesuatu yang istimewa. Buka, edit file (kebanyakan file .elm) atau biarkan saja dan macet. Bahkan tidak menunggu untuk kehilangan fokus dulu.

1.0 crash hampir setiap malam.
Windows 10 Ent.
Plugin: Pemeriksa Ejaan dan Tata Bahasa, ESLint

Oke, rilis orang dalam keluar dengan perubahan saya disertakan. Akan dengan senang hati seseorang mencobanya: http://code.visualstudio.com/Download#insiders

Siapapun :)?

Menggunakannya sekarang. Belum mengalami kecelakaan sejak kemarin.

@bpasero Saya akan memutakhirkan sekarang dan membiarkannya berjalan semalaman dan lihat bagaimana kami melanjutkan! Bersulang :)

@bpasero Saya menginstalnya hari Jumat tetapi kemudian pergi untuk akhir pekan yang panjang, juga PC kerja saya di-boot ulang jadi saya tidak punya apa-apa untuk dilaporkan.

@bpasero mengalami crash kemarin. Tetap terjaga selama 3 hari sebelum mogok.

@bpasero Saya masih melihat

Saya juga.
Windows 8

@bpasero Insider 1.1.0 lebih baik, membutuhkan waktu hampir seminggu sebelum crash.

Saya akan mengambil 1.1.0 sekarang dan melihat bagaimana kelanjutannya

Saya tidak dapat mengambil snapshot heap tanpa crash saat penggunaan memori melebihi 150mb.

Setiap pagi, saya membuka kunci komputer saya untuk menemukan VS Code telah rusak dalam semalam.

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

Saya biasanya membiarkan file terbuka. Saya menjalankan dengan ekstensi. Apakah ada pengaturan yang dapat saya gunakan untuk membantu mengumpulkan lebih banyak informasi diagnostik?

Rilis orang dalam baru kami sudah keluar (http://code.visualstudio.com/Download#insiders) dan menyertakan pekerjaan kami untuk tab / stack. Ini datang dengan pembuangan sumber daya yang lebih agresif karena segera setelah Anda menutup editor, kami menyingkirkan sumber daya yang mendasarinya.

Penasaran apakah orang bisa melakukan selfhost ini untuk sementara waktu dan melaporkan kembali jika keadaan membaik.

Catatan: orang dalam mulai sekarang diperbarui setiap malam (lihat http://code.visualstudio.com/blogs/2016/05/23/evolution-of-insiders)

@bpasero Saya telah memperbarui semua perangkat saya hari ini, lihat bagaimana kita pergi beberapa hari ke depan

Ya, saya terutama pindah ke orang dalam karena terminal. Oh betapa aku
suka. Menurut saya editornya jauh lebih tajam dan ringan. Kerja bagus.

Apakah ada cara untuk mengganti "kode". Di baris perintah untuk menunjuk
orang dalam?

Pada hari Rabu, 8 Juni 2016, Elijah Bate [email protected] menulis:

@bpasero https://github.com/bpasero Saya telah memperbarui semua perangkat saya hari ini,
lihat bagaimana kita pergi beberapa hari ke depan

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -224539214,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe/AA-JVM4KoGeXoc2SU5VeEYnxkZyPVWYMks5qJo13gaJpZM4Gnvn5
.

Masih terjadi di 1.2.0 untuk saya. Terjadi setiap malam - berjalan di Windows 7 Enterprise SP1. Saya punya pertanyaan yang sama dengan @garthk

Saya biasanya membiarkan file terbuka. Saya menjalankan dengan ekstensi. Apakah ada pengaturan yang dapat saya gunakan untuk membantu mengumpulkan lebih banyak informasi diagnostik?

@n northerncodemky Saya mengacu pada rilis orang dalam 1.3.0 di mana tab / tumpukan kami bekerja disertakan (http://code.visualstudio.com/Download#insiders). Saya tidak mengharapkan banyak perubahan di 1.2.0.

@bpasero Aah ok - tidak

@bpero terlihat bagus sejauh ini !!

Saya memiliki VSCode Insiders yang dibangun selama akhir pekan. Datang pada Senin pagi dan melihat kecelakaan.

Saya ingin tahu apakah ada data telemetri crash / dump yang secara otomatis dikirim saat VSCode rusak? Semacam laporan watson seperti.

Saya mendapat mesin baru minggu lalu. Ketika saya mengaturnya, saya hanya meletakkan build rilis (bukan orang dalam) - saya belum memperhatikannya crash sejak saat itu.

@bpasero Saya belum pernah melihat crash sejak 1.3, menjalankan windows 10 insider build> = 14367

@bpasero dengan tab diaktifkan, buka ac # project dan vscode mengalami error error beberapa menit setelah update terbaru untuk insider commit hash: 5474147bb83618975409dad7d8aa96151d7d1ea1.
CATATAN: Saya sebelumnya tidak mengaktifkan tab sampai sekarang

@ eByte23 Dapatkah Anda memverifikasi ini terkait dengan mengaktifkan tab atau tidak dengan mencoba tanpa tab?

@bpasero masih terjadi saat tab dinonaktifkan, tetapi tidak ada tempat di dekat tingkat keparahan dengan tab diaktifkan.

Namun sangat terlihat dan dapat direproduksi saat bekerja dengan gambar, mengklik di antara gambar besar dengan cepat di dalam dan v1.2.1

@ eByte23 Saya sarankan untuk membuka masalah baru dengan detail sebanyak yang Anda bisa berikan (misalnya apakah memori bertambah?).

Tentu bisa. Saya belum melakukan banyak penyelidikan di sekitarnya, tetapi saya akan mendapatkan beberapa detail mendalam untuk Anda nanti.

VSCode 1.3.1 crash sekitar dua kali sehari untuk saya, sekali dalam semalam (selalu) dan terkadang secara acak di siang hari. Itu baru saja macet sekarang ketika saya membukanya di latar belakang, tidak menggunakannya selama sekitar 2 jam. Juga setelah membuka vscode lagi itu kehilangan ruang kerja saya, dan saya harus membuka kembali folder proyek yang telah dibuka sebelum crash. Tab dan pemisahan dipertahankan setelah folder dibuka kembali.

saya dibiarkan terbuka di latar belakang untuk sementara waktu dengan perubahan yang belum disimpan, kembali, mulai mengetik dan vscode berhenti selama beberapa detik kemudian macet. itu kehilangan pekerjaan saya.

Saya harap Anda bisa memahami rasa frustrasi saya. Ini tidak dapat diterima untuk editor. Juga sesi yang dipulihkannya bahkan tidak membuka tab yang benar, atau tempat saya di setiap tab.

@DelvarWorld dapatkah Anda membagikan lebih banyak detail tentang lingkungan kerja Anda? dapatkah Anda mencoba menjalankan dengan ekstensi yang dinonaktifkan untuk melihat apakah itu membantu?

Saya memiliki masalah yang sama di Linux Mint 17 Qiana (tidak dapat mengingat versi ubuntu itu!). Itu hanya membeku bagi saya setelah ~ 2 jam tidak aktif. Saya akan ingat untuk memeriksa penggunaan memori / CPU saat itu terjadi, meskipun saya tidak pernah melihat perlambatan umum di aplikasi lain, dll ketika ini terjadi.

Info VSCode:

Versi 1.4.0.0
Komit 6276dcb0ae497766056b4c09ea75be1d76a8b679
Tanggal 2016-08-04T16: 49: 32.489Z
Kulit 0.37.6
Perender 49.0.2623.75
Node 5.10.0

Masalah ini telah hilang untuk saya (pada 1.5.3, Windows 7) - mengingat komentar terakhir adalah 2 bulan yang lalu, apakah ini mungkin diselesaikan?

Saya belum pernah melihat ini terjadi pada saya selama berabad-abad. Saya telah menggunakan rilis saat ini selama berbulan-bulan. Sepertinya bagus

Sama. Sepertinya tidak kelebihan beban sama sekali.

Oke, kita harus melanjutkan dalam masalah individu dan menghindari bug monster seperti ini yang sulit dilacak. Jika ada yang masih melihat masalah ini, ajukan masalah baru dengan detail lebih lanjut. HARAP hindari pembajakan masalah yang ada 👍

Saya juga ingat pernah melihat ini sebelumnya dan sudah lama tidak melihatnya, jadi, itulah verifikasi saya.