Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sentry APIs block after failed sentry_init #638

Closed
2 tasks
zakalawe opened this issue Dec 20, 2021 · 3 comments · Fixed by #639
Closed
2 tasks

Sentry APIs block after failed sentry_init #638

zakalawe opened this issue Dec 20, 2021 · 3 comments · Fixed by #639
Labels
bug Something isn't working

Comments

@zakalawe
Copy link

Description

When sentry_init returns non-zero, in my case due to broken deployment (no crashpad executable in the correct location), calling other Sentry APIs on other threads will block forever, because they try to acquire mutexes which are in-use.

When does the problem happen

  • During build
  • [X ] During run-time
  • When capturing a hard crash

Environment

Observed on Windows and macOS (pthread)

Steps To Reproduce

  1. run with a missing / non-executable crashpad
  2. call an API, eg sentry_add_breadcrumb, from a secondary thread
    -> the thread blocks indefinitely on sentry__options_getref, trying to lock g_options_lock

I'm now correctly handling non-zero returns from sentry_init, but of course it would be ideal if other APIs did not block in this case, but rather just returned immediately.

@zakalawe
Copy link
Author

Wow, fast response, thanks guys, you are awesome.

@Swatinem
Copy link
Member

Are you okay using the git version for the time being? We are in the middle of some bigger changes and would rather hold of on releasing some incomplete things.

@zakalawe
Copy link
Author

Yes, that's no problem at all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants