Brave freezes at start (macos 10.11, Renderer processes)

New download, latest Brave release for macos (both from and, also latest nigthly.

System details:
Hardware Overview:
  Model Name:	iMac
  Model Identifier:	iMac8,1
  Processor Name:	Intel Core 2 Duo
  Processor Speed:	2.66 GHz
  Number of Processors:	1
  Total Number of Cores:	2
  L2 Cache:	6 MB
  Memory:	4 GB
ATI Radeon HD 2600 Pro:
  Chipset Model:	ATI Radeon HD 2600 Pro
  Type:	GPU
  Bus:	PCIe
  PCIe Lane Width:	x16
  VRAM (Total):	256 MB
  Vendor:	ATI (0x1002)
  Device ID:	0x9583
  Revision ID:	0x0000
  ROM Revision:	113-B2250L-259
  EFI Driver Version:	01.00.259
  Display Type:	LCD
  Resolution:	1680 x 1050
  Pixel Depth:	32-Bit Color (ARGB8888)
  Main Display:	Yes
  Mirror:	Off
  Online:	Yes
  Built-In:	Yes
System Software Overview:
  System Version:	OS X 10.11.6 (15G22010)
  Kernel Version:	Darwin 15.6.0

Brave consistently freezes after a few seconds after start, while rendering the welcome page.

No extensions, no open tabs, as I could not yet use it once.

Process activity seem to point to the two processes “Brave Browser Helper (Renderer)” and “Brave Browser Helper (GPU)”.

I also tried running from the command line with --disable-gpu but got the same problem.

Hi @elder-n00b, Welcome to Community!
What is the exact text you used in terminal?
Can you try:

open -a “Brave” --args --disable-gpu

Hi @Aa-ron, thanks for your support.

I forgot to specify.
I used both open -a "Brave" --args --disable-gpu and /Applications/Brave\\ Browser --disable-gpu and then for good measure with all the “disable something gpu related” switches at once (most probably useless).

To my surprise, when I run with --disable-gpu I still see the “Brave Browser Helper (GPU)” process running, though the main process clearly has the said command line switch.

BUT, meanwhile I found out that if I leave it alone for a while the problem goes away by itself (only with gpu disabled though). Where “for a while” means half a minute or so in most cases, rarely less than that, sometimes “too long for my patience” in which case I kill and retry.

I’ve been too quick to conclude “it freezes just the same”.

I have also noticed that in both cases (with and without gpu switch) the processor usage is barely above 25% most of the time with spikes to over 80%. Not sure if that’s meaningful or just the process manager (htop) having trouble to average correctly due to the problem.
By intuition, but without any evidence, I’d suspect some kind of race condition.

Most affected parts of the system are the mouse (almost completely stuck, moves every second or two) and keyboard (sluggish at times but usable with some patience), all the rest is a bit slow and unresponsive but functioning and returns to normal after a while (with gpu disabled) or after killing the browser (with gpu enabled).

In conclusion, it appears to be usable on my system after all, just with gpu disabled and the inconvenience of the startup glitch. I’ll see if I manage to trigger the problem during use, I have noticed there are quite a few reports about those rendering processes, usually caused by some particular website. Let me know if you’d like me to do some tests.
I tried --enable-input since its description rang a bell, but no difference.
I tried --no-startup-window expecting the glitch only when opening a window, but no difference.
I see there are options about “deterministic behavior”, I’ll try those too when I have time.

Thanks again, best regards.

1.27.109 update: this problem is no more. Brave now works fine without --disable-gpu for me.
Not sure which version actually fixed it.

(Often the mouse pointer freezes or disappears, and when it happens everything still works with keyboard anyway, so it’s just command-q and restart. No more high CPU usage though.)

Thanks for still supporting this aging platform.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.