MacOS Browser OOM Crash on Right Click

Description of the issue:

On 02.03.2025, possibly after installing an update, the Brave browser started OOM closing when right clicking on the browser window.

This was not occurring until very recently.

How can this issue be reproduced?

Open the browser on MacOS:

open -a 'Brave Browser.app' --args --incognito --no-experiments --disable-extensions --disable-gpu

Right click on the body of the opened window.

Observe the “application unresponsive” spinner and the memory usage, in Activity Monitor, shoot to maximum before the process is killed.

Expected result:

No crash.

Brave Version( check About Brave):

Version 1.74.51 Chromium: 132.0.6834.160 (Official Build) (arm64)

Additional Information:

Crash id’s from today:
6e391700-eb92-500d-0000-000000000000
69391700-eb92-500d-0000-000000000000
6b391700-eb92-500d-0000-000000000000
72391700-eb92-500d-0000-000000000000
63391700-eb92-500d-0000-000000000000

Downloaded a new installer today and installed over the existing installation to no effect.

@Mattches

OP has crash IDs.

@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.

Thanks a bunch @Benn, a few initial follow up questions:

Do you have:

  • Anything enabled on brave://flags,
  • Any extensions installed?
  • Any changes made on brave://settings/shields/filters

Do you know which version you updated from? Does it happen every time or intermittently?

Can you try a fresh --user-data-dir, wondering if the file could be corrupted.

Thanks in advance @Benn. Will likely have additional follow up q’s shortly.

  • Anything enabled on brave://flags,

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:

  1. Open the browser from the command line, the brave://settings/shields/filters page loads.
  2. Add the next filter from the list.
  3. Click the Update lists button.
  4. Wait 5-10 seconds to see if anything happens.
  5. Quit the browser using cmd-q
  6. Restart the browser, filters page loads.
  7. Attempt multiple right-clicks to see if there’s any change in memory pressure.
  8. 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.

Wondering if this is the same issue as this one here:

@Benn thanks for taking the time and trouble to go through those steps. Have reported back to the team, will be in touch as I know more.

It does appear that there are others experiencing a similar issue, and it’s been tied to an upstream Chromium bug https://issues.chromium.org/issues/369633257 as @Mattches mentions.

The team is Investigating.

@Benn does toggling on the memory saver feature as part of brave://settings/system make any difference for you?

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.

Thanks @Benn, I’ve sent this latest report to the team. Glad to know enabling the memory saver was helpful.