FYI, my testing machine has 4GB memory

Thanks for the issue...

Unable to reproduce the issue on reported chrome 70.0.3538.102 using Windows 10. Attaching screenshot for reference.
Steps:
-----
1. Launched chrome
2. Opened given links and leave system for a while (about 4 hours)
As we have observed that chrome working normally 

@Reporter: Can you verify this issue with fresh profile that is not having any extensions and apps or reset all the flags. Let us know whether issue still persists also provide chrome crash id from chrome://crashes

Thanks..!

Deleted: 905539.mp4 1.9 MB

	905539.mp4 1.9 MB View Download

Similar symptoms as issue 642601.

FWIW memory usage of a tab with this svg doubled in 371207-371214 range:
https://chromium.googlesource.com/chromium/src/+log/56f66725..45f46be8?pretty=fuller
Could be due to r371208 "Enable Oilpan on ToT"

Not quite a definite confirmation, but I can report that on Mac Chrome 70.0.3538.102, when I opened  the first page (https://jsfiddle.net/g9h85qye/1/), the renderer memory consumption went up at a rate of about 7.5kbytes per second. This was observed with just one browser/tab open, and over a period of about 5 minutes. The climb was rather steady. And opening other tabs reset the memory back to a lower level.

This rate of increase (and general symptoms) definitely sound similar to https://bugs.chromium.org/p/chromium/issues/detail?id=642601, see c#11 on that bug.

pdr@, can you take a look?

My general feeling here is that this caused by GC-heuristics (growth rates etc.), but I haven't really been able to substantiate that.

I am trying to send crash report and it says that user has requested upload, but not uploaded yet.

I have a vague theory that the lazy sweep may not make (sufficient) progress.

I noticed that ThreadHeap::AdvanceLazySweep has a full millisecond of "slack" (moving the deadline back by that amount). I don't know how likely it is to have a idle task get alloted <= 1ms though. Triggering that (repeatedly) wouldn't be required to starve the sweep though I think.

If anything think they can reproduce this reliable [1], you may try to record a trace using chrome://tracing ("Manually select settings" -> clear all checkboxes and then select blink_gc in both columns). You'll likely need to record for quite some time (probably over a period of time where the memory usage of the page can be observed to grow by 100M[1] or so).

[1] There are various limits that seem to be relevant here, and I believe they are 1M and 32M, although it's difficult to observe this outside the tracing data.

I'll make a try next Monday, and I can reproduce that every time.

Sorry for the late reply.
Here is my exported tracing log from page load to page crash

Deleted: trace_log.json.gz 3.1 MB

trace_log.json.gz 3.1 MB Download

Thank you very much for the trace! (No worries about the delay.) Now let's hope we can make good use of it.

That "...from page load to page crash" could mean that the data we're interested in isn't actually in the trace though - sadly. This is why recommend to just trace for a significant increase in memory though, and not until the page crashes (at which point trace data is lost).

Yes, sadly that appears to be the case =/. (The relevant process is missing from the trace data.)

The behavior of BlinkGC.AllocatedObjectSizeSincePreviousGCKB is kind of interesting though (looks like it is underflowing), although I think that cause GCs to be scheduled more often (rather than not at all).

I'll try one more time

I changed test pc, but it didn't crash after a night. Guess it has larger memory.
Here is the new log

Deleted: trace_log.json.gz 3.6 MB

trace_log.json.gz 3.6 MB Download

Sadly I don't see the testcase process in that trace either (I expect there to be two "Renderer" processes present - one which is the chrome://tracing page, and one which is the actual testcase page). Do note that it's absolute _not_ required to to run the test until it crashes - just running it long enough for memory usage to go above what could be expected should be sufficient. Based on Mason's 7.5kb/s observation above, running for 3-4 hours ought to get us to the 100M limit. 2 hours could be entirely sufficient though. (If you do another trace, then sanity checking it so that includes data for the testcase page might be a good idea.)

I can't find it now, but there was a bug where we ran out of memory because font information on Mac was never ever released as the font was scaled. It seemed to be an OS issue, not something we could deal with ourselves.

It's not super helpful if I can't find it, I know.