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
### General announcements
General fixes and improvements across SOS debugger commands, macOS dump
analysis, and the diagnostic tools since v10.0.721401.
### dotnet-dump / SOS
- **`!gcinfo` GC info v5 support**: The `GCInfoDecoder`/`GCInfoDumper`
sources were synchronized with dotnet/runtime to parse GC info **version
5**, keeping `!gcinfo` working against current runtime builds. (#5862)
- `!threadpool` now properly enumerates assignable work item queues
- Adds support for 11.0 preview 4 runtimes.
- Much faster SOS-in-lldb memory reads for macOS.
- Fixes in crash dump special buffer detection on Apple Silicon cores.
- Modules that live in the macOS 11+ dyld shared cache are now
identified and skipped during version-string extraction, avoiding
unnecessary symbol-server downloads and timeouts.
### dotnet-gcdump
- **Clearer `convert` errors**: `dotnet-gcdump convert` now emits
actionable messages when the input is not a valid nettrace file,
contains no GC heap events, or holds an incomplete heap dump, instead of
failing opaquely. (#5814)
### Other notable changes
- **Source Link for SOS native libraries**: Added Source Link support
for the SOS native libraries, enabling source-level debugging into the
native SOS binaries. (#5703)
Copy file name to clipboardExpand all lines: .github/policies/resourceManagement.yml
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -36,7 +36,7 @@ configuration:
36
36
days: 3
37
37
actions:
38
38
- addReply:
39
-
reply: Hi @${issueAuthor}. We are closing this issue due to inactivity. If you comment within 30 days it will automatically reopen. If you are not the author of this issue and you're facing the same problem, feel free to open a new issue referencing this one.
39
+
reply: Hi ${issueAuthor}. We are closing this issue due to inactivity. If you comment within 30 days it will automatically reopen. If you are not the author of this issue and you're facing the same problem, feel free to open a new issue referencing this one.
40
40
- closeIssue
41
41
- description: '[Idle Issue Management] Add no recent activity label to issues'
42
42
frequencies:
@@ -174,7 +174,7 @@ configuration:
174
174
label: 'Needs: Author Feedback'
175
175
then:
176
176
- addReply:
177
-
reply: 'Hi @${issueAuthor}. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.'
177
+
reply: 'Hi ${issueAuthor}. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.'
description: Generate release notes for the dotnet/diagnostics repository. Use when asked to generate release notes, a release summary, or a changelog.
4
+
---
5
+
6
+
# Release Notes Generation
7
+
8
+
## Process
9
+
10
+
### 1. Determine the baseline
11
+
12
+
Find the **last published GitHub release** — not the latest git tag. This repo may have many version tags (e.g., `v10.0.*`, `v11.0.*`) that don't correspond to published releases.
13
+
14
+
```bash
15
+
# Get the most recent published GitHub release tag for dotnet/diagnostics
The last published release may be on a different branch (e.g., `release/9.0`). Even so, use the tag directly in `git log` — **do NOT use `git merge-base`**. The release branch often contains snap/backport merges that bring `main` commits into the release, so `merge-base` returns an ancestor that is already included in the release tag. Instead:
21
+
22
+
```bash
23
+
# Correct: use the tag directly — git handles cross-branch reachability
Follow the format used in the latest release to get a sense of the current format used. For example, for `v9.0.661903` the structure follows the following pattern:
59
+
60
+
```markdown
61
+
### General announcements
62
+
63
+
Brief summary.
64
+
65
+
### dotnet-dump / SOS
66
+
67
+
-**Feature/fix name**: Description focusing on WHY and user impact. (#PR)
68
+
69
+
#### SOS Bug Fixes
70
+
71
+
-**Command affected**: What was wrong, what's fixed. (#PR)
72
+
73
+
### dotnet-trace
74
+
75
+
-**collect-linux improvements**: Group related sub-items.
76
+
77
+
### dotnet-counters
78
+
79
+
-**Feature**: Description. (#PR)
80
+
81
+
### Microsoft.Diagnostics.NETCore.Client
82
+
83
+
-**Feature**: Description. (#PR)
84
+
85
+
### Other notable changes
86
+
87
+
- Items that don't fit above categories.
88
+
```
89
+
90
+
### 5. Style guidelines
91
+
92
+
- Focus on **why** a change matters to users, not implementation details
93
+
- Include issue references where available: `([#1234](https://github.com/dotnet/diagnostics/issues/1234), #5678)`
94
+
- Group related fixes (e.g., all `collect-linux` terminal fixes together)
95
+
- Call out breaking changes or UX changes explicitly
96
+
- Omit purely internal changes (refactors, test moves, CI config) unless they have user impact
97
+
- Use bold for command names and flags: **`!dumpheap -stat -bycount`**
98
+
99
+
## Example output
100
+
101
+
See the release at https://github.com/dotnet/diagnostics/releases/tag/v9.0.661903 for format reference.
The interpreter-frame SOS tests (`SOSInterpreterTests`) are skipped by default because `FEATURE_INTERPRETER` is only compiled into Debug/Checked CoreCLR drops (see `src/coreclr/clrfeatures.cmake` in dotnet/runtime) and is therefore unavailable on the public Release runtimes the SOS tests download by default.
61
+
62
+
The opt-in is layered:
63
+
64
+
1.**Per-debuggee csproj flag.**`Debuggees/InterpreterStackTest/InterpreterStackTest.csproj` declares `<InterpreterTest>true</InterpreterTest>` to mark itself as an interpreter SOS test. Methods that should run on the interpreter follow the convention of being named with the prefix `InterpTestMethod` (e.g. `InterpTestMethodRunNested`). The csproj does not need to specify the method-name pattern; it is shared across all interpreter-test debuggees.
65
+
2.**Per-test gate.**`SOS_TEST_INTERPRETER=true` (or `-testInterpreter` to `Build.cmd`/`build.sh`) unskips the `SOSInterpreterTests.InterpreterStackTest` test method. SOSRunner sets `DOTNET_Interpreter=InterpTestMethod*` on the debuggee process at launch when this gate is on. The shared `Debuggees/Directory.Build.targets` additionally no-ops any direct `dotnet build` of an interpreter-test debuggee when the gate is unset, emitting a message rather than producing a binary that wouldn't exercise the interpreter. Other SOS tests are unaffected.
66
+
67
+
To run them:
68
+
69
+
1. Build the runtime as Checked: `build.cmd -subset clr -c Checked` (or `-c Debug`).
70
+
2. Overlay that drop onto each `artifacts\dotnet-test\shared\Microsoft.NETCore.App\<version>` directory exactly as for any private build (see the example scripts above).
71
+
3. Set `SOS_TEST_INTERPRETER=true` (or pass `-testInterpreter` to `Build.cmd`/`build.sh` when running with `-test`).
0 commit comments