[Feature Request]: Provide an alternative way to launch chrome_crashpad_handler process

[haoxi911]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Problem Description

Right now, Electron's crashReporter module makes use of the chrome_crashpad_handler executable to capture crashes, and this executable was bundled as a part of the software.

Refer to issue #35944, I am running an Electron app from USB flash drive. When crashReporter is not enabled, unplug the drive will simply crash the app with a bus error (which is expected), but when crashReporter is enabled and chrome_crashpad_handler is spawned, unplug the drive will result a very high CPU usage, and certain Electron processes won't quit until reboot macOS.

I believe the root cause is chrome_crashpad_handler process, because it was located at the USB flash drive, so it was in unknown status when user unplugged the USB drive.

Proposed Solution

chrome_crashpad_handler is currently bundled in the Electron app, but it actually didn't depend on any Electron libraries or frameworks. I think it should be possible to copy this 1.1 MB file to appData folder and launch it from there. This way, it will be able to handle crash reporting in my use case, and also the Electron app will crash properly too.

Alternatives Considered

Provide some documents on how to manually launch this chrome_crashpad_handler process.

Additional Information

No response

[RaisinTen]

Are you able to repro this issue when you try this with a copy of chromium on your flash drive?

[haoxi911]

@RaisinTen Yes, it also exists in chromium, seems like a bug of chrome. I will report a bug to them, by the way, do you know if there is a way to launch chrome_crashpad_handler from a different location (other than the macOS app bundle), does it require modifying Electron source code? Thanks!

[RaisinTen]

Yes, it also exists in chromium, seems like a bug of chrome. I will report a bug to them

👍 that seems like the best way to tackle this problem. If chromium fixes this issue, electron too would benefit from it without us having to maintain code to launch that executable separately. I too would recommend you to create an issue in chromium's bug tracker and share the link here so that interested folks can follow the conversation there. We can then probably close this issue because there's not much we can practically do here to solve this problem.

do you know if there is a way to launch chrome_crashpad_handler from a different location (other than the macOS app bundle), does it require modifying Electron source code? Thanks!

I remember doing some research on how this executable is launched while preparing a performance boost for the launch process on macOS - #34609 and I found out that when you write this code in js:

crashReporter.start({ uploadToServer: false });

internally, Chromium launches the process on macOS with these arguments:

$ "Electron.app/Contents/Frameworks/Electron Framework.framework/Helpers/chrome_crashpad_handler" \
  --no-rate-limit \
  --monitor-self-annotation=ptype=crashpad-handler \
  --database="/Users/raisinten/Library/Application Support/Electron/Crashpad" \
  --annotation=_productName=Electron \
  --annotation=_version=15.5.2 \
  --annotation=prod=Electron \
  --annotation=ver=15.5.2 \
  --handshake-fd=40

Apart from what we see here, Chromium also passes some open fds into the launched process for IPC. This process is also launched in a new process group. You may take a look at https://source.chromium.org/chromium/chromium/src/+/main:third_party/crashpad/crashpad/util/posix/spawn_subprocess.cc;drc=9369044d135466db00f0abb5828f55821c0341d8;bpv=0;bpt=0 for the code behind all of this only for the posix platforms.

Given how complex the launch process is, I think maintaining the code to launch the executable directly from electron would be too complicated. Not sure if it's worth maintaining for the use case you mentioned because it sounds like it's very much an edge case.

[haoxi911]

Thank you @RaisinTen for the additional information. I report a bug in crashpad project here.

Close this issue for now.