Obsolete constructor public StackTrace(Thread targetThread, bool needFileInfo)

[DamirLisak]

I wan't to come back to the sentence from Originally posted by @leculver in #31508 (comment)
"It's just on my roadmap. Feel free to create an issue in the clrmd github repo though if you'd like to track it."

https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.stacktrace.-ctor?view=net-7.0

This feature was automatically closed by the msftbot. Is this feature still planned to be implemented? If not - why?
Stack-Tracing of managed threads is not only useful for unresponsive threads, it's very useful for the diagnostic during runtime.
1.) For example in very multithreaded projects to detect deadlocks and prevent deadlocks by lock leveling (https://learn.microsoft.com/en-us/archive/msdn-magazine/2007/october/net-matters-deadlock-monitor). Only by suspending all relevant threads, dumping the stack trace and resuming them afterwards is it possible to find problems on productive systems.
2.) A another example for diagnosing performance issues when the processing time of a thread is to long because it waits for a lock, that is currently hold by another thread. Another monitoring thread would then temporarily stop the relevant threads and dump the stacks.
I think there are far more examples where suspending and resuming threads is useful. Therefore, I cannot understand why such functionalities that existed in .NET 4 should no longer be available in .net core.

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[DamirLisak]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Label is:
area-System.Diagnostics

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I wan't to come back to the sentence from Originally posted by @leculver in #31508 (comment)
"It's just on my roadmap. Feel free to create an issue in the clrmd github repo though if you'd like to track it."

https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.stacktrace.-ctor?view=net-7.0

This feature was automatically closed by the msftbot. Is this feature still planned to be implemented? If not - why?
Stack-Tracing of managed threads is not only useful for unresponsive threads, it's very useful for the diagnostic during runtime.
1.) For example in very multithreaded projects to detect deadlocks and prevent deadlocks by lock leveling (https://learn.microsoft.com/en-us/archive/msdn-magazine/2007/october/net-matters-deadlock-monitor). Only by suspending all relevant threads, dumping the stack trace and resuming them afterwards is it possible to find problems on productive systems.
2.) A another example for diagnosing performance issues when the processing time of a thread is to long because it waits for a lock, that is currently hold by another thread. Another monitoring thread would then temporarily stop the relevant threads and dump the stacks.
I think there are far more examples where suspending and resuming threads is useful. Therefore, I cannot understand why such functionalities that existed in .NET 4 should no longer be available in .net core.

Author:	DamirLisak
Assignees:	-
Labels:	area-System.Diagnostics, untriaged
Milestone:	-

[tommcdon]

@noahfalk

[noahfalk]

Originally posted by @leculver in #31508 (comment)
"It's just on my roadmap. Feel free to create an issue in the clrmd github repo though if you'd like to track it."
https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.stacktrace.-ctor?view=net-7.0
This feature was automatically closed by the msftbot. Is this feature still planned to be implemented? If not - why?

There may have been some confusion but I believe the "It" that Lee Culver was referring to implementing at that point in the discussion was the ability for the CLRMD library to attach to a running process on Linux. I'll defer to @leculver to understand what the current status of that work is.

In terms of StackTrace API that takes a Thread parameter, any attempt to recreate the API would require a new implementation because the underlying runtime code it relied on has undergone some significant changes. The more interest we see from developers to use that API the more priority we would give it, but so far I think requests have been few and far between.

In the meantime there are some potential alternatives that might fulfill what you are looking for. The dotnet-stack tool can produce a textual version of stacktraces for all threads. It is intended for developers that are diagnosing hangs/deadlocks to understand where threads are blocked. If you didn't want to run a 2nd process there is also the Microsoft.Diagnostics.NetCore.Client library which has the underlying APIs you could invoke directly and all the code to dotnet-stack is OSS if you want to see how it works. These APIs are a little more involved than a one-liner new StackTrace(...), but they are also considerably more powerful letting you capture complete profiling traces or dumps. For example with a trace you could distinguish whether the non-responsive thread is deadlocked, live locked, or just executing abnormally slowly.
If you captured dumps instead of profiling traces the CLRMD library Lee was refering to can help programmatically analyze them, or you can load them in a debugger like any other dump.

Sorry I know its not quite what you were hoping for, but hopefully some of the alternatives help. I'm also happy to leave this issue open to allow other .NET devs to +1 their interest in the StackTrace(Thread, ...) APIs.

[DamirLisak]

@tommcdon : Thank you for adding to future milestone 🙏!