Provided context for exception's thread for mac

[saf-e]

Collect exception's thread context to give ability traverse call stack

[Swatinem]

I will defer this to @supervacuus

[supervacuus]

Hi @saf-e!

Thanks for the contribution! Can you elaborate on what you're trying to achieve with this change? As @Swatinem mentioned in #39 (comment), this not only breaks compatibility with the upstream project but also breaks the current interface with the Native SDK.

For this change to make sense in the Native SDK context, the retrieved information would have to be passed on somehow to the client via the on_crash hook. To do so, we'd have to retrieve the context for this hook on all backends and all platforms. But since you didn't provide a PR on the Native SDK side, I cannot imagine what context you'd use this change in.

The change, as it currently exists in this PR, does not provide any value to the Native SDK users. If you can provide a few lines of explanation, that would help. Thanks.

[saf-e]

As I already mentioned, breakpad does not provide any exception context to the callback for mac (for windows we have it). So, its not possible make any logic on it.

In our case, we use exception's callstack (obtained from context), to analyze do we want to sent this crash to sentry or not

[supervacuus]

Thanks, @saf-e. I probably formulated my question incorrectly: I understand what the feature you're trying to add does. The question for me is how you want to integrate this. If I merge this as is, the breakpad fork will be unusable in the Native SDK (because the build will break).

So, my question boils down to this:

• do you plan to create a PR for the Native SDK, too?
• if so, do you have the capacity/time to make this a non-breaking change vs. vanilla breakpad (by adding interfaces instead of changing existing ones and then adapting the compile-time conditionals in the breakpad-backend to support both)?

I am okay with taking over the integration, but it will take a while until I have time to do this.

[saf-e]

do you plan to create a PR for the Native SDK, too?

yes, but it has no sense w/o this one, so it waits for its turn
if you know some github's multi-commit feature, I'll gladly use it

by adding interfaces instead of changing existing ones and then adapting the compile-time conditionals in the breakpad-backend to support both

I suppose thats possible, will try to do in nearest future

[supervacuus]

do you plan to create a PR for the Native SDK, too?

yes, but it has no sense w/o this one, so it waits for its turn if you know some github's multi-commit feature, I'll gladly use it

You can checkout the breakpad submodule at the commit in this PR and then commit it to a PR in the Native SDK. Github PRs have no problem with submodules as long as the referenced commit (i.e., its branch/fork) is accessible via a GitHub remote (like from a PR of the remote in .gitmodules). It is a very convenient feature, and it makes changes to the submodules much easier to review.

by adding interfaces instead of changing existing ones and then adapting the compile-time conditionals in the breakpad-backend to support both

I suppose thats possible, will try to do in nearest future

Thx!

[saf-e]

@supervacuus added ifdef for sentry compilation, plz check if you are ok with the approach

[supervacuus]

Sorry for the gigantic delay, @saf-e. Thanks for the effort. This will be integrated via getsentry/sentry-native#1083