Ungoogled-chromium: crashpad_handler running at 90% CPU on Mac OS

[stfnhh]

After installing version 62 crashpad_handler is using up to 56% cpu on two cores, causing a system wide slowdown and my fans sound like a jumbo jet taking off. Let me know what I can do to help debug.

[tectiv3]

yep, I have it too. Killing it won't get it started again.

[stolendata]

Can confirm same problem when running on 10.11.6. Also noticed that the mds/mdworker metadata daemons for Spotlight were running haywire during this - probably indicating high disk output by the crashpad_handler processes - though I couldn't locate exactly what or where.

[Eloston]

63 is ready for testing. If this is still a problem, please report here.

[tectiv3]

Still there...

[Eloston]

Could you guys report what arguments are passed into crashpad_handler? What's the parent process? Is there an instance of run_with_crashpad anywhere?

[Eloston]

For reference, here's documentation for Crashpad: https://chromium.googlesource.com/crashpad/crashpad

[tectiv3]

user           77256  50.4  0.0  2437952   6168   ??  R     1:09AM   0:16.72 /Applications/Chromium.app/Contents/Versions/63.0.3239.132/Chromium Framework.framework/Helpers/crashpad_handler --no-periodic-tasks --monitor-self-annotation=ptype=crashpad-handler --database=/Users/user/Library/Application Support/Chromium/Crashpad --annotation=plat=OS X --annotation=prod=Chromium_Mac --annotation=ver=63.0.3239.132 --handshake-fd=4
user           77254  50.3  0.0  2457936   6308   ??  S     1:09AM   0:16.68 /Applications/Chromium.app/Contents/Versions/63.0.3239.132/Chromium Framework.framework/Helpers/crashpad_handler --monitor-self --monitor-self-annotation=ptype=crashpad-handler --database=/Users/user/Library/Application Support/Chromium/Crashpad --metrics-dir=/Users/user/Library/Application Support/Chromium --annotation=plat=OS X --annotation=prod=Chromium_Mac --annotation=ver=63.0.3239.132 --handshake-fd=9

Quitting those two processes won't bring them back (until chromium restart)
no run_with_crashpad spotted.

[Eloston]

@tectiv3 Do those processes have any parents or children that should be noted?

[tectiv3]

No children, parent is launchd, process group - Chromium.
Actually I was wrong, sending them SIGTERM will quit that stuck process and re-spawn a normal one:

user           77256   0.0  0.0  2438976   5384   ??  S     1:09AM   0:24.01 /Applications/Chromium.app/Contents/Versions/63.0.3239.132/Chromium Framework.framework/Helpers/crashpad_handler --no-periodic-tasks --monitor-self-annotation=ptype=crashpad-handler --database=/Users/user/Library/Application Support/Chromium/Crashpad --annotation=plat=OS X --annotation=prod=Chromium_Mac --annotation=ver=63.0.3239.132 --handshake-fd=4
user           77254   0.0  0.0  2457936   5496   ??  S     1:09AM   0:27.29 /Applications/Chromium.app/Contents/Versions/63.0.3239.132/Chromium Framework.framework/Helpers/crashpad_handler --monitor-self --monitor-self-annotation=ptype=crashpad-handler --database=/Users/user/Library/Application Support/Chromium/Crashpad --metrics-dir=/Users/user/Library/Application Support/Chromium --annotation=plat=OS X --annotation=prod=Chromium_Mac --annotation=ver=63.0.3239.132 --handshake-fd=9

[tectiv3]

Even better, sending them SIGTERM will just stop them using all CPU without restarting a process :/
Notice the same PID.
BTW after that quitting Chromium won't quit those two crashpad_handler processes. They have to be killed with SIGKILL.

[Eloston]

Hmm, well it seems none of the debugging options will be easy. Either we look through the code and patches, do a debug build/make modifications and debug at runtime, or both. I haven't worked with this area of Chromium before so I have no ideas.

[tectiv3]

Can we just disable it all-together?

[Eloston]

I was thinking about it, but I'm not sure how integrated the crashpad client (or the whole client module) is in Chromium. It may not be that straight-forward to remove. That can cause some more unintended side-effects.

It's an option we can take if we aren't able to fix crashpad_handler.

[Eloston]

Could you guys check to see if dbf4c0e58765b77b9e3569facd3eee589084b0ee changes anything? I doubt this is the cause, but I'd like to be certain.

[tectiv3]

OK, I will try it a bit later.

[kelvinq]

This happens on my machine too.

[stfnhh]

@Eloston any progress on this bug?

[stolendata]

I have nothing to add as dbf4c0e unfortunately refuses to build on my El Capital setup. I'm too swamped with work right now to get enough time to dig into it. @tectiv3, have perhaps you gotten around to building it?

[Eloston]

@stfnhrrs I just finished up major rework to the build system. I'm starting development on 64, so we can test again once I merge everything in.

[tectiv3]

@stolendata nope, it refuses to build for me too.

[sebvargo]

I experienced this problem as well. I left my computer overnight to upload videos to a cloud using Google Chrome and my fans started to sound very loud to the point that they woke me up.

After checking Activity Monitor, crashpad_handler was taking 199% CPU. Please see image below.

How can this be troubleshooted?

Thank you

[arutr]

@sebvargo That process shouldn't be active. Maybe the patch is no longer valid

[Eloston]

@sebvargo If you experience this with 72.0.3626.109-1, please create a new issue. Thanks.

[KimPG]

yep, I have it too. Killing it won't get it started again.

thanks a lot.I thought my MacBook would bomb with the problem.

[simmerlee]

apple is shit! mac is shit! crap!

[datacode384]

any solution ? crashpad_han running at 192 % cpu for me as well

[kramred]

@krishnadamarla, are you using the current version? Try updating first if you're still on an older version.

If the issue persists try a new profile:
∙ make sure (ungoogled) Chromium is not running
∙ make a backup of your profile folder (should be ~/Library/Application Support/Chromium/Default ) and then delete it, or simply rename it
∙ restart (ungoogled) Chromium

If this resolved it start migrating your settings/bookmarks etc. (always with Chromium not running)

If it still persists, please open a new issue in the macOS repo.

Remember to always have a backup first...

[JaZZim]

End the process with the command:
kill -KILL {PID}

[aybarsyildiz]

after ending the kernel_task from activity monitor, it fixed this situation for me

[protoboolean]

This happened to me today, macOS Big Sur (11.1). The open files of this process suggest Visual Studio Code uses it.

/private/var/folders/gc/📁/T/AppTranslocation/📁/d/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Helpers/chrome_crashpad_handler
/Users/🏠/Library/Application Support/Code/CrashpadMetrics-active.pma
/Users/🏠/Library/Application Support/Code/CrashpadMetrics-active.pma

I decided to reboot and, so far, it's behaving. Note: I don't have Chromium or Chrome installed. HTH

[exgs]

This happened to me too. mac Big Sur (11.1). Fanning is running crazy. So Force quit "Chrome crashpad_handler" in Activity Monitor

[Eloston]

I've been hearing a number of applications breaking under Big Sur, so it could be a Chromium issue. Please open an issue on ungoogled-chromium-macos if this is a problem for you instead of posting on this old issue.