On Tue, 2024 Jun 25 14:26-04:00, Andres Salomon wrote: > > That backtrace makes sense; it's running OnNoMemoryInternal(), which > calls PA_IMMEDIATE_CRASH(), which generates an invalid opcode customized > for various architectures (ironically to provide a better backtrace > compared to calling abort() or something). > > It's a maze of #ifdefs, but it appears that on x86, it calls 'int3' > (which should emit SIGTRAP), followed by 'ud2' (undefined instruction). > You can probably get gdb to catch the SIGTRAP, but that honestly doesn't > help diagnose _why_ you're running out of memory.
Even though GDB didn't catch all the crashes, the circumstantial evidence of all of them going through OnNoMemoryInternal() is pretty strong. > I don't know how chromium handles GPU memory, but I wonder if the issue > is that GPU memory can't be swapped, and the partition allocator is just > grabbing way too much of it and wasting it? > > Try changing the following in > base/allocator/partition_allocator/src/partition_alloc/partition_alloc_constants.h > > , around line 144: > > constexpr size_t kMaxPartitionPagesPerRegularSlotSpan = 4; > > Change that value to be 3 or 2, and see if that helps. Keep in mind by > doing this you're trading memory for speed, so memory allocations might > be a bit slower. Yep, I put the build-reproducibility issue aside, and built with this set to 2. (I also set use_thin_lto=true, in hopes of getting a small speed boost.) The difference is pretty stark, feels like an order of magnitude fewer crashes compared to the stock build. I can do the kind of aggressive browsing that previously took it down, and it keeps going. I've counted only two crashes so far, in quick succession on the same complex Web page, across multiple hours of use. I tried putting together a quick-and-dirty patch that allows setting the value via an environment variable, but the value gets used in a lot of other constexpr's, as well as array sizes, etc. (it's practically a #define). Do you think a patch is ultimately the way to go, or would the upstream be receptive to improving [configurability of] low-memory behavior? > If that doesn't help, it could also be that the CreateSharedImage() code > for your specific graphics driver is leaking memory or something. If you > can try a different graphics driver/stack, that could also point to a > specific bug in the driver. It seemed like --use-gl=egl was somewhat more crash-y with the stock build, so I reverted that tweak a while back. I need to try it again, it might be fine now. > Memory Saver is exactly what I was going to recommend as a workaround, > before I saw the backtrace. ;) Overall, Chromium does very well with what I'm throwing at it. The crashes feel like a minor issue that can be fixed easily, not some hard architectural problem requiring a refactor. --Daniel
