Change GetThreadContext to return an ReadOnlySpan because the original
API allowed the array returned to be changed. Fixed a couple of other
APIs to that a ReadOnlySpan.
Added some common GetThreadContext extensions
Fixed an issue with the `!dumprequests` command that was causing an
error when reading dumps from a Kestrel host.
```
0:000> !dumprequests
Field 'Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http2.Http2Stream<Microsoft.AspNetCore.Hosting.HostingApplication+Context>.<Method>k__BackingField' is not of type 'string'.
```
In Kestrel host dumps, the `<Method>k__BackingField` field in the
`HttpContext` object is of `Enum` type, whereas in IIS host dumps, it is
of `String` type. To address this, the `_methodText` field in the
`HttpContext` object is now read if the `<Method>k__BackingField` field
is not of `String` type.
Also added min width for each column for better readability.
---------
Co-authored-by: Sainath Reddy G N V <nagosang@microsoft.com>
The @dotnet/source-build-internal team is being deprecated. All
references to it were updated.
Included the renaming of SourceBuild.props to the new naming convention,
DotNetBuild.props.
Related to dotnet/source-build#4645
Repo admins, please grant write access to @dotnet/product-construction
and @dotnet/source-build. This is needed for the CODEOWNERS changes.
Write access can be removed for @dotnet/source-build-internal.
---------
Co-authored-by: Matt Thalman <mthalman@microsoft.com>
Fixes https://github.com/dotnet/diagnostics/issues/4826
When running dotnet-stack against an unresponsive target process, there
were various points where dotnet-stack wouldn't correctly cancel when
Ctrl-C was pressed. There were several underlying issues:
- Cancellation caused EventPipeSession.Dispose() to run which attempted
to send a Stop IPC command that might block indefinitely
- Several of the async operations dotnet-stack performed did not pass a
cancellation token and so ignore when Ctrl-C is pressed
- The calls to start and stop the session were still using the
synchronous API which both ignored the cancellation token and create the
standard async-over-sync issues.
The change in behavior for EventPipeSession.Dispose() is strictly
speaking a breaking change, although callers would need to emply some
dubious code patterns to observe the difference. The most likely way
code could observe the difference is if thread 1 is reading from the
EventStream at the same time thread 2 called Dispose(). Previously this
would have caused thread 1 to start receiving rundown events although it
was also a race condition between thread 1 reading from the stream and
thread 2 disposing the stream. Its possible some tool could have worked
successfully if thread 1 always won the race in practice. If any code
was doing that pattern then now thread 1 will observe the stream is
disposed without seeing the rundown events first. The proper way to
ensure seeing all the rundown events would be to explicitly call
EventPipeSession.Stop(), then read all the remaining data and reach the
end of stream marker, then Dispose() the session.
I looked through all the usage of EventPipeSession in our existing tools
and it looked like all of them were already using Stop() properly.
This changes resource iteration in `GetNextLevelResourceEntryRVA` to explicitly cast a potential overflow. It's safe since it will just not iterate any resources.
```sh
$ ./build.sh
...
[ 97%] Building CXX object src/SOS/Strike/CMakeFiles/sos.dir/platform/hostimpl.cpp.o
/foo77/diagnostics/src/SOS/Strike/eeheap.cpp:439:11: error: cannot initialize a variable of type 'DWORD' (aka 'unsigned int') with an rvalue of type 'std::nullptr_t'
DWORD Value = NULL;
^ ~~~~
```
Fix:
```sh
$ ./build.sh
...
dotnet-install: To check the list of dependencies, go to https://learn.microsoft.com/dotnet/core/install, select your operating system and check the "Dependencies" section.
Restore complete (43.7s)
diagnostics failed with 19 error(s) (86.1s)
/foo77/diagnostics/src/Microsoft.Diagnostics.DebugServices.Implementation/Microsoft.Diagnostics.DebugServices.Implementation.csproj : error NU1903: Warning As Error: Package 'System.Text.Json' 8.0.4 has a known high severity vulnerability, https://github.com/advisories/GHSA-8g4q-xg66-9fp4
/foo77/diagnostics/src/SOS/SOS.Extensions/SOS.Extensions.csproj : error NU1903: Warning As Error: Package 'System.Text.Json' 8.0.4 has a known high severity vulnerability, https://github.com/advisories/GHSA-8g4q-xg66-9fp4
/foo77/diagnostics/src/Tools/dotnet-symbol/dotnet-symbol.csproj : error NU1903: Warning As Error: Package 'System.Text.Json' 6.0.9 has a known high severity vulnerability, https://github.com/advisories/GHSA-8g4q-xg66-9fp4
/foo77/diagnostics/src/Tools/dotnet-trace/dotnet-trace.csproj : error NU1903: Warning As Error: Package 'System.Text.Json' 8.0.4 has a known high severity vulnerability, https://github.com/advisories/GHSA-8g4q-xg66-9fp4
/foo77/diagnostics/src/Tools/dotnet-counters/dotnet-counters.csproj : error NU1903: Warning As Error: Package 'System.Text.Json' 8.0.4 has a known high severity vulnerability, https://github.com/advisories/GHSA-8g4q-xg66-9fp4
/foo77/diagnostics/src/Tools/dotnet-dsrouter/dotnet-dsrouter.csproj : error NU1903: Warning As Error: Package 'System.Text.Json' 6.0.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-8g4q-xg66-9fp4
/foo77/diagnostics/src/Microsoft.Diagnostics.Monitoring.EventPipe/Microsoft.Diagnostics.Monitoring.EventPipe.csproj : error NU1903: Warning As Error: Package 'System.Text.Json' 8.0.4 has a known high severity vulnerability, https://github.com/advisories/GHSA-8g4q-xg66-9fp4
```
related PR https://github.com/dotnet/runtime/pull/108704
DiagnosticClient is documented on our official docs site. Removing the
repo copy which is not receiving updates and would get out-of-sync.
Related to: https://github.com/dotnet/docs/pull/42771
dotnet-maestro[bot]
Mike McLaughlin
Liu An
Sainath Reddy G N V
Michael Simons
Noah Falk
Juan Hoyos
Adeel Mujahid