All right, I've figured out what was going on, as well as a fix.
Going back to that backtrace I posted some months ago, which I've seen
crop up again and again:
#0 0x00... in partition_alloc::internal::OnNoMemoryInternal(unsigned long)
()
#1 0x00... in partition_alloc::TerminateBecauseOutOfMemory(unsigned long)
()
#2 0x00... in
gpu::ClientSharedImageInterface::CreateSharedImage(gpu::SharedImageInfo const&)
()
I took a closer look at the CreateSharedImage() method:
https://source.chromium.org/chromium/chromium/src/+/refs/tags/132.0.6834.83:gpu/ipc/client/client_shared_image_interface.cc;l=206
So the method is not allocating main memory via the usual
partition_allocator pathway; it calls TerminateBecauseOutOfMemory() if
an allocation of *shared memory* fails. That allocation goes down to
PlatformSharedMemoryRegion::Create(), POSIX edition:
https://source.chromium.org/chromium/chromium/src/+/refs/tags/132.0.6834.83:base/memory/platform_shared_memory_region_posix.cc;l=169
And the thing to note is that it is creating a temp file (well, a file
descriptor to a deleted temp file) in /dev/shm.
As noted previously, the laptop where this issue occurs has only 3 GB of
RAM, and that means /dev/shm isn't all that big:
$ df -m /dev/shm
Filesystem 1M-blocks Used Available Use% Mounted on
tmpfs 1482 0 1482 0% /dev/shm
(The size of the /dev/shm tmpfs seems to be pretty consistently 50% that
of main memory.)
Chromium provides an option, --disable-dev-shm-usage, that will cause it
to use $TMPDIR or /tmp for this shared-memory allocation instead of
/dev/shm. I added that option in an /etc/chromium.d/ file, and have not
encountered a single crash since.
So the fix is to pass this option when /dev/shm isn't big enough. I'll
submit a merge request with my implementation of this.
--Daniel
