Debugging memory / allocation issues

[chenw...@google.com]

Hello Chromium developers -

I'm trying to debug issues with an web app (Google-internal) where we're consistently encountering issues from a small subset of our users:

We're receiving JS errors from our logging infrastructure such as:

1. "RangeError: Failed to execute 'getImageData' on 'CanvasRenderingContext2D': Out of memory at ImageData creation"

2. "RangeError: Array buffer allocation failed"

1.  Looks like it could be coming from somewhere in: https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/canvas/canvas2d/base_rendering_context_2d.cc?l=1581&rcl=dfae77a3bc63d90731092f4f69598ce26b2272a1

2. Seems to be originating from https://cs.chromium.org/chromium/src/v8/src/builtins/builtins-arraybuffer.cc?l=53&rcl=94a9e6155ebda4918522a702528c6e54a0018a00 and my guess is that V8 is unable to a new array buffer because there's a lack of memory.

I'm not familiar enough with V8 or Blink to meaningfully interpe

My questions are:

1. Are these caused by a lack of memory?

2. In general, how does Chrome cap memory usage? I know there's an OOM error and I was wondering what's Chrome's heuristics around max memory usage and if it's per-tab, per-frame, per-origin, etc.

3. Is there any best practices for collecting RUM on memory usage? I know there's window.performance.memory but it says "Do not use. Proprietary. Chrome only" on https://webplatform.github.io/docs/apis/timing/properties/memory/.

Thanks for your help.

Will

[Daniel Bratell]

Adding memory-dev to cc (and I suspect the google adress will bounce me).

Since you have no other answer, I will add some general information about
Chromium's memory management. Memory is mostly managed one renderer
process at a time, and if you share a renderer process with other
apps/sites/data you will also have to share the memory.

There are internal memory limits, mostly of the "2GB per process" kind,
coming from the use of custom allocators with those limits. While the
limits are sometimes hit, moving them has not yet been a goal as far as I
know.

A relatively common problem with large images and buffers is that the
memory is too fragmented to be used. If your crashing users crash after
some time, that might be the cause.

Another problem with garbage collected large buffers is that the garbage
collect doesn't trigger fast enough.

There is no cross platform memory metrics. Every browser is different
enough to make metrics impossible to compare between browser which has
stopped cross platform solution. If you have to use chromium only metrics
for debugging, then go ahead.

If you want to debug the browser itself, then
https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/
is the tool for that.

I hope this can bring you closer to figuring out what is going on.
Memory/oom debugging can be tricky.

/Daniel

> --
> --
> Chromium Developers mailing list: chromi...@chromium.org
>
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
>
> ---
> You received this message because you are subscribed to the Google
> Groups "Chromium-dev" group.
>
> To unsubscribe from this group and stop receiving emails from it, send
> an email to chromium-dev>+unsub...@chromium.org.
>
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/chromium->dev/f5e0cd61-d07a-49ce-ae1f-27b4fd8b8e24%40chromium.org.
>



--
/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[Will Chen]

Thanks for the reply. 

Just to clarify, is a single render process = 1 tab or 1 origin? IIRC, with site isolation, a single render process contains multiple frames (across potentially multiple tabs?) for the same origin.

The reason why I'm asking, is because I suspect our iframing strategy (we have multiple hidden iframes from the same origin) may be causing us to hit this 2GB limit.

- Will

[Daniel Bratell]

Frames that can call into each other in JavaScript have to share the same renderer process so yes, it's quite possible that many of your iframes live in the same renderer process. The task manager in the desktop version of Chromium can show you what's in each renderer if that task manager is available to you.

Before site isolation (OOPIF) all iframes lived in the same process as the root document. Now they don't but I think (this seems to be tuned and change) that to avoid an excessive number of processes and an excessive amount of overhead iframes from the same site but with different root documents may share the same process. Looking in the task manager of my local many-tab opera I see some processes with a lot of "Google" iframes (ads, stats?) which supports that.

/Daniel

--
You received this message because you are subscribed to the Google Groups "memory-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to memory-dev+...@chromium.org.
To post to this group, send email to memor...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/memory-dev/CAAb7rV7SeR-T_spKhRsKTiZthuCXGbYasmWyRuymLRuJh%3DyG3g%40mail.gmail.com.

[Petter Nilsen]

On Wed, 08 May 2019 18:41:27 +0200, Daniel Bratell <bra...@opera.com>
wrote:

>> We're receiving JS errors from our logging infrastructure such as:
>> 1. "RangeError: Failed to execute 'getImageData' on
>> 'CanvasRenderingContext2D': Out of memory at >ImageData creation"
>> 2. "RangeError: Array buffer allocation failed"

You might be hitting on
https://bugs.chromium.org/p/chromium/issues/detail?id=242215, there
appears to be a memory leak in getImageData.

--
Petter Nilsen, Senior Developer, Vivaldi Technologies AS