GitLab

On Windows 32 bit, Chrome reserves a significant chunk of address space
when a renderer starts, to make large contiguous allocations easier to
fulfill. Once a memory allocation fails, the reservation is released,
then the allocation retried. This only works if *all* the allocators are
aware that this mechanism exists. Unfortunately, malloc() in particular
is not aware of this, meaning that if a large malloc() allocation bumps
into this issue first, then the renderer crashes.

As this seems to be the case, from looking at crash reports (see linked
bugs for instance), malloc() should be made aware of this.

On Windows, allocations use the allocator shim, and call the "new
handler", which should return a non-0 value when it is able to free some
memory. Currently, this new handler always crashes the process. We
update it to drop the reservation if it exists, and crash otherwise.

This should hopefully solve some crashes we are seeing, especially some
related to video decoding, frequently allocating buffers of ~1MB, which
is large enough to trigger the issue, as seen in crash reports.

This is not a complete fix, since it does not address all allocators in
a process, e.g. allocations by DLLs loaded by the process will not pass
through the new-handler hook. We do not (yet) see these as a significant
cause of crashes in practice though.

Note that this CL also adds the reservation dropping behavior to Linux
builds as well. There is no address space reservation in actual Chrome
builds on Linux, but adding this allows to exercise the tests on Linux
builders as well, which is preferable.

Bug: 1028086, 1023804
Change-Id: I12ad4aa0c7bf518c3cf1df93c966e8631a69c280
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1989747Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Benoit L <lizeb@chromium.org>
Reviewed-by: Wez <wez@chromium.org>
Commit-Queue: Benoit L <lizeb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#730994}