getsentry
Non-root processes with sentry-native integrated unable to launch crashpad_handler on macOS
Description
I am currently working on integrating sentry-native into a macOS application that runs multiple root and non-root processes. The integration works well on root processes and crashes are reported to sentry but on non-root processes, crashpad_handler fails to launch even though execute permission for it is available to everyone. There’s not much information in sentry debug logs on why that’s happening. Any help here is really appreciated.
When does the problem happen
- [ ] During build
- [x] During run-time
- [ ] When capturing a hard crash
Environment
- OS: macOS 11.6.1
- Compiler: [e.g. MSVC 19]
- CMake version and config: 3.22.1 SENTRY_BUILD_SHARED_LIBS=OFF SENTRY_BUILD_RUNTIMESTATIC=ON SENTRY_BACKEND=crashpad
Steps To Reproduce
Sentry initialization is done in the following way (C++):
sentry_options_t *options = sentry_options_new();
sentry_options_set_dsn(options, "https://<masked>@<masked>.ingest.sentry.io/<masked>");
sentry_options_set_release(options, "[email protected]");
sentry_options_set_handler_path(options, "/Library/Application Support/TextCopy/TextCopy.app/Contents/Helpers/crashpad_handler");
sentry_options_set_debug(options, 1);
sentry_options_set_logger(options, sentry_logger, nullptr);
sentry_options_set_database_path(options, "/Library/Application Support/TextCopy");
sentry_init(options);
Log output
2022-04-29 00:53:10.125 PST d: [clipboard_01_01] Sentry log - using database path "/Library/Application Support/TextCopy"
2022-04-29 00:53:10.127 PST d: [clipboard_01_01] Sentry log - starting transport
2022-04-29 00:53:10.128 PST d: [clipboard_01_01] Sentry log - starting background worker thread
2022-04-29 00:53:10.128 PST d: [clipboard_01_01] Sentry log - starting backend
2022-04-29 00:53:10.129 PST d: [clipboard_01_01] Sentry log - starting crashpad backend with handler "/Library/Application Support/TextCopy/TextCopy.app/Contents/Helpers/crashpad_handler"
2022-04-29 00:53:10.131 PST d: [clipboard_01_01] Sentry log - using minidump url "https://o173976.ingest.sentry.io:443/api/<masked>/minidump/?sentry_client=sentry.native/0.4.13&sentry_key=<masked>"
2022-04-29 00:53:10.229 PST d: [clipboard_01_01] Sentry log - failed to start crashpad client handler
2022-04-29 00:53:10.229 PST d: [clipboard_01_01] Sentry log - failed to initialize backend
2022-04-29 00:53:10.229 PST d: [clipboard_01_01] Sentry log - `sentry_init` failed
2022-04-29 00:53:10.229 PST d: [clipboard_01_01] Sentry log - shutting down transport
2022-04-29 00:53:10.229 PST d: [clipboard_01_01] Sentry log - shutting down background worker thread
2022-04-29 00:53:10.229 PST d: [clipboard_01_01] Sentry log - submitting task to background worker thread
Hi!
There shouldn’t be any problems with normal root vs non-root users.
Crashpad internally relies on mach exception ports to monitor an exception from the outside. The crashpad subprocess will do its own stderr logging for any failures related to setting that up.
We have received reports previously that these mach exception ports are not available for specially sandboxed applications.
As an alternative, you might want to try the breakpad backend, which uses standard unix signals and should thus have less restrictions.
Closing due to inactivity. Feel free to re-open if you run into this issue again.
