to mem sheriff for investigation

The crash in [1] is for a system OOM while generating a heap snapshot. This usually happens when taking a snapshot for a "larger" webpage. IIUC, this is a known issue where malloc is limited to 2GB for consecutive memory regions and this limit is sometimes hit during taking a heap snapshot.

This would probably require re-designing the data structures to work around that security limit. Not sure that's worth it.

Re-assign to alph@, but I guess this is sadly WAI because of security limits.

[1] https://crash.corp.google.com/browse?q=reportid=%27a0a54e22fe70ab6c%27

It crashes without taking a heap snapshot. I probably put the wrong report ID there. I'll repro now and update with a proper report ID.

There were two crash reports generated:
fe9f3803af300a9f
1623d4556f95d847

Sending back to mem sheriff as per comments 4&5.

Setting the component back for visibility.

Crashed on Chrome 72.0.3626.14.

Did not crash on 60.2.0esr (64-bit).

I debugged this together with Ulan on 72.0.3626.14.

We can see a steady increase of live memory that's accumulated via a memory leak on the webpage itself.

Some code seems to add properties of the form "closure_lm_<number>" to the global window object. Each of these closures retains a native context in v8 which can easily be on the order of MB.

The way to debug this:
1. Open DevTools
2. Take heap snapshot
3. Search for "Detached": This will highlight DOM elements that are not attached to the renderer tree.
4. Check the retaining path of "Detached Window" or "Detached HTMLDocument".
5. These retaining paths go through a property on the global window object.

One can verify this by just typing "window." into the console. The window object will have all those properties that retain native contexts (windows and documents).

At this point it is a memory leak on the webpage for us. Other browsers may (or may not) kill any detached documents at some point which would violate the spec though.

Thanks for looking into this!