Tentatively tagging garbage collection - not sure if this component is correct. Assuming this bug is cross-platform since it's probably a blink issue.

Any update?

I am also facing same issue.
Steps to reproduce the problem:
1.Each ajax request Task manager increased by 20 MB 
2.Event after removing the entire element but memory not released
3.We have checked for detached DOM, Event Listeners, but found none.
6. After 1 hour of repeating this operation browser memory reaches the max and getting crashed.
7. I have checked some other sites like Facebook, For that too, when i load more content, Tab memory got increased and getting Crashed.



 

Please click multiple time(minimum 10time) for change content button.

Deleted: leak-xhr.html 1.0 KB

leak-xhr.html 1.0 KB View Download

Deleted: leak8.html 1020 KB

leak8.html 1020 KB View Download

Any update?

I can't reproduce this on Chrome for Linux 55.0.2883.87 (Official Build) (64-bit). It's normal for the tab's memory use to not drop all the way down to that of a blank renderer, but it *should* go down. Can you try reproducing this in an Incognito Window, and tell us exactly how to reproduce it? (For example, you mention clicking the button ten times, is that ten times slowly or something?)

We are Using  Chrome(55.0.2883.95 (64-bit)) for Mac OS X EI Capitan (10.11.6). I have attached latest files & Youtube URL of Demo https://www.youtube.com/watch?v=_1F8uf--e34 

1. Before Appending DOM, Tab Memory is 60 MB. 
2. After Appending DOM, Tab memory raised to arroung 400 MB.
3. Even after removing the entire dom, Tab memory not released. 

Deleted: leak-xhr.html 1.0 KB

leak-xhr.html 1.0 KB View Download

Deleted: leak8.html 1020 KB

leak8.html 1020 KB View Download

Any Update?

Memory team, could you please take a look?

Thank you for providing more feedback. Adding requester "dominicc@chromium.org" for another review and adding "Needs-Review" label for tracking.

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

Any Update?

I really think this needs a memory person to investigate. They can tell what state that 400MB of memory is in. Just using the task manager's memory isn't very useful.

I'm unassigning myself and moving this back to untriaged, the memory team will triage it and can investigate. Sorry I can't be of more help.

Memory team needs to investigate?

Any Update?

Been looking into this one some, with mixed results wrt what's being reported. On Windows and linux targets, but not OSX. Using current versions, not M55.

For the given testcase, upon clearing contents, I do notice a clear drop-off in memory resident size. That clearing operation should trigger GCs and do, which will clear out most DOM nodes. We could possibly be more aggressive about fully letting go of the freed heap pages on the Blink GC side -- will continue to look into that.

The video is/was very helpful, thanks a lot for doing that, but I do wonder if the test didn't trigger enough allocations and activity after clearing contents (=> the M55-based browser didn't end up doing any GCs to balance the books..possibly.) So, would it be possible to retest where you repeatedly clear and just generally mouse around, to see if that makes a difference? Testing with newer versions would also be a valuable data point.

Yes. Today  I have tested in latest chrome browser  (Version 56.0.2924.87 (64-bit)) OS Version ( OS X 10.11.6). Memory not released. (Dom memory garbage collection not collecting properly).

Thanks a lot, useful extra data point wrt M56. This appears to be OSX specific.

I do wonder if we are running into the same issue that Mozilla did with jemalloc memory usage measurements some time ago, not getting real, but over-inflated, RSS (aka "in-use memory" for a process) readings on OSX [1, 2]. Blink's page allocators will let go of pages in the same way as jemalloc by calling madvise(.., MADV_FREE). MADV_FREE is a lot lazier on OS X, that we know (cf. [3]) ), so if the machine you're testing on isn't up against memory pressure, the pages will not be recycled back to the OS. With the outcome here that RSS will not be reporting a real active footprint for us on this platform, like it does elsewhere.

I don't have access to a Mac atm, I'm afraid, but if you're willing to run an experiment... what happens if you run your testcase, and then switch to another application or start up a new, causing other processes to allocate a (lot) more memory - does the reported memory in devtools shrink when you switch back? If there's evidence of that, then we could be getting somewhere..

1 - http://jemalloc.net/mailman/jemalloc-discuss/2011-October/000037.html
2 - http://stackoverflow.com/questions/7718964/how-can-i-force-macos-to-release-madv-freed-pages
3 - https://codereview.chromium.org/2531973002#msg151

Cleaning up sheriffbot label "Needs-Review" label as a part of modified "Needs-Feedback" sheriffbot rule. [ref bug for cleanup 684919]

This is likely fixed by https://codereview.chromium.org/2818623004/

Thanks a lot  Chromium Team for fixing this Memory related issue.

To the reporter, did you confirm that their fix fixes what you were seeing?

Please send me procedure to test in our local setup.

#18 has suggested repro steps for this alleged memory-usage measurement problem on OSX.

I believe nives... was asking how he could pull the fix into his local setup to test. AFAIK the answer is that he has to wait for a new version of chromium to be released with the fix included.

I don't myself know how to tell what fixes are included in what versions.

The assigned owner "sigbjornf@opera.com" is not able to receive e-mails, please re-triage.

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

Mac triage: closing old issue without feedback and with likely fix.