Breakpad Crash Handler Not Sending Crash Errors

[ricolaw-clarius]

Hi currently I have set up Sentry for my project along with custom transports via setting sentry_tranport_new() which works properly when creating events with sentry_capture_event(). However it does not seem to send anything when I crash the program. From what I read in another issue here Crashpad has it's own transport method, is similar for Breakpad? If so is there a way to use our own transport code, or is that for in proc error handling only?

Thanks

[Swatinem]

The breakpad handler (and in-proc) will write the event directly to disk in the case of a hard crash. On restart, the event will be loaded from disk and passed to the configured transport.

[tian-yu-ocado]

Hi @Swatinem, i am wondering is there a way to send out the crash event before the program completely shuts down, instead of having to wait until the next time the program restarts? That sort of "defeat" the purpose of crash monitoring (you dont know a crash happened until the crash has been recovered)?

[supervacuus]

Your question is answered partially here: #786. The other part is that running an HTTP client inside an already hard-crashed application is rarely a good idea (even if technically possible).

On Linux specifically we are very limited in what we can do within a signal-handler. There are ways around this, but they haven't been attempted yet, because users can use our crashpad backend in that case (which uses a separate process to send the crash-event "live").

Most users gather crash-events over a wide range of deployed target systems in an aggregate fashion where it isn't necessary to be informed of a singular "live" crash event, but rather get an overview of how many of their users or client-configurations are affected by issues in a particular version of their deployables. So yes, with our breakpad- and inproc-backends "monitoring" of a particular deplyoment is not supported yet, although you will be able to retrieve a lot of context that led to the crash after the fact.

[ricolaw-clarius]

Is there a method you'd recommend for debugging whether the crash is being saved and whether the event is read again after the program restarts? I am assuming this second step will still use the custom transport.

[Swatinem]

I am assuming this second step will still use the custom transport.

Yes thats true.

You can take a look at the directory that you configured via:

sentry-native/include/sentry.h

Lines 960 to 990 in 0e94e49

	/**
	* Sets the path to the Sentry Database Directory.
	*
	* Sentry will use this path to persist user consent, sessions, and other
	* artifacts in case of a crash. This will also be used by the crashpad backend
	* if it is configured.
	*
	* The directory is used for "cached" data, which needs to persist across
	* application restarts to ensure proper flagging of release-health sessions,
	* but might otherwise be safely purged regularly.
	*
	* It is roughly equivalent to the type of `AppData/Local` on Windows and
	* `XDG_CACHE_HOME` on Linux, and equivalent runtime directories on other
	* platforms.
	*
	* It is recommended that users set an explicit absolute path, depending
	* on their apps runtime directory. The path will be created if it does not
	* exist, and will be resolved to an absolute path inside of `sentry_init`. The
	* directory should not be shared with other application data/configuration, as
	* sentry-native will enumerate and possibly delete files in that directory. An
	* example might be `$XDG_CACHE_HOME/your-app/sentry`
	*
	* If no explicit path it set, sentry-native will default to `.sentry-native` in
	* the current working directory, with no specific platform-specific handling.
	*
	* `path` is assumed to be in platform-specific filesystem path encoding.
	* API Users on windows are encouraged to use
	* `sentry_options_set_database_pathw` instead.
	*/
	SENTRY_API void sentry_options_set_database_path(
	sentry_options_t *opts, const char *path);