New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 801702 link

Starred by 7 users

Issue metadata

Status: Fixed
Closed: Mar 2018
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , iOS , Chrome , Mac
Pri: 1
Type: Bug

issue 802310

Sign in to add a comment

Chrome main process memory leak [2GB] in glib.

Reported by, Jan 12 2018

Issue description

Chrome Version       : 65.0.3315.3
OS Version: XUbuntu 17.10
URLs (if applicable) :
Other browsers tested: None

What steps will reproduce the problem?
1. Open chrome
2. Use chrome

What is the expected result?
Chrome not to use a larger and larger amount of memory.

What happens instead of that?
The Chrome _main_ process starts to use more and more memory, reaching over 10GiB in quite a short time span. It also seems to evade the oomkiller, so this causes my entire system to freeze.

Please provide any additional information below. Attach a screenshot if

I've ran chrome with "--disable-gpu --memlog=minimal", however, I've attached about:gpu.
I've also attached a memory profile and screenshots of Chrome's Task Manager after use, and after having closed all other tasks.

Here's a timeline of the increased memory usage:
In most cases when the memory usage increased dramatically, I believe the browser was sitting idle.

UserAgentString: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3315.3 Safari/537.36

This has been happening over a month, and for quite a few versions, on stable and unstable chrome versions, and on different versions of Ubuntu.

I don't know how to continue even debugging this, apart from restarting chrome at regular intervals, there doesn't seem to be any workaround.
4.7 KB View Download
131 KB View Download
31.3 KB View Download
25.9 KB View Download
151 KB Download
Labels: -Pri-3 Performance-Memory Pri-2
Status: Assigned (was: Unconfirmed)
Thanks, investigating.
Attached symbolized trace. I looked up the 4 glib addresses, and symbolized using

The four symbols correspond to:erikchen@erikchen:/tmp/out3/usr/lib/debug/.build-id$ ./ 

which correspond to allocator_memalign, g_malloc, g_realloc, and g_malloc0

So - something calls glib and leaks a lot. primiano guesses dbus or gconf.
175 KB Download
Labels: -Pri-2 M-65 Pri-1
Over to thomas anderson, our resident Linux expert.

There's not much more I can do here without a full stack trace. ajwong@ and primiano@ are currently discussing some potential changes to get there on slack.

thomasanderson: This issue seems to have really cropped up around M63. Any change in that time period that might cause this type of issue?
Summary: Chrome main process memory leak [2GB] in glib. (was: Chrome main process memory leak)
Looks like hidehiko has been making non-trivial changes to dbus.

Comment 6 by, Jan 16 2018

Is there any more data I can gather to provide you with?
One temporary workaround would be starting chrome with
ltrace -llibglib* /opt/google/chrome and see if there is something that stands out

Comment 8 by, Jan 16 2018

When starting with ltrace, the process seems to die before any GUI shows up. I've attached the output
6.0 MB View Download
Blocking: 802310
If you have time, please take the following steps. This is a bit involved, but should get us sufficient info to debug the problem.

1) Download and extract this custom build of chromium. It's a release build, with unstripped CFI, and our heap dump code has been changed to use backtrace() instead of framepointers.

2) Take your existing instance of chrome and navigate to chrome://version. Record the profile path. Mine is 

3)_Close Chrome.

4) Make a copy of the profile [path minus the Default or Profile 1 suffix] e.g.
cp -r /usr/local/google/home/erikchen/.config/chrome-remote-desktop/chrome-profile /tmp/test_profile
We'll work with the test profile to prevent anything weird from happening to the real profile. 

5) Launch unstripped-chrome. I extracted to the desktop, so for me it's
~/Desktop/unstripped-chrome/chrome --user-data-dir=/tmp/test_profile

6) Confirm that chromium has launched. The icon should be shades of blue instead of red/yellow/green.

7) Navigate to about://flags and turn on "memlog" to "profile only the browser process".

8) Do the thing that gets chrome to bloat in memory. This might be as simple as letting it sit for a few hours.

9) Navigate to chrome://memory-internals to get a heap dump. Send it to me.

Fingers crossed. :)

Comment 11 by, Jan 17 2018

I've attached the heap dump using the binary from that link, I've also attached a log of the cpu/memory usage over time.

The main process in the binary used a LOT of CPU and performed really badly, is this normal for an unstriped binary when profiling memory?

176 KB Download
4.0 MB View Download
whoo, awesome. Attaching symbolized trace.

performance - yeah, that's a combination of the change to use backtrace(), as well as the heap profiling itself.

There's ~700MB being leaked via gio on a new pthread, along with some PasswordStore code. Will dig.
188 KB Download
Screen Shot 2018-01-17 at 11.43.08 AM.png
344 KB View Download
george@ you are our hero! Thanks so much, your help here is super useful (especially when erikchen@ does all the rest of the work :P).
danakj points out a potentially related crbug:

still digging.

Comment 16 by, Jan 17 2018

My pleasure. I've been experiencing this bug for a few months. It sometimes interferes with work. I've even switched to firefox for a few days because of it, but the experience didn't even come close.

I asked around on IRC a few times with no reply, then was discouraged by all the non-useful "my chrome is using too much memory" bugs that have no activity for months, and finally decided to do all I can to help squash this bug!
trace with glib and gio symbolized. nothing too exciting that's new.
188 KB Download
Screenshot of the 800MB chunk of leaked memory. Just glib/gio doing some parsing on another thread. Root cause is probably still the same [guessing password still].
Screen Shot 2018-01-17 at 1.27.31 PM.png
258 KB View Download
There's probably more than 1 problem.

More details on obvious chrome leak:

There's also the question: Why is the password manager being called millions (?) of times. This is probably not a particularly cheap operation.

The heap dump suggests that we're querying the password manager 100,000s or millions of times. Any idea why that might be happening?

Comment 21 by, Jan 17 2018

Same issue here, the main Browser process leaks 15GB per day for me. Let me know if there's anything I can do to help.
I put up a CL to fix the obvious leak. The next thing I want to figure out is *why* this is being called so often. Will post back tomorrow with some follow up steps.
I am not noticing unreasonable calls to the password manager when I run locally.
George, when you used Chrome, did you visit a website and which one?

+vasilii, who understands better what fetches the password list.

Comment 24 by, Jan 18 2018

I've logged in on several websites, I've also got LastPass running, in case that matters for anything.

I've also managed to reproduce the leak without vising any sites with any kind of visible password fields, extensions disabled and just browsing.

This happens when I'm idle as well, so I don't think user input is relevant.

I can reproduce the bug, if there's any way of me providing you with more debug info from a running process, let me know
I'm working on putting together a custom build of Chrome that will give us more debugging information - hopefully to the point where we can figure out what's causing all these password manager invocations. :)
We retrieve passwords when we see a form on a site. Thus, thousands of PasswordStore::GetLoginsImpl calls is extraordinary.

Can you open chrome://password-manager-internals/ next to your other tabs and browse normally? It will record the interesting events while the tab is open. Then you can post the log here.

Comment 27 by, Jan 18 2018

I've attached a paste of the chrome://password-manager-internals/ page
115 KB View Download
Oh, awesome. Even as someone who knows nothing about what this log means, there are several things that stand out:

"Number of pending login managers" increases over time, ending at 57 at the end of the log.

Problem is probably with "".

There are quite a few "Message: Generation invalid PasswordForm " and "Message: Generation: no non-blacklisted confirmation " messages.
I made an account on and logged in to the freenode #chromium channel. Every minute, there are 13 calls to "NativeBackendLibsecret::GetLoginsList".

At a guess, any single page site which dynamically creates forms will cause this issue.
I posted a test page. It causes an infinite stream of calls to GetLoginsList.

Notably - if I don't remove the previous password forms, every single password form is queried every time any password form is added, which causes N^2 calls to GetLoginsList. :O
680 bytes View Download
Project Member

Comment 31 by, Jan 18 2018

The following revision refers to this bug:

commit e3e1bc737140de3f68b2a40dfa1f51ad3815460c
Author: erikchen <>
Date: Thu Jan 18 16:31:29 2018

Fix memory leak in Linux libsecret wrapper.

secret_service_search_sync returns a glist, whose elements must also be freed.
The existing code did not do this. This CL creates a new SearchHelper to wrap
this call. The results are stored in the SearchHelper, whose destructor will
correctly free the elements.

This CL updates the key_storage_libsecret and native_backend_libsecret unittests
to return real GObjects from secret_service_search. The tear down steps now
check that the GObjects are correctly unreffed by the caller.

Bug:  801702 ,  393395 
Change-Id: I0dcac794d4d79499742aea6e7e42a99135367a51
Commit-Queue: Erik Chen <>
Reviewed-by: Thomas Anderson <>
Reviewed-by: Vasilii Sukhanov <>
Reviewed-by: Christos Froussios <>
Cr-Commit-Position: refs/heads/master@{#530162}

Comment 32 by, Jan 18 2018

Can confirm that the test page causes memory usage to increase fast.
I agree that from the log generates more calls than it should. So there is a bug in the password manager here (and in the page too as it seems to generate too many forms).

george@, can you confirm that without opened your memory consumption is doing better?

Comment 34 by, Jan 18 2018

vasilii@, the memory consumption appears to be better with closed.

The test page submitted by erikchen@ also appears to increase the memory usage at a fast pace while opene (I've modified the timer to spawn forms faster).
Okay, even with the fix, there are still some slow leaks in the browser process.

repro steps: 
1) Run infinite_forms.html [change the settimeout duration to 10ms]
2) Watch browser memory climb over time.

I've attached a JSON file which contains stack traces of all leaked allocations. Load the contents in to see it easily.

Almost all leaks come from CreatePendingLoginManagers. At a guess, we never clear pending_login_managers_ unless the page goes through a navigation.

This sounds very similar to
I'm not seeing any other leaks caused by libsecret.

So, handing bug over to vasilli. Two issues:

1) N calls to GetLoginsList every time a single password form is added.
2) Objects created in CreatePendingLoginManagers are leaked on test page.

22.3 KB View Download
vasilii: Ping.
I'll look into it soon.
The regression happened in r496263. The form without name doesn't match itself. Therefore, we create enormous amount of PasswordFormManager objects and every single one creates a request to the password store.
Nice find! Thanks for following up. :)
Project Member

Comment 40 by, Mar 6 2018

The following revision refers to this bug:

commit fb3209a2a966a499243dd844490879f4fb4a6ff8
Author: Vasilii Sukhanov <>
Date: Tue Mar 06 18:05:28 2018

Improve password form matching.

Current code is written in a way that a form without action or name doesn't match itself. It's a performance problem because PasswordManager::CreatePendingLoginManagers continuously creates a PasswordFormManager for the same form leading to poor performance.
The code was firstly introduced in However, motivation for it is unclear after discussing together.

Bug:  801702 , 597309 
Change-Id: Ie2458d8d5340852530675b9f5d7f627132e1f3c6
Commit-Queue: Vasilii Sukhanov <>
Reviewed-by: Vadym Doroshenko <>
Cr-Commit-Position: refs/heads/master@{#541145}

Components: UI>Browser>Passwords
Labels: OS-Android OS-Chrome OS-iOS OS-Mac OS-Windows
Status: Fixed (was: Assigned)

Sign in to add a comment