Could you provide an HTML file, jsfiddle URL, etc. to reproduce the issue?

1st load tab : 10628 Ko
1min not doing anything : 10704 Ko
one refresh : 10984 Ko
10 more refresh : 11536 Ko

5min of 5sec interval (commented code) : 13932 Ko

this example isn't very convincing since the ajax result is only few lines of html, but you can imagine when the ajax result is big

Deleted: index.html 805 bytes

index.html 805 bytes View Download

Deleted: jquery.js 94.1 KB

jquery.js 94.1 KB View Download

Thank you for providing more feedback. Adding requester "yhirano@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

I refreshed the page 100 times, but didn't see significant memory growth.
I see some amount of memory growth (~20mb) but it recovered after a while so I think it's due to delayed heap collection. 

you musn't refresh the page... you need to let it open and loop on the ajax...

i don't think it comes from the delay since i have extensions with a 15min delay between requests

I'm confused. Should I restore the commented out setInterval call to reproduce the issue?

what i'm saying :
- i have extensions that do ajax requests when the browser is running... (nothing special here)
- thoses extensions do multiple ajax requests every 15min (more or less) on urls in order to do some automatic checking/notifications for me.
- over a day, when i look the chromium's task manager, i see that my extensions (and other ones like adblock) take a lot of memory. (up to 1Go in worst days)

- i noticed that only extensions with XHR requests took a lot of memory. and when i "restart" thoses extensions, they go down to couple of Mo.

in the attached file, i provided 2 example : one onclick to generate 1 ajax, and one commented to generate ajax over time.

the example isn't really convincing since it's a tiny XHR result (few html lines) but for me, it's good enought to illustrate my problem since i can see a memory growth. (uncomment the setInterval() if you want to test; and let the page run for couple of minutes)

i hope this clears up things for you

Thank you.

 - I ran the html file with setInterval. Then the memory consumption went up (25MB => 75MB).
 - I ran the html file with setInterval and without '$("#container").html(data);'. Then I see no unlimited memory growth (25MB => 35MB => stable).

Can you run the test without '$("#container").html(data);'?

the $("#container").html(data); was just an example to see the ajax result...
my extension do not do that (i parse the data in most cases)

ps : i got an error "Your account is temporary blocked due to exceeding of requests limitation of your subscription type." (you flooded it haha )
maybe this is why your 2nd test only went up 10Mo

ps(2) : if you have a free public api with no limitations so everybody can test....that would be great

I mean, I see a similar memory growth WITHOUT ajax. Can you run the attached html file?

|content| in the file is an html content gotten from the site.

Deleted: index.html 2.7 KB

index.html 2.7 KB View Download

aaaah ... you're spot on !

the memory grows without the ajax...
even a simple $("#container").html(''); or document.getElementById("container").innerHTML = ""; is enouth to have the memory grow...

i guess it's not an XHR issue then.

Thanks, I fixed the title and the label. I have less expertise in DOM, so let's hope that another developer looks into this issue.

okay, just to be clear :
function refresh() {
 document.getElementById("container").innerHTML = "";
 return;
}
setInterval(refresh, 10);

^ this code have a memory growing

function refresh() {
 //document.getElementById("container").innerHTML = "";
 return;
}
setInterval(refresh, 10);

^ this code (1 line commented) is "stable"

Needs bisect with index.html in Comment 12.

i'm sorry, i didn't understand your comment ...

the code that generates a memory growth is in the comment 15. the comments before are now useless since i tought it was an ajax problem.

it seems to be a DOM issue

i attach a "clean" file with the problem

Deleted: memory_test.html 337 bytes

memory_test.html 337 bytes View Download

As per comment#17,able to reproduce the issue on Windows 7.
Observations:
1.Memory is not getting increased from M40 to M47 builds on task manager for the above html file.
2.Memory is getting increased from M47 to M59 builds on task manager for the above html file.

Memory:
40.0.2200.0 -13K-Fixed value
45.0.2454.101 -13632k-Fixed value
46.0.2490.71 - 13792k-Fixed value
47.0.2526.106 -13576k--Fixed value

48.0.2560.0 -Increased from 13564k to 20k
50.0.2652.0 -Increased from 14180k to 16K after 15mins
Till latest canary observed memory is getting increased in Task manager 

Please look into the issue.
Thanks.

Marking it as 'Untriaged' for further investigation removing needs-bisect label as the issue is inconsistent. Feel free to add it back if anyone has consistent repro case.

Thank you!!

I reproduced the memory growth with 57.0.2987.133 Stable.
However I didn't reproduce it with 59.0.3064.0 canary.

francois.deyme@, can you test with newer canary?

tested with canary 59.0.3064.0 ... it still grows.
starts at ~11500Ko, then kind of stabilize ~10 seconds at ~12000Ko, then grows...
14000Ko in less than 3min

Here's a file which might exhibit this slightly more quickly, as long as it's visible (it is rAF driven.)

haraken, we need a way to judge reliably whether these repros are leaking or not. Since that's a memory-infra thing I think you're responsible for that. If there's no leak here, it would be good if the memory statistics users see where more usable so that they don't think there is a leak.

Deleted: memory_test.html 375 bytes

memory_test.html 375 bytes View Download

Even if comment #22 wasn't for me the more feed back you have, the bette. I still tested it with chromium and canary : both have indeed a faster memory growth with this new file (~500Ko / 30sec)

I don't think this is leaking something but I suspect that V8 GC is not happening for some reason.

What is growing btw? This test is just setting an empty string to innerHTML. Maybe the a JS function object is increasing?

keishi@: Would you mind taking a look at this?

the 2 screenshots are less than 1min apart

Deleted: memory.png 97.0 KB

	memory.png 97.0 KB View Download

I think we are mixing two issues here. The original issue and the micro benchmark issue (test cases in comment #22 and #17).


Regarding the latter, this seems to be working as expected.

These tests (in comment #22 and #17) do not create new DOM wrappers or JS objects so it is testing pure BlinkGC timing.

According to my observations, BlinkGC is trying to keep memory usage stable. But because BlinkGC tasks are scheduled, and there is a slight delay, you will see a slow increase in memory usage.

This is by design as we prioritize avoiding jank and mutator throughput over memory use unless under memory pressure. Under memory pressure, we will trigger additional GCs appropriately.


Regarding the former, 1GB sounds like you have a real bug (GC should have definitely triggered).

It's very hard to minimize a memory leak problem correctly so it would be best if I could run the actual JS/HTML source code.
But if you can't here are some data you could collect that would be very helpful.

1. After memory use reaches 1GB, open devtools, open Memory panel and take a heap snapshot. You can use the "Save" button in the sidebar to save it to a heapprof file and you can attach it to this bug.

2. After memory use reaches 1GB, open the Chrome task manager and note memory usage. Open devtools, open Memory panel and click on the trash can button in the sidebar. Note the memory usage again. Report the memory use before and after you clicked on the trash can.

i've let the memory_test.html run for ~3h.
the memory went to ~15 000Ko.

the 1GB problem is when i create/delete and modify DOM elements with my extensions.

with this small test file, i can't reach the 1GB...

"so it would be best if I could run the actual JS/HTML source code"
=> what do you mean ?

1. even if it only took up to 15MB, i took a snapshot (attached file)
2. i clicked the trash (attached file)

i'm sorry if i'm missing key informations for you. i'm trying my best to help you :/

ps : do you want me to take a snapshot of my extension ?

Deleted: memory.png 80.9 KB

	memory.png 80.9 KB View Download

Deleted: Heap-20170418T134253.heapsnapshot 2.9 MB

Heap-20170418T134253.heapsnapshot 2.9 MB Download

Sorry for the confusion.

We should forget about all the minimized test cases thus far. 15MB after 3 hours means there is no memory leak.

The real problem is your extension.
If you can send me the extension source code and I am able to reproduce the leak locally that would be the easiest for me to debug.
If not sending me the snapshots will be second best.

francois.deyme@ sent me the extension privately and I ran it for 12 hours. Memory use increased from 64MB to 80MB so I was not able to reproduce the problem. I observed that there is no significant leaks in JS, and the ~20MB increase is mostly malloc metadata_fragmentation. So this looks like working as expected.

francois has sent me a heap snapshot and because it contained many HTMLCollection objects we concluded that the issue is the same as  crbug.com/707544  .

Thank you keishi for investigating this to resolution.