Unfortunately as I was suspecting this is one of those cases that we are observing every now and then, where churn accumulates into the browser and today it falls into the catch-all bucket "malloc" (+erikchen). The rest is just lot of renderers.

We should get soon to a better state where we can tell folks: start chrome with --enable-heap-profiling and use TraceOnTap again. That will give us a full view of the heap (+erikchen). We are just not there yet.

Closing this bug as there is little action we can to today, other than observe that:
1. this problem (malloc in the browser growing) keeps happening 
2. lot of renderers processes have a cost (not a surprise). In this specific case 4 GB.

The real problem here is 1. I think beyond the leak, something adds up and slows down the browser.
2 will be mitigated  by the work on Purge&Suspend and memory coordinator, which are both happening as we speak.

Thanks for trying out TraceOnTap and sending the trace. Hopefully in a couple of months we'll be in the state where we can pinpoint what's going on in the heap.

OK. Thanks for looking into this, Primiano! If there's something I can do to help in the future, just let me know.

We recently added some extra instrumentation to the "sync" code and we found that it was a cause of similar bloat on Android (Issue 675682).
Such instrumentation is only available on  57.0.2928.0 and later.
If you happen to run dev or canary and end up in this situation again might be worth uploading a new trace, as that will help us narrow down more the issue and see if this is a culprit here.

I think the desktop memory growing problem exists without sync as well. The two main reasons are the libnss used in networking and the number of corp extensions that are running in Chrome. I haven't looked at the data yet, but last time I checked there were 6-8 default corp extensions, and they are run by default without any webpages. Each of this could cause certificates and sockets being cached in browser.

ssid, in this case we are talking about the browser *process* growing up, not chrome in its entirety. extensions don't explain why the browser process inflates, as they are separate renderers. Not sure about libnss but I would hope that we dont' reach 800 MB from libnss.

> I think the desktop memory growing problem exists without sync as well. 
well this is what we are trying to find out here.

Browser process was ~1.6GB res, ~9GB virtual this morning. I had to restart to make Chrome usable, but I'll switch to dev channel on Linux and see if I can repro.

I switched to dev channel (57) before the break, and I haven't seen an enormous (15GB) RSS like I saw earlier, nor unusable UI (missing popups, sluggish interaction, etc). I do regularly see 2+GB RSS and ~500MB browser process, which seems larger than in the past, though.

This is probably same as  issue 678768  which leaks memory. Thanks for filing the bug.