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

Issue 655945 link

Starred by 1 user

Issue metadata

Status: Archived
Owner: ----
Closed: Jan 10
Cc:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Feature



Sign in to add a comment

Feature req: On OOM report JS stack back to aw snap page + OOM reports

Project Member Reported by primiano@chromium.org, Oct 14 2016

Issue description

Taking inspiration from pdr@ proposal from the internal thread "Debugging Aww Snap! Errors".

Background
----------
OOM in the renderer happen. The root causes can be: (i) chrome code in the renderer process bloating memory. (ii) the actual JS of the content bloating memory (If the page requests 2 GB of arrays there is very little v8 can do other than try to serve them).

(ii) itself can happen in the form of:
 A) the OS hard-killing the renderer process. This is in the case of exhausting physical memory (or reaching some ulimit / cgroup limit) and the OS refusing to handle a page fault. 
 B) Chrome suiciding because a malloc / mmap failed. This is often the case when we exhaust address space (mostly on 32 bit) or when we hit the OS virtual/physical overcommit ratio.

This bug is purely about B. There is very little we can do in A, as the renderer is not given to handle that fault. At least on Android that's a SIGKILL, which is not trappable.

Today, when B happens in V8 that is handled by reportOOMErrorInMainThread, which just DVLOGs something and suicides.

Proposal
--------
What if, instead, if it did detect that we did OOM while running JS it did try to:
- unmap some chunk of memory (whatever space not strictly needed for the StackFrameIterator, if any)
- unwind the JS stack
- IPC the stack dump to the browser
- suicide
And just IMMEDIATE_CRASH if it re-enters and re-OOMs while trying to handle the OOM (which means the umap at step 1 wasn't enough)

The browser could attach some "ADVANCED" ui to the aw snap page (or even have a more graceful page) which shows the JS stacktrace.
It could be useful for the cases where OOM is really due to the content leaking. I know that the stack in the case of OOM is not necessarily what caused the bloat, but maybe in a lot of cases it can help (if you think at chrome crashes, in quite some cases the culprit is in the stack).

Proposal on steroids
--------------------
Maybe this could be taken one step further and we have something like the HTTP security reports: report OOM stacks back to the website if the website opted in with some similar http headers.
 
Labels: -Type-Bug Type-Feature
Cc: hablich@chromium.org hpayer@chromium.org
+hablich, +hpayer

Comment 3 by jochen@chromium.org, Oct 26 2016

Cc: -eisinger@chromium.org jochen@chromium.org
Status: Archived (was: Untriaged)
Archiving P3s older than 1 year with no owner or component.

Sign in to add a comment