feat: invoke on_crash when handling a crash

[espkk]

for #592

not sure if it's possible to add some UT for that

[Swatinem]

This looks very good!

Supporting the uctx on breakpad linux / macos would be nice.

It would also be interesting to highlight the difference between this and before_send.
Currently, before_send in some cases gets an empty event that is being discarded, just to satisfy its function signature, and to give users the ability to return a null event, in which case no crash report is being sent.
We should do something similar, maybe add a boolean return value to the hook, to indicate if we would capture the crash, or ignore it.

Another interesting aspect would be to maybe phase out before_send as currently used in the crash handler, meaning:

1. If on_crash is defined, before_send is only invoked for normal events, but not for crashes.
2. If on_crash is not defined, we need to maintain the current before_send behavior for backwards compatibility.

This would also give users the possibility to opt into the new behavior just by providing an empty noop on_crash handler.

[espkk]

Currently, before_send in some cases gets an empty event that is being discarded, just to satisfy its function signature, and to give users the ability to return a null event, in which case no crash report is being sent.

As far as I can see, in case of crash report return value is ignored, so there is no option to discard the event:

sentry-native/src/backends/sentry_backend_crashpad.cpp

Lines 140 to 146 in b091b76

	sentry_value_t event = sentry_value_new_event();
	if (options->before_send_func) {
	SENTRY_TRACE("invoking `before_send` hook");
	event = options->before_send_func(
	event, NULL, options->before_send_data);
	}
	sentry_value_decref(event);

I'm not sure if it make sense to change this behaviour since you want to preserve backwards compatibility.
But it makes sense to have such for on_crash

UPD:
I made kind of, but not sure about sentry__transport_dump_queue...
And still no idea about breakpad data on non-windows systems

[Swatinem]

there is no option to discard the event

Which I would say is a bug then that we need to fix, I vaguely remember customers asking about this.

A dedicated on_crash that allows you to optionally discard the crash event would be a very welcome change.

Though it should be well documented in which permutations we have what kind of guarantees. As in: crashpad on macOS would not support any of that :-(

[espkk]

Adjusted as discussed. readme is not updated yet.
not sure what to do with breakpad uctx , it seems it cannot be extracted

[Swatinem]

One thing to note here, and I think this is very much in line with the recent changes to sessions, more specifically, we shouldn’t touch them when the event is being discarded by hooks. But that also means that sessions would be marked as "abnormal" instead of "crashed", but I think this is expected. CC @adinauer

[Swatinem]

It looks like our CI is broken right now, but I will merge this as soon as we fix that.

[Swatinem]

Sorry for this last minute change request ;-)

Also we fixed our CI, so please merge/rebase master.

[Swatinem]

This might just be personal preference, but I think its also more consistent with similar callbacks:
Can you turn this logic around? So that false discards the event, and true will continue processing as normal?
This is also in line with how before_send behaves, as you return a null value to discard the event.

[espkk]

I already inverted it to be consistent with crashpad and breakpad handler returns
But it makes sense, especially since it's not used for breakpad return value anymore
Though, maybe it also shouldn't be used for crashpad as well there?

sentry-native/src/backends/sentry_backend_crashpad.cpp

Lines 188 to 190 in e8011b6

	// further handling can be skipped via on_crash hook
	return already_handled;

[Swatinem]

I admit this is a bit confusing. Ideally the SDK users should not care about the underlying handler, and we can return an appropriate value to make the handler behave like it should.

[espkk]

The problem is I'm not sure what is the desired behaviour.
The docs says
If the custom handler returns true, the signal is considered handled and the signal handler returns. Otherwise, the currently installed Crashpad signal handler is run.
But the actual behaviour should depend on some formal requirements
I reverted the return to false for crashpad too. Let me know if you think it should depend on on_crash return

[Swatinem]

I reverted the return to false for crashpad too. Let me know if you think it should depend on on_crash return

Yes I think it should. Essentially we need to return !should_handle, as returning true from the crashpad hook tells it to not handle (aka send to sentry).

[espkk]

alright, should be fine now