Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Additional work in dumpasync command #163

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

Closed
mikem8361 opened this issue Apr 17, 2019 · 1 comment
Closed

Additional work in dumpasync command #163

mikem8361 opened this issue Apr 17, 2019 · 1 comment
Assignees
Milestone

Comments

@mikem8361
Copy link
Member

@stephentoub commented on Tue Oct 16 2018

In dotnet/coreclr#18160 and dotnet/coreclr#18213 for 3.0 we added a basic dumpasync command to SOS. Before we actually ship it, we should try to augment it in a few ways:

  1. Remove the dependency on interpreting the C# state machine's _state field. We can use the Task's IsCompleted for the same purpose.
  2. Add support for following continuation chains. Right now we use gcroots for this purpose, which can actually be more comprehensive, but also adds a lot of runtime expense.
  3. Support optionally finding all Tasks, not just async state machine objects; that's fairly easily done with dumpheap today, but the gcroot automation, completion detection, and continuation-chain following from (2) all make it much more useful in dumpasync than it is in dumpheap.
  4. List all thread stacks waiting on tasks, and dump the associated information for that task (state machine if it's an async method, gcroot / continuation chain, etc.)

cc: @noahfalk


@mikem8361 commented on Tue Oct 16 2018

Maybe this could be done in the diagnostics repo.


@stephentoub commented on Tue Oct 16 2018

Is that the official home now for the SOS source? Is the code in coreclr being deleted then? Or mirrored? Or some such thing?


@mikem8361 commented on Tue Oct 16 2018

Eventually it will be the official home for SOS and it will be deleted from coreclr, but I still have a few hoops and other things to go through to ship this SOS “out of band”. That is why I said “maybe”. I don’t have a definite time frame for the switch over. Probably not 2.2. On the positive side, it is easier to develop and testing is more through in the diagnostic repo.


@tommcdon commented on Wed Apr 17 2019

@mikem8361 can we move this issue to the diagnostics repo?

@mikem8361 mikem8361 self-assigned this Apr 17, 2019
@mikem8361 mikem8361 modified the milestones: Future, 3.0 Apr 17, 2019
@mikem8361 mikem8361 assigned stephentoub and unassigned mikem8361 Apr 17, 2019
@stephentoub
Copy link
Member

This has all been done. (Not 4, but I don't think that's necessary.)

@ghost ghost locked as resolved and limited conversation to collaborators Jun 27, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants