v8 fails to OOM-crash background tabs at 2GB memory usage |
|||||||
Issue descriptionContext: There's a recent large spike in crashes going into M64 stable. See https://docs.google.com/document/d/19Ubr6GlTDUQzyujFhQhfuNr3bw14m_SGHLwlXeSBpi4/edit?ts=5a819383# Around the time of this roll out, I noticed a large spike in renderer crashes on my personal machine. Coincidence? I started to investigate. Repro steps: 1) Open a tab to http://poe.trade/search/hichusigakugon. 2) Wait. Watch memory usage go up. Okay. In and of itself, not super exciting. Just another website that leaks memory. But I have two observations: 1) Open 10 tabs [9 in the background] and repeat this procedure. The foreground tab will OOM [great!] but all 9 background tabs will stay at 2GB private memory usage. That's really weird! This implies that for some reason, we're not properly OOMing background tabs that *should* be OOMing. This in turn greatly reduces available memory on the machine. 2) When trying to use Devtools to take heap snapshots to investigate this problem, the snapshot size doesn't match the actual private memory usage. Summing across the retained sizes does the right thing, but all the percentages are wrong. (1) seems quite concerning from a performance perspective. (2) seems like it might be a devtools bug. I've attached a screenshot that demonstrates both (1) and (2).
,
Mar 7 2018
Attaching a memory-infra trace that shows a bunch of background tabs happily sitting away at just over 2GB v8 memory usage.
,
Mar 8 2018
regarding (2) Is it 2GB private memory or 2GB of v8 heap memory? If latter, are there worker threads? The heap snapshot is for a single isolate only (main by default). There's a combobox on the profilers panel to select worker isolates.
,
Mar 8 2018
> Is it 2GB private memory or 2GB of v8 heap memory? Both. But trying to take a heap snapshot of a 2GB heap just blows up the renderer. In the screenshot, I've taken a heap snapshot of a 600MB renderer. I see, so the percentages are just not meaningful in this case? Sounds good. Thanks for the response.
,
Mar 8 2018
The snapshot is per isolate. The percentages are relative to isolate's used v8 heap size. I'm trying to repro to take a look...
,
Mar 8 2018
Unable to repro (2). There are no workers on the page, just the main isolate. In my experiments the snapshot size always matched Task Manager's live JavaScript memory column. Tried for v8 heap sizes up to 500MB.
,
Mar 8 2018
Hm. I was also not able to repro (2). I'll open a new bug if I can come up with a clean repro for that.
,
Mar 15 2018
titzer@ could Wasm-off-v8-heap the reasons here?
,
Mar 15 2018
If this happens on M64, then wasm-jit-to-native cannot be the reason. It was only enabled in M65.
,
May 22 2018
I tried opening to this page and it does not appear to be still leaking memory. Does this behavior still reproduce with another leaking webpage?
,
Jul 20
Just coming back to clean this out. Since it did not repro in c8 or c10, it may already be fixed. Please reopen or file another issue if it reoccurs. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by erikc...@chromium.org
, Mar 7 2018