search

getsentry / sentry-native

Sentry SDK for C, C++ and native applications.
MIT License
404 stars 170 forks source link

Implement sentry_handle_exception for macOS and Linux when using crashpad #1032

Closed david-antiteum closed 3 months ago

david-antiteum commented 3 months ago

Description

sentry_handle_exception only works for Windows with crashpad as the crashpad_backend_except is not implemented in macOS and Linux.

Extra

The Windows version of our app generates a crash report, including symbols and line numbers when calling sentry_handle_exception. Our macOS and Linux versions has no crash report at all due to the lack of implementation in crashpad_backend_except.

If using the default signal handlers, that is, let sentry do all the magic, in macOS and Linux the crash is reported with function names but no line numbers.

We are using the latest version of the SDK (0.7.8), curl and crashpad in macOS and Linux. Sentry is configure with this cmake line:

cmake -B build -DSENTRY_BACKEND=crashpad -DSENTRY_TRANSPORT=curl -DSENTRY_BUILD_TESTS=OFF -DSENTRY_BUILD_EXAMPLES=OFF -DCMAKE_BUILD_TYPE=Release -DCRASHPAD_ENABLE_STACKTRACE=ON -DSENTRY_TRANSPORT_COMPRESSION=ON

Thanks,

David

supervacuus commented 3 months ago

The Windows version of our app generates a crash report, including symbols and line numbers when calling sentry_handle_exception. Our macOS and Linux versions has no crash report at all due to the lack of implementation in crashpad_backend_except.

This is primarily an upstream issue since crashpad does not expose this functionality in the client interface on these platforms. Can you elaborate on why you need this functionality on Linux and macOS, or in what scenario you use Sentry? Do you have your own signal handlers installed? That could be a problem on macOS since the POSIX signal handlers only abstract over mach exception ports (which we use in crashpad and breakpad).

People use this feature on Windows mainly because they already have an elaborate SEH handling structure in place. But it would be interesting to understand the specific use case for Linux and macOS (especially the latter because your signal handler might not be firing before we handle the crash).

If using the default signal handlers, that is, let sentry do all the magic, in macOS and Linux the crash is reported with function names but no line numbers.

That issue is entirely different, probably not caused by client processing but by the uploaded debug information.

david-antiteum commented 3 months ago

People use this feature on Windows mainly because they already have an elaborate SEH handling structure in place. But it would be interesting to understand the specific use case for Linux and macOS (especially the latter because your signal handler might not be firing before we handle the crash).

OK, then the only missing part is to document the function as Windows only to avoid using it in unsupported platforms. Other than that, we are happy removing our signal handlers and using the Sentry ones.

If using the default signal handlers, that is, let sentry do all the magic, in macOS and Linux the crash is reported with function names but no line numbers.

That issue is entirely different, probably not caused by client processing but by the uploaded debug information.

I did some extra checks and seems that the problem was on the uploaded debug information. All good on this side.

supervacuus commented 3 months ago

OK, then the only missing part is to document the function as Windows only to avoid using it in unsupported platforms. Other than that, we are happy removing our signal handlers and using the Sentry ones.

I added platform support to the inline docs in #1036. Thanks for the reminder.

We can still leave this open to gather additional use cases.