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

iOS bugsnag events - show the number of alive threads #595

Open
troy-lamerton opened this issue Aug 9, 2022 · 2 comments
Open

iOS bugsnag events - show the number of alive threads #595

troy-lamerton opened this issue Aug 9, 2022 · 2 comments
Labels
backlog We hope to fix this feature/bug in the future feature request Request for a new feature

Comments

@troy-lamerton
Copy link

troy-lamerton commented Aug 9, 2022

Description

Describe the solution you'd like

In bugsnag events from iOS devices, I would like to know the number of threads that were alive when the event happened.

Describe alternatives you've considered

  • Looking at Apple crash reports in Xcode.
  • Write a native method to get number of threads, then leave a breadcrumb every 30 seconds stating the number of threads

Additional context

Grand Central Dispatch is limited to 64 threads. When this limit is reached, any code that tries to wait run on a DispatchQueue will cause the app to hang. This leads to events with varying stacktraces.

It's not obvious that such a crash is caused by the GCD thread pool limit. However, the number of threads is often 50+ more than normal when GCD is hitting the limit. For example, Apple crash reports showed 120+ threads for these app hangs, but only 70 threads for other crashes. So seeing the number of threads will help identify this specific issue.

If you guys can think of a better way to identity GCD thread pool exhaustion, I'd be open to that as well!

@luke-belton
Copy link
Member

Hi @troy-lamerton - firstly, in terms of getting a thread count, we do have an item on our product roadmap to look at adding this information in the future. I've noted your use case with our product team and will keep you updated on that. In the meantime, you may be able to implement something similar yourself inside a callback that's run at crash time, adding this as metadata to the error event that you see in the Bugsnag dashboard. You can read about these callbacks in our docs, and the threads, including their state, is already exposed on the Event object that the callback receives.

In terms of GCD thread pool exhaustion - I'm going to have some internal discussions on that to see if there's anything we can do in that area in the future, and again will keep you updated.

@luke-belton luke-belton added feature request Request for a new feature backlog We hope to fix this feature/bug in the future labels Aug 10, 2022
@luke-belton
Copy link
Member

Hi @troy-lamerton - just a quick update on this, we've added an item to our roadmap to look at showing when the GCD queue thread limit is reached, however I don't have an ETA for when we might work on that.

It is worth noting that GCD queue width is an implementation detail and not something that should necessarily be relied upon as part of your app design - there's a bit more discussion on this here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backlog We hope to fix this feature/bug in the future feature request Request for a new feature
Projects
None yet
Development

No branches or pull requests

2 participants