Conversation
|
Thanks, @stima and @ayx-rsavchenko! The way we currently set up our handlers, this makes sense. I have a couple of other changes in the same territory and will look at how to integrate this best when I am working on those. |
stima
force-pushed
the
first_chance_handler
branch
from
f4e7c79 to
78f579a
Compare
|
@supervacuus Hey any updates on that? |
Hi @stima, I am truly sorry for not responding for such a long time. Over the last months, the focus has been on supporting downstream SDKs with various native topics that weren't necessarily Native SDK-related. This led to open PRs and issues related to standalone usage being put on the back burner. I will focus on standalone usage this month. |
|
Closing in favor of #109 and getsentry/sentry-native#1019 which integrated the general idea of the PR. Thanks! |
4 participants
For platfroms that support FirstChanceHandler (windows, linux) execute it only once.
For windows that mimics behaviour of
sentry__crashpad_handlerbut avoid an issue with a possible race condition for multiple executions ofsentry__crashpad_handler:crashpad_state_t::event_pathduringcrashpad_backend_flush_scopecrashpad_state_t::eventinsidesentry__crashpad_handlerThat would also remove necessety of having
sentry__enter_signal_handlerfor linux, because crashpad has same logic insideSignalHandler::HandleOrReraiseSignal.