@Benn thanks a bunch for reporting and for sharing the Crash ID’s. I’ve passed along to the appropriate folks internally and will let you know as soon as I have an update.
I’m technically skilled and don’t mind running a beta or custom build in a debugger. Let me know what else I can do to chase this down; it’s a full blocker for me. Exec level Brave-internal references available on request.
Nothing that I’ve changed in the last few months, but there’s no way to export a list and there’s… I don’t know, thousands of entries there.
Any extensions installed?
Yes, but this occurs with the --disable-extensions flag set, so those shouldn’t be a factor.
Any changes made on brave://settings/shields/filters
All of the pages under brave://settings immediately start the memory crash loop without any subsequent user interaction. I was able to load and scroll brave://flags without problem, for example, but the brave://settings/shields/filters page immediately starts the crash loop.
Do you know which version you updated from? Does it happen every time or intermittently?
I do not; however, I’m pretty regular on my updates, so at most it would have gotten to “yellow” on the hamburger menu button.
Reproducibility is super consistent. The default window is stable until right click interaction. The settings pages immediately start to crash once the page is loaded.
Can you try a fresh --user-data-dir
This does not crash, all pages seem to be working correctly.
The default filters are “EasyList Cookie” and “Fanboy’s Mobile Notifications”.
As part of debugging, I did the following steps:
Open the browser from the command line, the brave://settings/shields/filters page loads.
Add the next filter from the list.
Click the Update lists button.
Wait 5-10 seconds to see if anything happens.
Quit the browser using cmd-q
Restart the browser, filters page loads.
Attempt multiple right-clicks to see if there’s any change in memory pressure.
Continue at (2).
This did not produce any crashes. I then added the developer.mozilla.org custom filter. This also did not create any crashes.
It does appear likely to be related to https://issues.chromium.org/issues/369633257. The team will continue to dig in and investigate and see what fix can be implemented on our end if it’s not first addressed by the Chromium team.
I disagree with it being associated with 36933257 due to the reproduction simply by loading a brave://settings page. `257 relates to the height of the context menu and subsequent actions, and none of the related materials or issues mention OOM crashes.
@steeven - Enabling memory saver does stop the crashes. It was a very dramatic moment where I managed to click it on just before the process went unresponsive, but whatever that enables managed to garbage collect and now the app is stabilized at ~1.5GB which… given the number of tabs open on this profile, is not surprising.
However.
Starting a new browser using:
open -a 'Brave Browser.app' --args --incognito --no-experiments --disable-extensions --disable-gpu
does not crash, however the Brave process sits at ~1.6GB of used memory. This is a marked difference to when I run the browser with the custom user directory, where it utilizes only around 200MB. I would not expect the --incognito --disable-extensions instance to still consume 1.6 with a single window and no page loaded.