-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Ability to print stacktraces of all tasks, including unscheduled ones #46177
Comments
From my perspective, I think we could achieve this by keeping an array of WeakRefs to all Tasks, adding every task when its first constructed. And then we can iterate that to dump the tasks when requested. Does that sound reasonable to others? Could that integrate well with the existing spontaneous profiling tools? |
Note that the spontaneous profiling tool (good name!) does group by thread and task already. It'd be good to understand how that's falling short |
Ian, i think that it only shows the stack traces for tasks that are scheduled on threads. I.e. it's a profile of execution. We're interested in something different, which is understanding the state of execution of all Tasks in the system, even the ones that aren't scheduled, because they're currently blocking. This can help with identifying the cause of a deadlocked runtime, by dumping all Task stack traces and identifying which ones should be making progress but aren't able to. This cannot really be automated in general, and requires a careful eye reading the code together with all the stacktraces. |
Sounds like a good topic for the profiling call this Friday @ 2pm ET, if you can make it! |
|
Thanks @maleadt. That PR is actually what started this discussion, yeah. I think we think that Lines 256 to 257 in b2bf56e
Lines 138 to 140 in 05eb153
And note that you need to loop through all the threads to get all live tasks, like we did in So I think
I think the best way to do this would be with a global array of Weak References, which we add new Tasks to in their constructor, or when they're first scheduled. Does that sound reasonable to you? |
CC: @kpamnany, @jakebolewski |
Hmm, I'm able to see the
I'm probably missing something though, as I'm not familiar with the scheduler internals. @vtjnash should be able to elaborate. |
Correct, |
Okay! Thanks both, that really helps me understand what's going on! So I think we were just misunderstanding what @maleadt i'm not sure why i wasn't seeing the same backtraces that you are seeing... 🤔 @vchuravy pointed out that maybe for some reason my tasks weren't meeting some of these criteria?: Lines 866 to 870 in e2a8a4e
Thanks @JeffBezanson, so maybe actually #44990 is what we wanted, and we can re-open that PR! :) Thanks |
Reopening until the revert is reapplied :) |
Detecting deadlocks is currently a bit difficult because if the tasks involved are unscheduled, we have no way of printing their backtraces.
Feature request: ability to print backtraces of all tasks, including all currently unscheduled tasks.
For us, deadlocks are not just priority inversions on locks, they can be byzantine scenarios involving many tasks, semaphores, channels, mutexes, conditions, futures, etc.
CC @NHDaly
The text was updated successfully, but these errors were encountered: