You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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!
The text was updated successfully, but these errors were encountered:
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.
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.
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
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!
The text was updated successfully, but these errors were encountered: