Vscode: Crash when running overnight

This seems to happen consistently every night I leave the computer running. It looks like it's unresponsive due to the CPU being maxed out. Maybe some infinite loop is somewhere, perhaps to do with file or git repo polling?

I wonder if the OS decides to put VSCode (Electron actually) into a state where it is causing this crash. I have pinged Electron if they have a clue.

Never happened on Atom fyi, at least on 1.19.x (from memory) and 1.2.4.

I have a similar issue, since the November update (0.10.2/0.10.3?). Just about every day I'd log in to find my VSCode windows left overnight have all crashed (with the standard uninformative/apologetic crash error, "Visual Studio Code has crashed").

Today, after the 0.10.5 update, I had my first crash while I was there - unfortunately not while I was actively using it.

Running VSCode on Windows 7 (64-bit), primarily using it as a JS editor on a very large project - nearly a million lines total (including libs I need to search, so are not excluded). No performance issues in normal use and I didn't notice any excessive resource usage leading up to today's crash.

I'd be happy to provide more detailed error logs/info if someone can point me to them.

I'm getting the same basic issue as @Elusive138, when I leave code running overnight (every night), in the morning without fail I get "Visual Studio Code has crashed".

Still repros for me on vscode 0.10.5, Ubuntu 12.04

I tried to reproduce on Windows 10, Mac OS 10.11 and Ubuntu 15 without luck. I am suspecting an out of memory issue but for none of the above the memory was increasing much.

Can someone try to reproduce this with the following conditions:

• does it reproduce when opening just an empty instance of code (File | Close Folder)
• does it reproduce when opening a workspace but not opening any file in the editor

Ubuntu 12.04, vscode 0.10.5 could not reproduce leaving it over the weekend with an empty instance.

It may well be a subtle memory leak, made apparent by the relatively high memory utilisation on this system.

I left the computer at about 5:30 PM, with system memory commit slowly creeping up - it was 15,402 MB at 7:00 PM. At 3:09 AM was the closest approach to the system commit limit (17,682 MB), and commit usage dropped from 16,218 MB to 15,217 MB. I suspect this might be where VSCode crashed. Commit usage was stable around there until logging stopped around 6 AM (out of disk space - those performance counters are big!).

Unfortunately I did not include all the VSCode processes so I do not have process-specific logging. I will try that tonight.

Would be very useful if I could get the time of crash. Does VSCode leave logs anywhere?

Unfortunately I did not include all the VSCode processes so I do not have process-specific logging. I will try that tonight.

That would be super useful, thanks!

Currently vscode does not log to disk.

@Elusive138 can you share the workspace you let vscode running on?

@bpasero Unfortunately not. It is based on Ext JS, though, and that's where the majority of the (library) code is. I'll try a clean Ext JS workspace after this other testing is done, and see if it repros there.

@Elusive138 yes would be good to have a sample to reproduce on our end.

One of the code.exe processes (code#3 in the log, attached) seems to be leaking. Commit started at about 200 MB at 5:30 PM, and reached 460 MB by 9:00 AM the next day, with a constant increase:

Handle count does not go up.

vscode_memleak.zip

There was no crash this time, perhaps because I did not have as many other memory-intensive programs running. Might be able to test this in a VM with a low commit limit later.

This log was created overnight with 3 large workspaces open in different windows. I'll try to narrow it down to a workspace I'm able to share.

@Elusive138 it would be helpful to understand the details of the process that leaks. Can you find its PID and then print its full meta data using ps aux | grep <pid>?

Ah, maybe this is on Windows, not sure :)?

@bpasero The command line is:

"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

Other details:

The process tree:

This is after another full day of use. As you can see, the process' memory usage appears to have risen linearly in that time (same workspace).

Ah... this isn't even the really bad one. The second-level code.exe below it was worse.

4772 was the process that leaked overnight. The other one seems to have risen up due to my use during the day... I think.

@Elusive138 this looks like you have multiple windows open with Code is that true?

@bpasero Yes, the test last night had three windows open with different workspaces. I'll be trying it tonight with just one, on a clean Ext JS workspace as mentioned above.

Sounds good!

Unfortunately, no repro... this is odd. What could be causing a leak within that specific project?

Speaking of which, this might be different from @Tyriar's initial issue. His was unresponsive, mine and gwynjudd are crashes with the error dialog..? In which case maybe we should make a new issue...

@Elusive138 odd. does it reproduce if you just open that workspace without opening any JS file?

Also, maybe we can start profiling this using the chrome developer tools where you can do heap snap shots. For that, just do a snapshot before and after some time to see where those memory goes.

@bpasero Oh, I completely forgot about those devtools. I'll try that one tonight.

@bpasero Heap snapshots of Main.js, workerMain.js and workerMain.js (2) don't really change. By maybe 5 MB at most.

Adding more on my situation, I tried to run it with a folder open (the one that crashed) but no working files and it didn't happen overnight. So it only happens when a folder is open and there are working files active.

@Elusive138 we spawn other processes that can cause the memory pressure and they would not show up in the heap profile. However from one of your previous posts it seems you had identified the high memory coming from the renderer process and that one should show up under the heap snap shot. Are you sure you saw the high memory for the renderer process and not for its children? because the renderer is the parent of other processes that it spawns, e.g. a process for file watching.

@Tyriar can you be more specific what you mean by that. is it that you did not open any file in the editor or that you literally had the working files section empty?

The reason I am asking about opening a file or not is that for example the JS language service only starts once you open a JS file. The same is true for any other language service. So if this issue reproduces without opening a file in the editor it is likely that the memory leak is not in any language service but somewhere else.

Another thing worthwhile to try: Run without any extension to see if maybe an extension is leaking. You can run with --disable-extensions to do so.

@bpasero I'm sure the command line provided above was for 4772, the highlighted (leaky) one in the screenshot. It does say --type=renderer.

I'll leave it running over the weekend again and see what happens. I don't think I've done a clean test with no JS files open yet.

@bpasero I believe I had no file open (on the right), only working files above the tree. If I remember when I finish work I'll try check with a file open and note the language.

I don't know for sure but it probably wasn't a JavaScript file when mine crashed, more likely C++, Java or no language. I'll be sure to check.

@Tyriar if it reproduces only by having something under working files and with all editors closed (right from the startup - that is important), we might be on to something.

@bpasero I might try open a bunch of instances under varying conditions before leaving work on Friday and see if I can get all of my experiments out of the way in one night. Unless you have reason to believe one instance of vscode hanging would break all the others?

@Tyriar yes totally, if you have more than one window open it all adds up to the total memory being used and they all would crash. This is because when you open multiple windows, they still share all one parent process and one memory limit of something like 1-1.5 GB. To really understand where the leak is coming from it would be best to measure 1 window isolated under these conditions:

• no extension enabled via --disable-extensions (an extension that consumes lots of memory or leaks would also cause a crash)
• no file opened on startup (just closing a file after startup is already too late)
• no working file under working files

btw the only thing for working files that might have an impact is that for each working file that is not inside the workspace we install a file watcher to watch for changes. maybe this causes the leak, would be surprising though. also, we do not install a watcher if the file is inside the workspace that is opened, only for files outside.

@bpasero No leaks when there are no open files (?). I'll try the clean workspace tonight after making sure to open a few.

I tried over the weekend with the following setup:

1. Launch with Code --disable-extensions
2. Open a ~1300 line JavaScript file

Memory and CPU were approximately the same Friday night and Monday morning.

@Tyriar was this just opening an empty workspace with one file or opening a folder first and then a file from it?

@bpasero Opening empty workspace, I didn't open a folder and no folder was open when I launched

Ok, good to know. So this seems to be related to having a (potentially large) folder open. Still to find out if just opening this folder is enough or having a file open only triggers it.

@bpasero I had a large folder open with no files open over the weekend, with no noticeable increase in memory usage. I'll have the results of a large-folder-and-file-open test with hopefully a reproducible/shareable workspace in about 7 hours.

@bpasero the folder in which I experienced crashs before would have been 13000-14000 files strong, this includes the git repo which was around 2000 by itself.

I guess I'll double check that the crash still happens in the latest version next as it's been a while since I've seen it (due to testing).

And I assume it is a JS workspace?

@bpasero py, cpp, js, html, css

Ok, this seems to reproduce the slowly climbing memory usage, if on a smaller scale: VSCodeTest.zip. I had /ext/build/ext-all-debug.js opened.

(Yes, it's a 7z inside a zip... GitHub won't let me upload a 7z or xz directly, and zip and gzip are too big)

@Elusive138 how much does it increase for you in avg? I had the workspace with some JS files open for 2 hours now without any increase in memory.

@bpasero Sorry, I'm having trouble reproducing again. I think I had a stray git repo in an earlier attempt, that wasn't included in the archive above. I'll let you know when I have more concrete results.

Would be really helpful if it were possible to open multiple independent instances... being limited to one test a night is quite slow. Do you happen to carry across the Chromium flags for separate profiles?

It is possible to build multiple Code versions that can run in parallel, though we have not documented it. If you change the values in https://github.com/Microsoft/vscode/blob/master/product.json so that they are different and then build from the command line, you can start multiple distinct instances. The identifiers that have to be unique are:

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

Windows 8.1. In Code, opened a folder for a git repository containing 39,000 files in the morning.
Did very little with it, a few small edits in a couple of files.
By the end of the day the Commit Size reported by Task Manager was 672,164K.
It grew steadily all day, even when I wasn't in the program.

@gushie any chance this repo can be shared with me? also, what was the initial memory reported?

@bpasero I'm sorry, I'm not allowed to share the repo itself but if there are any details about it that might help, excluding the file contents themselves, let me know. The process initially starts at around 110MB, quickly grows to about 130MB before settling back to 90MB. It will then grow steadily from this point forward. (There are 5 other code.exe processes which vary from 4MB to 30MB but these don't noticably grow. There is only the one Code Window)

I don't know what the final Commit Size was from yesterday as the process had crashed when I returned to it today.

@gushie I've been using Performance Monitor on the code.exe processes to monitor the "Private Size".

Pretty annoying that we can't share the workspaces we have issues with! I wonder if anyone's encountered this with something open-source. Looking for similarities: was your repo ever used with git-svn?

@bpasero Thanks, if the process I left hasn't repro'd when I get back in on Monday, I might try building a couple additional copies. Would need to figure out how to keep track of which one's which, though.. that might be a problem.

@Elusive138 We use Atlassian tools, so SourceTree connecting to a private Stash server

Ah, that's completely different from mine. Was a local Git repo (w/ Git Extensions) connecting to an SVN server. My current test is with a git repo based off the vscode one... hopefully that'll repro and I can share it.

@gushie does it reproduce if you just open the workspace without opening any file? try to first close all files and restart to get this setup. if that does not reproduce, does it reproduce if you open the workspace and open one JS file and let it like that?

@bpasero I had already left it open with just a single unedited working file last night, and checking this morning the memory usage does't appear to have changed much. I've now edited and done a build on the file, and will leave this to see what happens.

Note until I read through this issue, I hadn't ever cleared down the working files. (I hadn't really had a need to, I generally ignored this panel and switched files via the project file explorer underneath it, or with Ctrl+E).

Crashed again, this time it was after regular usage but it was left in this state:

• ~14000 file folder open
• 5 working files active (.cc, .java, .h, .py, .json)
• No file open in text editor

ps aux output:

❯ ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
...
daniimms  6086  0.0  0.5 970620 92180 pts/0    Sl   Jan11   0:36 /home/local/ANT/daniimms/VSCode-linux-x64/Code /home/local/ANT/daniimms/VSCode-linux-x64/resources/app/out/bootstrap --type=watcherService

As mentioned though this was after regular usage and not in safe mode so it _could_ have been due to an extension?

I left a single file with a small edit open, just that file in the working files. Otherwise untouched all day. Memory has not increased from it's initial value.

@Tyriar well the process you are showing is our file watching service and on Linux/Mac we use Chokidar for it (https://github.com/paulmillr/chokidar). This would indicate that they have a leak when watching files. Is there some build task constantly running and changing files?

@gushie was this without opening a folder?

@bpasero I did have the folder open. There is obviously some action that appears to kick off the memory leaks beyond the initial opening of a file within the folder. I'll continue to monitor and try and narrow it down.

@bpasero That was the only vscode-related process I could see in the output, it's possible that it wasn't visible in the output because it was already killed due to unresponsiveness? As shown that process was only using 0.5% of memory and 0% of CPU. I think out of my recent discoveries the issue I'm experiencing probably isn't due to a JS service.

Btw even if we do not find the reason for this until end of month, I pushed a change so that the crash dialog you get by default selects an action to reopen the window so that you can continue to work where you left. This is also good for the case where you have multiple windows open and only one of them crashes.

(one thing missing and for the future is to be able to periodically flush UI state to disk so that reopening also restores your previous work environment)

@bpasero :+1: that would be helpful.

VS has been crashing every morning for about a month now. I have come to the end of my patience.

I hope this is being treated as a PRI 0 bug because any sane editor should not crash this often.

Please let me know how I can get a trace out about why this is happening. I have seen this happen on other machines as well.

@nojvek are you able to share with me the workspace where this happens?

I'm not sure what you mean by share workspace. It's a typescript/HTML/CSS project with a bit of c++. Around ~1500 files and 80,000 lines of code.

Is there a way in VS to show crashdumps?

@nojvek I would like to have a workspace that I can run Code with to reproduce this issue. We suspect it is related to a memory leak somewhere, it is just not clear where. If you can send me a zip of the workspace or maybe the git URL if it is open source.

Benjamin,

Its internal Microsoft source code and I don't think I can give it to you.

If there is some memory monitoring tool I can add let me know.

Would it work if i take memory snapshots with the chrome debugger embedded
in vscode every couple of hours to see what is going on?

On Saturday, January 23, 2016, Benjamin Pasero [email protected]
wrote:

@nojvek https://github.com/nojvek I would like to have a workspace that
I can run Code with to reproduce this issue. We suspect it is related to a
memory leak somewhere, it is just not clear where. If you can send me a zip
of the workspace or maybe the git URL if it is open source.

—
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment-174192367.

Yes memory snapshots will help if and only if this leak is inside the main side of VS Code. However, it seems that at least in one case the leak was in one of the processes we spawn (the file watcher). Maybe you could identify using process explorer, which process is constantly increasing in terms of memory consumption.

If it helps to provide me with the source code: I work for Microsoft ;)

I'll have a word with my manager. This is in Windows repo so I'll have to
be a bit careful.

From the thread it seems the chokidar is used for the file watcher. A while
back I played with the source code. It was a bit of spaghetti.

I'll see if I can load chokidar on its own simple node app and see if it's
the culprit.

Btw any specific reasons why vs needs to use chokidar? There are other
cross platform file watchers right?

On Sunday, January 24, 2016, Benjamin Pasero [email protected]
wrote:

Yes memory snapshots will help if and only if this leak is inside the main
side of VS Code. However, it seems that at least in one case the leak was
in one of the processes we spawn (the file watcher). Maybe you could
identify using process explorer, which process is constantly increasing in
terms of memory consumption.

If it helps to provide me with the source code: I work for Microsoft ;)

—
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment-174269028.

Chokidar is used on Mac and Linux, if you are on Windows, we use a C# file watcher. I am happy to accept a PR with a working and performant cross file watcher solution :)

You know as of node 4.0 the fs.watch is stabilized on both windows and mac. See: https://github.com/Microsoft/TypeScript/issues/4643.

Typescript has a pretty solid cross platform file/directory watching logic. https://github.com/Microsoft/TypeScript/blob/931d162620c7e09377c12875834e1838c4cdd51b/src/compiler/sys.ts

I'll try to get a local build of VS code with a change and see if it still crashes. If it doesn't then I'll definitely send a PR.

I know it got much better by using the recursive watch call on the directory and thus avoiding having to attach a watch listener per folder, but I think the events still sometimes miss the file/folder name, at least in some cases. I feel more confi using C# here.

I managed to get a repro today. I just crashed before I was going to pull up Developer tools console to take a memory snapshot.

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

It seems the typescript server is taking about 200MB.
The renderer consumed about 800MB and then crashed.

When I get about 500MB of usage, I'll attempt to take a memory snapshot. The --renderer process is the webkit process right?

This was after two days since I last saw a crash. It seems using the tool for a 8 hour period editing lots of TS files adds up to usage faster.

Nice one, the renderer process is the main process for the editor. If you can do a memory snapshot there it would bring us further. Unfortunately the snapshot would not work for any other of the processes, but those seem to be ok'ish.

Is it normal for tscse (typescript server) to consume 200MB though?

On Tue, Jan 26, 2016 at 9:29 PM, Benjamin Pasero [email protected]
wrote:

Nice one, the renderer process is the main process for the editor. If you
can do a memory snapshot there it would bring us further. Unfortunately the
snapshot would not work for any other of the processes, but those seem to
be ok'ish.

—
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment-175408302.

Yeah, very easily.

Lol! I was in the process of taking heap snapshot and VS crashed.

I will try again and see if I have better luck tomorrow.

Is there a way to tell vscode to increase its memory limit so it doesn't crash while trying to take a heap snapshot ?

I think what happens is that taking the snapshot you caused an out of memory exception :-/. There is no way to change the memory limit, it is hardcoded in V8.

Maybe try to take the snapshot a bit earlier, before memory usage grows so high? Is it a gradual increase?

I've not been able to reproduce (no crashes, reasonable memory usage) for the last two weeks or so. Only difference I can think of is the PowerShell extension updating from 0.1.0 to 0.3.1 -- but I don't have any PS files in the workspace anyway, and it crashed with extensions disabled at the time.

I got a successful dump of around 300MB used by the --renderer process. It crashed 10 seconds after I took the dump.

It seems the bulk of the usage is in the DOM tree.

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

Hope this helps.

Hmmmm, I wonder if the profiler is telling the real truth here. I see all the tree elements and we might as well have a leak in the tree, but I would be surprised that this leak could cause an out of memory in such a short period of time.

I took a few more dumps.

It seems opening .min.js files causes a huge jump in memory. Even after closing the files the memory doesn't seem to go down. Between all the memory dumps it seems DOM is the dominator.

Also not sure why there were two renderer processes. May be one of them was the chrome devtools. But I got very close to 1 gig.

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

I took a screenshot of the two processes consuming ~500MB of ram.

Yes, one is devtools. It is expected that memory goes up when you open files. But I would like to understand how a VS Code that is running over night without activity increases in memory use until it crashes.

Well the repro is:
Start vs code.
Open one or two js/ts files on a large folder with lots of .tsconfig files.
Do some scrolling / editing.
Close all working files.
Put it in the even at 200c overnight.
Cake!

On Friday, January 29, 2016, Benjamin Pasero [email protected]
wrote:

Yes, one is devtools. It is expected that memory goes up when you open
files. But I would like to understand how a VS Code that is running over
night without activity increases in memory use until it crashes.

—
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment-177087988.

@nojvek Are the .tsconfigs necessary to repro? 'cause I've had crashes in the past without anything TS-related at all. Though I can't even repro those anymore...

Our project just happens to have them. Could be a red herring.

On Saturday, January 30, 2016, Bob [email protected] wrote:

@nojvek https://github.com/nojvek Are the .tsconfigs necessary to
repro? 'cause I've had crashes in the past without anything TS-related at
all. Though I can't even repro those anymore...

—
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment-177198518.

The only .* files we have in our folder are the .git folder and .gitignore

@nojvek are you using a custom typescript server with the project, or the out of the box TS we ship in 0.10.6? The one we ship in 0.10.6 is TypeScript 1.7.5

@bpasero @nojvek if it is a memory issue on the JS side. You can diff the heap snap shot on Chrome.

1. Take a snapshot.
2. Do the action that causes memory leak.
3. Force garbage collection. Otherwise the next heap snapshot will include the objects.
4. Take another snapshot.
5. Diff both snapshot.

Everything can be done with in Chrome Devtools above. The force of garbage collection is in the timeline tab, the garbage icon. And the diffing is done by just choosing it on the snapshot explorer on the filter menu.

Just report which objects is retained and possible retain paths(just below the heap table). And that is all the data needed to fix this issue.

Don't need to wait a whole day to collect data about a crash :wink:

The Dropbox link I sent had three heat snapshots taken half an hour apart.
I didn't do the force garbage collection. Will give that a trick.

On Sunday, January 31, 2016, Tingan Ho [email protected] wrote:

@bpasero https://github.com/bpasero @nojvek https://github.com/nojvek
if it is a memory issue on the JS side. You can diff the heap snap shot on
Chrome.

1. Take a snapshot.
2. Do the action that causes memory leak.
3. Force garbage collection. Otherwise the next heap snapshot will
   include the objects.
4. Take another snapshot.
5. Diff both snapshot.

Everything can be done with in Chrome Devtools above. The force of garbage
collection is in the timeline tab, the garbage icon. And the diffing is
done by just choosing it on the snapshot explorer on the filter menu.

Just report which objects is retained and possible retain paths(just below
the heap table). And that is all the data needed to fix this issue.

Don't need to wait a whole day to collect data about a crash [image:
:wink:]

—
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment-177462412.

I have same problem, VS Code is constantly crashing, not only over night, even after 30min of being idle.
I am using Windows 7, 64bit and latest version of VS Code. Regarding project itself it's huge js project, with node_modules and bower_components also loaded. Totally it has around 40K of files.

Steps to reproduce:
1) Open project folder(with lot of files), open several files so they could be in Working Files list.
2) Open task manager.
3) Put cursor to focus some file in VS Code
4) Watch as memory rises during time.

Can people with JS workspaces seeing this issue give our 0.10.7 insiders release a try (https://vscode-builds.azurewebsites.net/insider) with the option to use Salsa as JS language service: https://github.com/Microsoft/vscode-docs/blob/vnext/release-notes/latest.md#javascript---salsa-preview

Thanks!

+1 for this issue. Also appearing on Windows. Its totally annoying and I don't like it.

@bpasero I would like to try out the new build, but whenever I try to access the link you provided (https://vscode-builds.azurewebsites.net/insider), I get a very unhelpful error message page with the following text:

Sign In
Sorry, but we’re having trouble signing you in.
We received a bad request.

Additional technical information:
Correlation ID: e477dc1b-c193-4cf9-864b-1d3fdbba4f34
Timestamp: 2016-02-03 19:37:17Z
AADSTS50020: User account '[email protected]' from identity provider 'https://sts.windows.net/5a7d8144-6966-4b1e-8147-de672a307ea0/' does not exist in tenant 'Microsoft' and cannot access the application '9d5f02f6-ffd9-4e80-92d5-e42c85e09bc9' in that tenant. The account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Azure Active Directory user account.

I'm not able to download the build and try it out because of this issue.

Ah sorry, wrong link, please use https://code.visualstudio.com/insiders

@bpasero thanks I have the insiders build running with Salsa as the JS language service. I'll let you know how it goes over the next day or so

@bpasero, I tried insiders release and problem still exists, after one night in idle VS Code has crashed.

@milenkovic @gwynjudd you will also have to follow the steps to enable Salsa as outlined in https://github.com/Microsoft/vscode-docs/blob/vnext/release-notes/latest.md#javascript---salsa-preview

@bpasero, You were right, enabling Salsa fixed the problem. I left VS Code opened trough weekend and it still didn't crashed.

Good to hear that! Would be interesting if others could verify this too by trying.

@bpasero I had enabled salsa and left it running over the weekend. This morning it had crashed.

Installed typescript

$ npm install -g typescript@next
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

I've set settings.json to be

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

and the environment setting

$ setx VSCODE_TSJS 1

SUCCESS: Specified value was saved.

I don't still see salsa in the footer of VS code insider.

@nojvek I did basically what you did, and I do see Salsa in the footer, but only when a .js file is open and visible in the editor

@gwynjudd I assume you got the crash dialog and now with 0.10.8 out were able to reopen the window?

@bpasero yes I got the new crash dialog and could restart

Gwyn Judd

-------- Original message --------
From: Benjamin Pasero
Date:02/09/2016 19:13 (GMT+12:00)
To: Microsoft/vscode
Cc: Gwyn Judd
Subject: Re: [vscode] Crash when running overnight (#508)

@gwynjuddhttps://github.com/gwynjudd I assume you got the crash dialog and now with 0.10.8 out were able to reopen the window?

Reply to this email directly or view it on GitHubhttps://github.com/Microsoft/vscode/issues/508#issuecomment-181726111.

@gwynjudd is this a JS only workspace or other file types like PHP included?

@bpasero there are many file types including typescript, java script, css, less, aspx, cs

Gwyn Judd

-------- Original message --------
From: Benjamin Pasero
Date:02/09/2016 22:49 (GMT+12:00)
To: Microsoft/vscode
Cc: Gwyn Judd
Subject: Re: [vscode] Crash when running overnight (#508)

@gwynjuddhttps://github.com/gwynjudd is this a JS only workspace or other file types like PHP included?

Reply to this email directly or view it on GitHubhttps://github.com/Microsoft/vscode/issues/508#issuecomment-181786273.

With the new build it has crashed each morning when leaving it running overnight. I have only these extensions installed (in the new build, in the release build I had different extensions):

This morning when I came into work, it hadn't crashed. I didn't do anything different before I left work on friday.

Should try to reproduce with the Chromium workspace using Ubuntu as it seems @Tyriar had a setup like that when it happened.

Follow instructions here to get the code https://www.chromium.org/developers/how-tos/get-the-code

I've also noticed a lag in Code after some time using it, and eventual crashes. I've noticed that when it gets laggy, I am able to get it to run smoother if I press F1 and type in 'Reload Window'. That seems to clear up the issue for the moment and then I am able to work around it for now. I'm definitely interested to see this fixed.

From reading through this thread, I'm also guessing it's due to the render process, though I haven't done any testing with it, and it seems to happen regardless of the amount of working files in the list in the explorer panel, whether or not a file is open when Code is loaded, perhaps the sizes of the files currently being worked on, and I'm not sure if it has anything to do with the git diff checker or not, but I doubt it would be the culprit.

I'm also on Mac OS X El Capitan 10.11.3 and hadn't really seen the issue on Windows when I've used it at home, but I don't have a humongous working tree for any projects at home, only the massive folder I work from at work.

I would hope that both issues are related but I fear that they might not: Most people here see Code crashing when leaving it running without any user interaction, which seems very suspicious. Getting Code to eventually crash with an out of memory exception while using it for a long time might be caused by other memory leaks though. Ideally both issues are the same :)

Technically, it seems to slow and crash even if I am not using it, too, but I'm not sure if they also experience the same, in that case. Either way, the symptoms seem similar at the least. If it's found that my issue isn't related, I could create a separate issue instead.

@cwadrupldijjit if you see the issue with crashing overnight it would be helpful to get access to the workspace if possible.

I'll see what I can do. I usually put the mac to sleep at night, so nothing happens during that time. I'll try keeping it on at night and let you know in the morning if something happens. I'll also keep you posted on if you can access my workspace.

Sounds good, thanks!

K. So I left the instance of code running overnight, and didn't have a problem with it crashing or feeling immediately laggy. I continued work today, and even took a tiny bit of a break from using it while doing other things, and it started to be laggy again. It almost seems that maybe the problem isn't from actively using it, but it also sounds like something else triggered it during the time I've been working on it.

I'll run the profiler to keep my eye on it, and I'll create a new issue if there are other findings different than those explained above.

I haven't checked to see if you can have access to my workspace, though I'd suspect I can't share that with you, unfortunately.

I tried to run the profiler yesterday when it was getting particularly slow and when I was taking a heap snapshot, the computer maxed out of available RAM, and I could hardly do anything at all, not even force close Code, so I had to restart the computer. I'll try to run it sooner than I had before to avoid that happening again.

This is a little off-topic, but you posted the link for the insiders build, which I visited. I wanted to download the windows version (as I use that at home), and whenever I try to get to that link, it redirects first to the usual download page, but then promptly redirects me to the main page without initiating a download. In fact, it overwrites the history for the download page I was on, so I can't even go back in history to get to it. Is there any other way I could get the insiders build?

@cwadrupldijjit

This is a little off-topic, but you posted the link for the insiders build, which I visited. I wanted to download the windows version (as I use that at home), and whenever I try to get to that link, it redirects first to the usual download page, but then promptly redirects me to the main page without initiating a download.

Sorry about this, but some users reported some strange issue on the insiders build and we temporarily took it down until we understand this issue.

@egamma I wondered if it might have been inaccessible because of that. I'll keep an eye out for when it works, then.

@Tyriar I tried the chromium workspace over night on Linux, Windows and Mac and could not reproduce a crash. Could you try it again please?

I am not sure if this is related but I have noticed that VS Code tends to crash during my work day if I open it and forget about it for awhile. I am at work for 11 hours and I generally open code first thing in the morning. At some point during the day my computer will slow down and start hanging until either it crashes or I force-kill it.

Just in case it might help...

The primary project I have open in VS Code is a relatively unmodified version of a shopping cart called BVCart (version 2004.7). I have around 25-30 working files right now and even just opening VS Code and not touching it all day leads to a crash.

The project is 1836 files and 130 folders totaling around 35MB and it is contained in a small git repository.

@ZombieProtectionAgency is it possible to share this workspace with me?

@bpasero Sorry, I definitely couldn't share it :( I haven't looked but you might be able to find it online somewhere. It is just a mostly-flat old-fashioned ASP VB.Net shopping cart. The large majority of the files are .vb with aspx, ascx, and a small handful of css files.

I'm having the exact same error. VS Code just crashes every few minutes. I'm using it with elm. It does not clash when it is left on. It clashes within minutes after I start ending the file. It has been like this for the past three days making VS Code unusable. How do I check what is going on? I'm using version 0.10.10.

Another thought I had: We do have a service that can receive output from various end points (git, tasks, extensions) and this is something that can happen in the background and add up. We did quite some fixes in this area for GA that are not in previous releases.

If anyone with overnight crashes could just briefly check if there is any output logged from the background? You can see that from View > Toggle Output and then switching through the channels from the dropdown.

@bpasero
In the 'Tasks' output I'm just seeing output I would expect from my own compile task.
In the 'Git' output I'm seeing a fair few git fetch's, interspersed with a few git show's. I'm not sure how frequently though as there isn't a time stamp. No other output though.

We do auto fetch every now and then but the main output you see there is probably from the work you do within VS Code. Would be interesting if the output adds up when VS Code is in the background. Is the task running constantly or only when you explicitly invoke the compile task?

The task is just when I ctrl+shift+B and ends shortly thereafter. I've had crashes however when I haven't run a task.

I get two identical git show's when I switch between files and yes the git fetch's occur automatically once every couple of minutes.

Note that I don't do any checkouts etc within VSCode, I use SourceTree for all git related tasks.

@bpasero I will leave the output window up today and see if anything appears. Currently it has been open for an hour or so of normal use and I don't see anything in the tasks or git views. We do not use git, so I wouldn't expect to see anything in that as a general rule.

Our latest insiders build is out and I would appreciate if people could give it a try on this issue: https://code.visualstudio.com/insiders

@bpasero I still had the previous insiders build, can I just run that and do "check for updates", or do I have to update the build from the link you gave?

Will try and get back to you. To be honest I am seeing less of the VSCode
crashes nowadays. Atleast it doesn't crash everyday.

I can make it crash by openening a huge file with million plus lines
minified js and scrolling up and down repeatedly. But I know what is
pushing the limits of editor.

Whatever you have been adding as magic sauce is working for me.

On Wed, Mar 16, 2016 at 12:29 PM, Benjamin Pasero [email protected]
wrote:

Our latest insiders build is out and I would appreciate if people could
give it a try on this issue: https://code.visualstudio.com/insiders

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment-197503185

@gwynjudd you should be able to update if the VS Code logo shows up as green logo:

@nojvek yes that is pushing the limits a bit. for the march release we did explicit memory testing to find areas where we can improve. the insiders build includes some of those fixes (not all, we did some changes yesterday and today that are not yet in). so just curious if it makes any difference for people that see this...

@bpasero thanks I've done that and I'll let you know how it goes

@bpasero still got the same crash overnight with the march insiders build. Do you want me to to try getting a heap dump from the developer tools during normal use? I can try to keep an eye on the memory usage for code and grab a dump if it appears to be going up

Yes please, thanks.

Here is a heap snapshot immediately after launching code (memory usage about 100MB at that time)

Heap-20160318T115937.zip

I'll try again in an hour or two. The tricky bit seems to be getting it at a point where the memory has increased somewhat, but not so much that taking the snapshot triggers it to crash out of memory.

I saw the same kind of results when I tried taking a heap snapshot (ran out of memory), and it’s not fun.

I feel like there are still some memory issues in the latest insiders build (for mac).  I’ll see if I can get another heap snapshot without sacrificing my computer.

@bpasero sorry I haven't been able to successfully get a heap snapshot yet. Either the memory is very low such as for the one I captured before, or it jumps up to say around 500MB or more and grabbing the snapshot triggers a crash.

I have to restart vscode 1-2 times a day because the memory usage climbs over 1GB and things start feeling sluggish. It's using the amount of memory that a full blown IDE would, so there's definitely some leak going on.

@vincent-ly can you share more details about the workspace you see this with?

@bpasero There are about 30-40 js/scss/html files that uses a couple of bower components with gulp (without the vscode task runner). I work with 2 editor panes and frequently use the file search, pretty standard. The memory usage is under 100mb on startup, but builds up over time, even when minimized.

Does intellisense play a factor? I have Angular and jQuery type definitions installed.

You can try our insider build where we worked on reduced memory pressure to see if that makes it better: http://code.visualstudio.com/download?insiders=true

Do you have extensions installed?

@bpasero Just angular snippets
https://marketplace.visualstudio.com/items?itemName=johnpapa.Angular1

I'll try the insider build and report back, thanks!

+1

Seeing the same issue on VSCode for Windows 0.10.11. It typically crashes every night consistently when not in use. Given steps to collect info I'd be glad to help.

Running on a TypeScript git repo with 28,438 Files, 4,812 Folders. Has gulp watchers as well, with many TypeSript defs.

I have the following extensions installed:

• PowerShell
• C#
• Material Theme Kit

@alanwright could you try if it still reproduces with our latest insider build (http://code.visualstudio.com/Download#insiders). If so, can you share the workspace with me?

@bpasero It reproduced over night with insider build. I tried in both our private larger enlistment and our open source enlistment, and only the larger private enlistment seemed to cause the problem, which I unfortunately can't share (it is Microsoft internal though so maybe we can get you access? My alias is alanwri)

Is there anything I can do on my machine to capture logs and share with you?

Please share with me on my alias benjpas, thanks! Would also appreciate some details how you use VS Code on that workspace to cause the memory increase.

I am also getting crashing overnight and during the day.

It doesn't seem to be particularly related to just a workspace, extremely small workspaces 3-20 files or huge workspaces, predominantly noticed when having multiple windows open.

Repos I have used that crashed.
1500+ asp,js,.inc(asp) files
70 + files asp.net core, js,cshtml
This repo (https://github.com/gogits/gogs)

@eByte23 do you run with or without extensions? on what platform are you? did you try with insiders release?

@bpasero Win10 & OSX with C# as extension.
Have tried insiders but have not noted if it crashed as there is a tabbing bug so I stopped using it but I can leave it running over night to try to repro.

@eByte23 yes please. what tabbing bug?

@bpasero seems to be in last two releases of insider with display whitespace on and convert tabs to white space with a file with existing tabs it seems to keep tabbing and not write spaces even on new lines.

I hadn't had a chance to do full testing but I shall do that now.

@eByte23 I suggest you report something like that as separate issue if you think it is one. we introduced a new setting editor.detectIndentation which defaults to true. Maybe you can try setting it to false.

@bpasero My bad you are totally correct setting that setting to false fixed my issue.
I tested out Insider Yesterday overnight and it also crashed.

@bpasero seems like you guys might be getting on top of this one, from my perspective it seems to be getting generally better with the latest builds

We invested quite a bit in memory leak fixing for the 1.0 release, so I would expect the situation to be better with 1.0. But there is still cases where it happens.

I might have a new theory because I recently found out that Electron applications (our UI framework) get throttled as soon as their window either looses focus or moves to the background. I wonder if this throttling could have an impact on memory consumption.

Whenever I tested to reproduce I left the VS Code window open with keyboard focus, so maybe one difference is to let it run in the background.

There is a way to disable background throttling so I could produce a build with a flag to enable this.

Otherwise it would also be interesting to hear from people if a crash after minimize is the typical scenario.

All of my crashes happened when VSCode didn't have focus. Generally they happened after leaving it in the background all day while browsing the internet or using Visual Studio

I second this. I recently experienced a crash . It was with a VS in
background when I had focus on sublime for most of the day.

On Sat, Apr 16, 2016 at 11:44 AM, Toni [email protected] wrote:

All of my crashes happened when VSCode didn't have focus. Generally they
happened after leaving it in the background all day while browsing the
internet or using Visual Studio

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment-210872544

Experienced a crash when using the insider build not long ago. Had been on for 2 days. It suddenly became slow. Selecting text with the mouse stopped working. Shift-Right worked but very slowly. The app crashed a few minutes after losing focus.

This is my first crash for the insider build but as for the normal build, I upgraded to v1.0 and it still crashes every few minutes or so after opening making it unusable. I don't even have to do anything special. Open it, edit a file (mostly .elm files) or just let it be and it just crashes. Doesn't even wait to lose focus first.

1.0 crashes almost every night.
Windows 10 Ent.
Plugins: Spelling and Grammar Checker, ESLint

Ok, an insiders release is out with my change included. Would be happy for someone to give it a try: http://code.visualstudio.com/Download#insiders

Anyone :)?

Using it now. Haven't had a crash since yesterday.

@bpasero I'll upgrade now and leave it running overnight and see how we go! Cheers :)

@bpasero I installed it friday but then went away for a long weekend, also my work PC was rebooted so I have nothing to report.

@bpasero Had a crash yesterday. Stayed up for 3 days before crashing.

@bpasero I'm still seeing the occasional crash in the morning with the latest insiders build

Me too.
Windows 8

@bpasero Insider 1.1.0 stacks better, took almost a week before it crashed.

I'll pick up 1.1.0 now and see how it goes

I can't seem to take a heap snapshot without it crashing when the memory usage is over 150mb.

Every morning, I unlock my computer to find VS Code has crashed overnight.

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

I've usually left files open. I do run with extensions. Are there any settings I can use to help gather more diagnostic information?

Our new insiders release is out (http://code.visualstudio.com/Download#insiders) and includes our work for tabs/stacks. This comes with a more aggressive disposal of resources because as soon as you close an editor, we get rid of its underlying resources.

Curious if people could selfhost on this for a while and report back if things improve.

Note: insiders from now on get updated nightly (see http://code.visualstudio.com/blogs/2016/05/23/evolution-of-insiders)

@bpasero I've update all my devices today, see how we go over next few days

Yeah I've primarily moved to insiders because of terminal. Oh how much I
love it. I've found the editor to be a lot snappier and lighter. Great work.

Is there any way I can replace "code ." In command line to point to
insiders?

On Wednesday, June 8, 2016, Elijah Bate [email protected] wrote:

@bpasero https://github.com/bpasero I've update all my devices today,
see how we go over next few days

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment-224539214,
or mute the thread
https://github.com/notifications/unsubscribe/AA-JVM4KoGeXoc2SU5VeEYnxkZyPVWYMks5qJo13gaJpZM4Gnvn5
.

Still happening on 1.2.0 for me. Happens every night - running on Windows 7 Enterprise SP1. I've got the same question as @garthk

I've usually left files open. I do run with extensions. Are there any settings I can use to help gather more diagnostic information?

@northerncodemky I was referring to the 1.3.0 insiders release where our tabs/stacks work is included (http://code.visualstudio.com/Download#insiders). I would not expect any much change in 1.2.0.

@bpasero Aah ok - didn't clock the timestamp on your comment. I'll switch at some point today to see if this improves things. And get some new features to boot :)

@bpasero looking good so far!!

I had VSCode Insiders build running over the weekend. Came in Monday morning and saw a crash.

I'm wondering if there is any telemetry crash/dump data that is automatically sent when VSCode crashes? Sort of like watson reports.

I got a new machine last week. When I set it up, I only put the release build (not insiders) - I haven't noticed it crash since then.

@bpasero I haven't seen any crashes since 1.3, running windows 10 insider build >= 14367

@bpasero with tabs enabled, opened a c# project and vscode is crashing error couple of minutes after latest update to insider commit hash: 5474147bb83618975409dad7d8aa96151d7d1ea1 .
NOTE: I had previously not enabled tabs until now

@eByte23 can you verify this is related to having tabs enabled or not by trying without tabs?

@bpasero still happening when tabs are disabled, but no where near the severity with tabs enabled.

But is heavily noticeable and reproducible when working with images, clicking between large images quickly in both insider and v1.2.1

@eByte23 I suggest to open a new issue on that with as much detail as you can provide (e.g. does memory grow?).

Sure can do. I haven't done a huge amount of investigation around it yet but I'll get some in-depth details for you a bit later.

VSCode 1.3.1 crashes about twice a day for me, once overnight (always) and sometimes randomly during the day. It just crashed now while I had it open in the background, not using it for about 2 hours. Also upon opening vscode again it loses my workspace, and I have to re-open the project folder it had open before the crash. Tabs and splits are preserved after re-opening the folder.

i left open in the background for a while with unsaved changes, came back, started typing and vscode froze for a few seconds then crashed. it lost my work.

I hope you can understand my frustration. This is unacceptable for an editor. Also the session it restored didn't even have the right tabs open, nor my place in each tab.

@DelvarWorld can you share more details about your working environment? can you try to run with extensions disabled to see if that helps?

I have this same issue on Linux Mint 17 Qiana (cant remember which version of ubuntu that is!). It just froze for me after ~2 hours of inactivity. I'll remember to check memory/CPU usage next time it happens, though I have never noticed a general slowdown in other apps etc when this happens.

VSCode info:

Version 1.4.0
Commit 6276dcb0ae497766056b4c09ea75be1d76a8b679
Date 2016-08-04T16:49:32.489Z
Shell 0.37.6
Renderer 49.0.2623.75
Node 5.10.0

This issue has gone away for me (on 1.5.3, Windows 7) - given the last comment is 2 months ago is this maybe resolved?

I haven't seen this occur for me in ages either. I've been using the current release for months. SeemsGood

Same. Doesn't seem to overload at all.

Ok, we should continue in individual issues and avoid monster bugs like this one that are hard to track. If anyone is still seeing this issue, please file new issues with more details. PLEASE avoid hijacking an existing issue 👍

I also remember seeing this before and haven't seen it in ages, so, that's my verification.