Not my area of expertise (hopefully others chime in), but a good next step is to get a heap profile using chrome://tracing.

See the instructions at:

https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/README.md

I can only run a trace for about 10 seconds; any longer and I get "RangeError: Inflated gzip data too long to fit into a string (1084334579)."

Even gzipped the trace is still double the attachment limit, so here's a link: https://drive.google.com/open?id=0B_D42pFMZLiwVTQ2OGdhOWY1MVk

Let me know if I should upload this a different way or enable different trace options.

Thank you for providing more feedback. Adding requester "eroman@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thanks for the log!

I looked at it and was able to confirm that the browser process is using lots of memory, however couldn't classify *what* is using it.

@primiano: What can you advise for getting more data on the memory usage? When looking at the dump I see 5GB of non-specific mallocs(). Is there any easier way to get the allocation callstacks than having to re-build Chrome per https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/heap_profiler.md ?

Same observation as eroman@. I don't see anything obvious that could contribute to the 5GB mallocs() from the browser process in the trace.

The pseudo stack mode (--enable-heap-profiling flag) involves restarting chrome, which might not be a good way to investigate this since we will lose all information and start from scratch.

+erikchen@ who might know how to debug this.

> Is there any easier way to get the allocation callstacks than having to re-build Chrome per https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/heap_profiler.md ?
 
What xunjieli said in #7, but yes that involves restarting the browser.
Btw this is 57 which I think has some known leaks (go/chromepostmortem404 at least)  

Thanks, primiano@. You are right. net/ MDP instrumentation was added in f5267debb22eacffc2287fba55832299ef640bbb (58.0.2988.0 and later), so we don't know whether this is a dup of chromepostmortem404.  

danh1420@: could you update to M58 Stable? If you encounter this problem again, please get a memory-infra trace as you've done in #4.

Here's a new trace taken about 24 hours after updating to 58.0.3029.81 and launching with --enable-heap-profiling: https://drive.google.com/open?id=0B_D42pFMZLiwbzNzZ0tGYTdHaTg

Memory usage isn't as high as before because the browser hasn't been running as long, but it looks about consistent with where it was 24 hours after launch on 57.

Thanks! There's a lot of good information here. Attaching a screenshot of malloc from the browser process.

ssid@ and dskiba@ have the most experience here.

Deleted: Screen Shot 2017-04-28 at 2.29.30 PM.png 51.9 KB

	Screen Shot 2017-04-28 at 2.29.30 PM.png 51.9 KB View Download

Not sure what [gdbus] is. The 50MB from network stack is mostly the in-memory http cache used for incognito/guest profile. The usage from network stack seems normal.

hm I have seen dbus using memory before. But, 200MB seems to be too much.
I'd be surprised if this is the one that grows to 5GB later. It'd be better to try and get a trace once the memory grows higher.
+dbus owners to verify if the usage seems fine.

I've been trying to get a heap profile with higher memory usage, but Chrome is consistently crashing after 24~48 hours when I launch it with --enable-heap-profiling. Most recently, I got crash IDs 28554df0d0000000 and e8d2cdf0d0000000 (I assume it generated one dump for each profile I had active at the time). The browser crashed the moment I tried starting an Incognito session, so I wouldn't be surprised if that's related.

I checked the crash reports, that has been fixed by https://codereview.chromium.org/2787383002/, which is 59.0.3062.0 .
Before that we were crashing if the number of allocations >> the max space we reserved 
 in the tracking  datastructures of the heap profiler.

Re: comment #14
Probably the gdbus thread is created by Glib's D-Bus binding.
We prefer our own D-Bus lib under src/dbus so chrome/browser/notifications has switched from gdbus to src/dbus in https://codereview.chromium.org/2821533003/.
However, it looks chrome/browser/ui/views/frame/global_menu_bar_registrar_x11.cc and src/third_party/libsecret/ are still using gdbus.

danh - can you try again with a newer version of Chrome [e.g. Chrome Canary]

I'd actually just updated to 59.0.3071.104 a couple hours before your comment and restarted using --enable-heap-profiling. No more random crashes with that flag on v59, so that's good.

Here's a trace after using the browser normally for about 2 days: https://drive.google.com/open?id=0B_D42pFMZLiwc1B2RWFqb2JicEE

Thank you for providing more feedback. Adding requester "erikchen@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Quick update on this issue: not only is this still a problem in Chrome 63, it's slowly but steadily gotten worse. The attached screenshot showing nearly 13 gigabytes of memory usage in the browser process was taken just 3 hours after relaunching Chrome. Half of that time was spent doing some casual web browsing (Gmail, Facebook, YouTube, nothing too crazy), and the other half the computer was completely idle.

Is there any other information I can provide to help identify the source of this problem?

Deleted: Screenshot at 2018-01-16 18-36-16.png 17.2 KB

	Screenshot at 2018-01-16 18-36-16.png 17.2 KB View Download

Erp! Yes! Thanks for pinging.

Please take the following steps:
1) Update to chrome dev channel [m65]
2) Navigate to chrome://flags and set "memlog" to "profile the browser process".
3) Restart Chrome
4) Let Chrome bloat to 2GB or so. Higher is fine. 
5) Navigate to chrome://memory-internals and save a dump, then attach it here.