On 6/25/24 00:23, Daniel Richard G. wrote:
On Thu, 2024 Jun 13 15:07-04:00, Andres Salomon wrote:Oops, sorry, I didn't see this email. Let me finish getting v126 out the door, and then circle back if the crash is still present there.I still see the problem with .114, alas. Tabs crash, sometimes the whole browser goes. I often leave my home PC with Chromium up in the morning, only to find it gone in the evening. While stopping on SIGILL has not caught the crashes leading to the "invalid opcode" syslog error, GDB does occasionally stop at a location indicating an out of memory condition. Here is a typical backtrace: (gdb) bt #0 0x00005572f6c3dc4d in partition_alloc::internal::OnNoMemoryInternal(unsigned long) () #1 0x00005572f6c3dc59 in partition_alloc::TerminateBecauseOutOfMemory(unsigned long) () #2 0x00005572f31a33cf in gpu::ClientSharedImageInterface::CreateSharedImage(gpu::SharedImageInfo const&) () #3 0x00005572f82ba0bd in cc::BitmapRasterBufferProvider::AcquireBufferForRaster(cc::ResourcePool::InUsePoolResource const&, unsigned long, unsigned long, bool, bool, bool) () #4 0x00005572f8225d8f in cc::TileManager::CreateRasterTask(cc::PrioritizedTile const&, cc::TargetColorParams const&, cc::TileManager::PrioritizedWorkToSchedule*) () #5 0x00005572f82237f4 in cc::TileManager::AssignGpuMemoryToTiles() () [...]
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.
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.
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.
I am running Chromium under strong memory pressure (3 GB RAM with hundreds of tabs open), but with a good amount of swap space (16 GB) of which not more than 2 GB is typically used. When loading a new page or the like, Chromium will sometimes spend a few seconds paging to swap, and at other times it will crash. Prior to this bug report, however, the crashes were very rare---swap access may have slowed things down, but the browser otherwise ran like a tank. Now, I often get crashes in the middle of typing text into a form window, which is especially aggravating as the text is not restored with the page. I have Memory Saver enabled. Are there any other settings you're aware of that I should experiment with? I already keep an eye on Chromium's Task Manager with the "Memory footprint" column in descending order, so if a site goes nuts with RAM usage, I can usually catch it.
Memory Saver is exactly what I was going to recommend as a workaround, before I saw the backtrace. ;)
OpenPGP_signature.asc
Description: OpenPGP digital signature
