createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS - #130443

Merged
steveisok merged 1 commit into
dotnet:mainfrom
steveisok:fix-specialdiaginfo
Jul 10, 2026
Merged

createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS#130443
steveisok merged 1 commit into
dotnet:mainfrom
steveisok:fix-specialdiaginfo

Conversation

@steveisok

@steveisoksteveisok commented Jul 9, 2026

Copy link
Copy Markdown
Member

Summary

Fixes the createdump (write) side of the SpecialDiagInfo issue addressed on the
reader side in dotnet/diagnostics#5823.

On Apple Silicon, the legacy macOS SpecialDiagInfo address 0x7fffffff10000000
is above the 47-bit user-space VM limit. createdump still writes a segment at
that address, but lldb's MachO core reader refuses to return reads above
0x7FFF_FFFFFFFF, so SOS reports:

Special diagnostics info read failed

and falls through to the slower managed-side path (or fails outright on older
builds without that fallback).

Change

src/coreclr/debug/createdump/specialdiaginfo.h now selects the address by arch
on macOS:

  • arm64 macOS → 0x00007ffffff10000 (47-bit valid; same address already
    used on Linux/other 64-bit)
  • x86_64 macOS → 0x7fffffff10000000 (legacy, unchanged)

All other platforms (Linux/other 64-bit, 32-bit) are unchanged.

The matching diagnostics reader (dotnet/diagnostics#5823) probes both the new
and legacy addresses, so dumps produced by older createdump binaries remain
readable — no regression.

Notes

  • SpecialThreadInfoAddress (0x7fffffff00000000) is intentionally left as-is;
    it's out of scope for this fix and lldb tolerates that region.

Note

This PR description was drafted with GitHub Copilot.

@steveisok
createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS
ba64543
The legacy macOS SpecialDiagInfo address 0x7fffffff10000000 is above Apple
Silicon's 47-bit user-space VM limit, so lldb's MachO core reader refuses to
return the segment and SOS reports "Special diagnostics info read failed".
Write the segment at the 47-bit-valid 0x00007ffffff10000 on arm64 macOS
(the same address already used on Linux 64-bit) while keeping the legacy
address on x86_64 macOS. This is the createdump-side counterpart to
dotnet/diagnostics#5823, whose reader probes both the new and legacy
addresses so older dumps remain readable.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: f5c2b675-e04f-4544-8338-ab6dc4701d7f
@steveisok
steveisok requested review from a team and CopilotJuly 9, 2026 23:34
@dotnet-policy-service

dotnet-policy-serviceBot commented Jul 9, 2026

Copy link
Copy Markdown
Contributor

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

CopilotAI reviewed Jul 9, 2026
View reviewed changes

CopilotAI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR adjusts the fixed virtual address used for the “SpecialDiagInfo” dump segment on Apple Silicon macOS so it stays within the 47-bit user-space address range accepted by lldb’s Mach-O core reader, while preserving the legacy address on x86_64 macOS.

Changes:

  • Use a 47-bit-valid SpecialDiagInfoAddress on macOS arm64 (0x00007ffffff10000).
  • Keep the legacy macOS x86_64 SpecialDiagInfoAddress unchanged (0x7fffffff10000000).

@build-analysisbuild-analysisBot mentioned this pull request Jul 10, 2026
Open
3 tasks
This was referenced Jul 10, 2026
Closed
Closed
@steveisok
steveisok merged commit a8110f2 into dotnet:mainJul 10, 2026
111 of 113 checks passed
@steveisok
steveisok deleted the fix-specialdiaginfo branch July 10, 2026 23:16
@dotnet-maestrodotnet-maestroBot mentioned this pull request Jul 11, 2026
Merged
@dotnet-milestone-botdotnet-milestone-botBot added this to the 11.0-preview7 milestone Jul 11, 2026
eiriktsarpalis pushed a commit that referenced this pull request Jul 15, 2026
@steveisok@eiriktsarpalis
createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS (#…
f4cab58
…130443)
## Summary
Fixes the createdump (write) side of the SpecialDiagInfo issue addressed
on the
reader side in dotnet/diagnostics#5823.
On Apple Silicon, the legacy macOS SpecialDiagInfo address
`0x7fffffff10000000`
is above the 47-bit user-space VM limit. createdump still writes a
segment at
that address, but lldb's MachO core reader refuses to return reads above
`0x7FFF_FFFFFFFF`, so SOS reports:
`Special diagnostics info read failed`
and falls through to the slower managed-side path (or fails outright on
older
builds without that fallback).
## Change
`src/coreclr/debug/createdump/specialdiaginfo.h` now selects the address
by arch
on macOS:
- **arm64 macOS** → `0x00007ffffff10000` (47-bit valid; same address
already
used on Linux/other 64-bit)
- **x86_64 macOS** → `0x7fffffff10000000` (legacy, unchanged)
All other platforms (Linux/other 64-bit, 32-bit) are unchanged.
The matching diagnostics reader (dotnet/diagnostics#5823) probes both
the new
and legacy addresses, so dumps produced by older createdump binaries
remain
readable — no regression.
## Notes
- `SpecialThreadInfoAddress` (`0x7fffffff00000000`) is intentionally
left as-is;
it's out of scope for this fix and lldb tolerates that region.
> [!NOTE]
> This PR description was drafted with GitHub Copilot.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This was referenced Aug 6, 2026
Merged
Merged
max-charlamb added a commit that referenced this pull request Aug 7, 2026
@max-charlamb
createdump: fix macOS arm64 thread IDs in LLDB (#131962)
f659b2c
## Summary
- write the macOS arm64 createdump thread-info region at a 47-bit-valid
address
- emit OS thread IDs using LLDB's `process metadata` `LC_NOTE` format
- this is for future support so we can eventually remove the
`SpecialThreadInfo`
- retain the existing special thread-info segment while consumers
migrate to the LLDB format
## Motivation
Apple Silicon LLDB rejects the legacy `0x7fffffff00000000` synthetic
segment and falls back to sequential thread IDs beginning at zero. SOS
then cannot correlate LLDB threads with runtime OS thread IDs or
retrieve the selected thread context.
Coordinated SOS reader change:
dotnet/diagnostics#5953
## Related precedent
This follows @steveisok's coordinated Apple Silicon fix for
`SpecialDiagInfoAddress`:
- runtime writer: #130443
- diagnostics readers: dotnet/diagnostics#5823
## Testing
Draft pending coordinated diagnostics validation on macOS arm64.
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 7805386d-16fd-4306-bcc9-54d4ea7b65cf
max-charlamb added a commit to dotnet/diagnostics that referenced this pull request Aug 10, 2026
@max-charlamb
SOS: read macOS arm64 thread metadata from a valid address (#5953)
1b6da39
## Summary
- read macOS arm64 createdump thread metadata from the new 47-bit-valid
address
- fall back to the legacy address for compatibility with existing
createdump output
- use the selected address for all subsequent thread-info entries
## Motivation
Apple Silicon LLDB rejects the legacy `0x7fffffff00000000` synthetic
segment and assigns sequential thread IDs beginning at zero. SOS cannot
then correlate LLDB threads with runtime OS thread IDs or retrieve the
selected thread context.
Coordinated writer change: dotnet/runtime#131962
## Related precedent
This follows @steveisok's coordinated Apple Silicon fix for
`SpecialDiagInfoAddress`:
- runtime writer: dotnet/runtime#130443
- diagnostics readers: #5823
## Testing
Draft pending coordinated macOS arm64 validation with the runtime writer
change.
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 7805386d-16fd-4306-bcc9-54d4ea7b65cf
@github-actionsgithub-actionsBot locked and limited conversation to collaborators Aug 11, 2026
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Reviewers

Copilot code reviewCopilot
Copilot review effort
Applies to this pull request for everyone.Learn more about Copilot code review.
Copilot left review comments
@noahfalknoahfalknoahfalk approved these changes
@hoyosjshoyosjshoyosjs approved these changes

Assignees

@steveisoksteveisok

Labels

area-Diagnostics-coreclr

Projects

None yet

Milestone

11.0-preview7

Development

Successfully merging this pull request may close these issues.

4 participants

@steveisok@noahfalk@hoyosjs
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS - #130443
Merged
steveisok merged 1 commit into
dotnet:mainfrom 
steveisok:fix-specialdiaginfo
Jul 10, 2026
Merged
createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS#130443
steveisok merged 1 commit into
dotnet:mainfrom 
steveisok:fix-specialdiaginfo
Conversation
@steveisok
@steveisoksteveisok
commented
Jul 9, 2026

Copy link


Copy Markdown

Member
Summary
Fixes the createdump (write) side of the SpecialDiagInfo issue addressed on the

reader side in dotnet/diagnostics#5823.
On Apple Silicon, the legacy macOS SpecialDiagInfo address 0x7fffffff10000000

is above the 47-bit user-space VM limit. createdump still writes a segment at

that address, but lldb's MachO core reader refuses to return reads above
0x7FFF_FFFFFFFF, so SOS reports:
Special diagnostics info read failed
and falls through to the slower managed-side path (or fails outright on older

builds without that fallback).
Change
src/coreclr/debug/createdump/specialdiaginfo.h now selects the address by arch

on macOS:
  • arm64 macOS → 0x00007ffffff10000 (47-bit valid; same address already
    
used on Linux/other 64-bit)
  • x86_64 macOS → 0x7fffffff10000000 (legacy, unchanged)
All other platforms (Linux/other 64-bit, 32-bit) are unchanged.
The matching diagnostics reader (dotnet/diagnostics#5823) probes both the new

and legacy addresses, so dumps produced by older createdump binaries remain

readable — no regression.
Notes
  • SpecialThreadInfoAddress (0x7fffffff00000000) is intentionally left as-is;
    
it's out of scope for this fix and lldb tolerates that region.
Note
This PR description was drafted with GitHub Copilot.
@steveisok
createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS
ba64543
The legacy macOS SpecialDiagInfo address 0x7fffffff10000000 is above Apple
Silicon's 47-bit user-space VM limit, so lldb's MachO core reader refuses to
return the segment and SOS reports "Special diagnostics info read failed".
Write the segment at the 47-bit-valid 0x00007ffffff10000 on arm64 macOS
(the same address already used on Linux 64-bit) while keeping the legacy
address on x86_64 macOS. This is the createdump-side counterpart to
dotnet/diagnostics#5823, whose reader probes both the new and legacy
addresses so older dumps remain readable.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: f5c2b675-e04f-4544-8338-ab6dc4701d7f
@steveisok
steveisok
requested review from
a team and CopilotJuly 9, 2026 23:34
@dotnet-policy-service
dotnet-policy-serviceBot
commented
Jul 9, 2026

Copy link


Copy Markdown

Contributor
Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag

See info in area-owners.md if you want to be subscribed.
CopilotAI
reviewed
Jul 9, 2026
View reviewed changes
CopilotAI
left a comment


Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview
This PR adjusts the fixed virtual address used for the “SpecialDiagInfo” dump segment on Apple Silicon macOS so it stays within the 47-bit user-space address range accepted by lldb’s Mach-O core reader, while preserving the legacy address on x86_64 macOS.
Changes:
  • Use a 47-bit-valid SpecialDiagInfoAddress on macOS arm64 (0x00007ffffff10000).
  • Keep the legacy macOS x86_64 SpecialDiagInfoAddress unchanged (0x7fffffff10000000).
@build-analysisbuild-analysisBot
mentioned this pull request
Jul 10, 2026

Open

3 tasks

This was referenced Jul 10, 2026

Closed


Closed

@steveisok
steveisok
merged commit a8110f2
into
dotnet:mainJul 10, 2026

111 of 113 checks passed

@steveisok
steveisok
deleted the

fix-specialdiaginfo

branch
July 10, 2026 23:16
@dotnet-maestrodotnet-maestroBot
mentioned this pull request
Jul 11, 2026
 Merged

@dotnet-milestone-botdotnet-milestone-botBot
added this to the 11.0-preview7 milestone
Jul 11, 2026
eiriktsarpalis pushed a commit
that referenced
this pull request
Jul 15, 2026
@steveisok@eiriktsarpalis
createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS (#…
f4cab58
…130443)
## Summary
Fixes the createdump (write) side of the SpecialDiagInfo issue addressed
on the
reader side in dotnet/diagnostics#5823.
On Apple Silicon, the legacy macOS SpecialDiagInfo address
`0x7fffffff10000000`
is above the 47-bit user-space VM limit. createdump still writes a
segment at
that address, but lldb's MachO core reader refuses to return reads above
`0x7FFF_FFFFFFFF`, so SOS reports:
`Special diagnostics info read failed`
and falls through to the slower managed-side path (or fails outright on
older
builds without that fallback).
## Change
`src/coreclr/debug/createdump/specialdiaginfo.h` now selects the address
by arch
on macOS:
- **arm64 macOS** → `0x00007ffffff10000` (47-bit valid; same address
already
used on Linux/other 64-bit)
- **x86_64 macOS** → `0x7fffffff10000000` (legacy, unchanged)
All other platforms (Linux/other 64-bit, 32-bit) are unchanged.
The matching diagnostics reader (dotnet/diagnostics#5823) probes both
the new
and legacy addresses, so dumps produced by older createdump binaries
remain
readable — no regression.
## Notes
- `SpecialThreadInfoAddress` (`0x7fffffff00000000`) is intentionally
left as-is;
it's out of scope for this fix and lldb tolerates that region.
> [!NOTE]
> This PR description was drafted with GitHub Copilot.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

This was referenced Aug 6, 2026
 Merged

 Merged

max-charlamb added a commit
that referenced
this pull request
Aug 7, 2026
@max-charlamb
createdump: fix macOS arm64 thread IDs in LLDB (#131962)
f659b2c
## Summary
- write the macOS arm64 createdump thread-info region at a 47-bit-valid
address
- emit OS thread IDs using LLDB's `process metadata` `LC_NOTE` format
- this is for future support so we can eventually remove the
`SpecialThreadInfo`
- retain the existing special thread-info segment while consumers
migrate to the LLDB format
## Motivation
Apple Silicon LLDB rejects the legacy `0x7fffffff00000000` synthetic
segment and falls back to sequential thread IDs beginning at zero. SOS
then cannot correlate LLDB threads with runtime OS thread IDs or
retrieve the selected thread context.
Coordinated SOS reader change:
dotnet/diagnostics#5953
## Related precedent
This follows @steveisok's coordinated Apple Silicon fix for
`SpecialDiagInfoAddress`:
- runtime writer: #130443
- diagnostics readers: dotnet/diagnostics#5823
## Testing
Draft pending coordinated diagnostics validation on macOS arm64.
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 7805386d-16fd-4306-bcc9-54d4ea7b65cf
max-charlamb added a commit
to dotnet/diagnostics
that referenced
this pull request
Aug 10, 2026
@max-charlamb
SOS: read macOS arm64 thread metadata from a valid address (#5953)
1b6da39
## Summary
- read macOS arm64 createdump thread metadata from the new 47-bit-valid
address
- fall back to the legacy address for compatibility with existing
createdump output
- use the selected address for all subsequent thread-info entries
## Motivation
Apple Silicon LLDB rejects the legacy `0x7fffffff00000000` synthetic
segment and assigns sequential thread IDs beginning at zero. SOS cannot
then correlate LLDB threads with runtime OS thread IDs or retrieve the
selected thread context.
Coordinated writer change: dotnet/runtime#131962
## Related precedent
This follows @steveisok's coordinated Apple Silicon fix for
`SpecialDiagInfoAddress`:
- runtime writer: dotnet/runtime#130443
- diagnostics readers: #5823
## Testing
Draft pending coordinated macOS arm64 validation with the runtime writer
change.
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 7805386d-16fd-4306-bcc9-54d4ea7b65cf
@github-actionsgithub-actionsBot
locked and limited conversation to collaborators
Aug 11, 2026
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

Copilot code reviewCopilot
Copilot review effort
Applies to this pull request for everyone.Learn more about Copilot code review.
Copilot left review comments
@noahfalknoahfalknoahfalk approved these changes
@hoyosjshoyosjshoyosjs approved these changes

Assignees

@steveisoksteveisok

Labels

area-Diagnostics-coreclr

Projects


None yet


Milestone

11.0-preview7

Development

Successfully merging this pull request may close these issues.

4 participants

@steveisok@noahfalk@hoyosjs

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS - #130443
Merged
steveisok merged 1 commit into
dotnet:mainfrom 
steveisok:fix-specialdiaginfo
Jul 10, 2026
Merged
createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS#130443
steveisok merged 1 commit into
dotnet:mainfrom 
steveisok:fix-specialdiaginfo
Conversation
@steveisok
@steveisoksteveisok
commented
Jul 9, 2026

Copy link


Copy Markdown

Member
Summary
Fixes the createdump (write) side of the SpecialDiagInfo issue addressed on the

reader side in dotnet/diagnostics#5823.
On Apple Silicon, the legacy macOS SpecialDiagInfo address 0x7fffffff10000000

is above the 47-bit user-space VM limit. createdump still writes a segment at

that address, but lldb's MachO core reader refuses to return reads above
0x7FFF_FFFFFFFF, so SOS reports:
Special diagnostics info read failed
and falls through to the slower managed-side path (or fails outright on older

builds without that fallback).
Change
src/coreclr/debug/createdump/specialdiaginfo.h now selects the address by arch

on macOS:
  • arm64 macOS → 0x00007ffffff10000 (47-bit valid; same address already
    
used on Linux/other 64-bit)
  • x86_64 macOS → 0x7fffffff10000000 (legacy, unchanged)
All other platforms (Linux/other 64-bit, 32-bit) are unchanged.
The matching diagnostics reader (dotnet/diagnostics#5823) probes both the new

and legacy addresses, so dumps produced by older createdump binaries remain

readable — no regression.
Notes
  • SpecialThreadInfoAddress (0x7fffffff00000000) is intentionally left as-is;
    
it's out of scope for this fix and lldb tolerates that region.
Note
This PR description was drafted with GitHub Copilot.
@steveisok
createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS
ba64543
The legacy macOS SpecialDiagInfo address 0x7fffffff10000000 is above Apple
Silicon's 47-bit user-space VM limit, so lldb's MachO core reader refuses to
return the segment and SOS reports "Special diagnostics info read failed".
Write the segment at the 47-bit-valid 0x00007ffffff10000 on arm64 macOS
(the same address already used on Linux 64-bit) while keeping the legacy
address on x86_64 macOS. This is the createdump-side counterpart to
dotnet/diagnostics#5823, whose reader probes both the new and legacy
addresses so older dumps remain readable.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: f5c2b675-e04f-4544-8338-ab6dc4701d7f
@steveisok
steveisok
requested review from
a team and CopilotJuly 9, 2026 23:34
@dotnet-policy-service
dotnet-policy-serviceBot
commented
Jul 9, 2026

Copy link


Copy Markdown

Contributor
Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag

See info in area-owners.md if you want to be subscribed.
CopilotAI
reviewed
Jul 9, 2026
View reviewed changes
CopilotAI
left a comment


Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview
This PR adjusts the fixed virtual address used for the “SpecialDiagInfo” dump segment on Apple Silicon macOS so it stays within the 47-bit user-space address range accepted by lldb’s Mach-O core reader, while preserving the legacy address on x86_64 macOS.
Changes:
  • Use a 47-bit-valid SpecialDiagInfoAddress on macOS arm64 (0x00007ffffff10000).
  • Keep the legacy macOS x86_64 SpecialDiagInfoAddress unchanged (0x7fffffff10000000).
@build-analysisbuild-analysisBot
mentioned this pull request
Jul 10, 2026

Open

3 tasks

This was referenced Jul 10, 2026

Closed


Closed

@steveisok
steveisok
merged commit a8110f2
into
dotnet:mainJul 10, 2026

111 of 113 checks passed

@steveisok
steveisok
deleted the

fix-specialdiaginfo

branch
July 10, 2026 23:16
@dotnet-maestrodotnet-maestroBot
mentioned this pull request
Jul 11, 2026
 Merged

@dotnet-milestone-botdotnet-milestone-botBot
added this to the 11.0-preview7 milestone
Jul 11, 2026
eiriktsarpalis pushed a commit
that referenced
this pull request
Jul 15, 2026
@steveisok@eiriktsarpalis
createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS (#…
f4cab58
…130443)
## Summary
Fixes the createdump (write) side of the SpecialDiagInfo issue addressed
on the
reader side in dotnet/diagnostics#5823.
On Apple Silicon, the legacy macOS SpecialDiagInfo address
`0x7fffffff10000000`
is above the 47-bit user-space VM limit. createdump still writes a
segment at
that address, but lldb's MachO core reader refuses to return reads above
`0x7FFF_FFFFFFFF`, so SOS reports:
`Special diagnostics info read failed`
and falls through to the slower managed-side path (or fails outright on
older
builds without that fallback).
## Change
`src/coreclr/debug/createdump/specialdiaginfo.h` now selects the address
by arch
on macOS:
- **arm64 macOS** → `0x00007ffffff10000` (47-bit valid; same address
already
used on Linux/other 64-bit)
- **x86_64 macOS** → `0x7fffffff10000000` (legacy, unchanged)
All other platforms (Linux/other 64-bit, 32-bit) are unchanged.
The matching diagnostics reader (dotnet/diagnostics#5823) probes both
the new
and legacy addresses, so dumps produced by older createdump binaries
remain
readable — no regression.
## Notes
- `SpecialThreadInfoAddress` (`0x7fffffff00000000`) is intentionally
left as-is;
it's out of scope for this fix and lldb tolerates that region.
> [!NOTE]
> This PR description was drafted with GitHub Copilot.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

This was referenced Aug 6, 2026
 Merged

 Merged

max-charlamb added a commit
that referenced
this pull request
Aug 7, 2026
@max-charlamb
createdump: fix macOS arm64 thread IDs in LLDB (#131962)
f659b2c
## Summary
- write the macOS arm64 createdump thread-info region at a 47-bit-valid
address
- emit OS thread IDs using LLDB's `process metadata` `LC_NOTE` format
- this is for future support so we can eventually remove the
`SpecialThreadInfo`
- retain the existing special thread-info segment while consumers
migrate to the LLDB format
## Motivation
Apple Silicon LLDB rejects the legacy `0x7fffffff00000000` synthetic
segment and falls back to sequential thread IDs beginning at zero. SOS
then cannot correlate LLDB threads with runtime OS thread IDs or
retrieve the selected thread context.
Coordinated SOS reader change:
dotnet/diagnostics#5953
## Related precedent
This follows @steveisok's coordinated Apple Silicon fix for
`SpecialDiagInfoAddress`:
- runtime writer: #130443
- diagnostics readers: dotnet/diagnostics#5823
## Testing
Draft pending coordinated diagnostics validation on macOS arm64.
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 7805386d-16fd-4306-bcc9-54d4ea7b65cf
max-charlamb added a commit
to dotnet/diagnostics
that referenced
this pull request
Aug 10, 2026
@max-charlamb
SOS: read macOS arm64 thread metadata from a valid address (#5953)
1b6da39
## Summary
- read macOS arm64 createdump thread metadata from the new 47-bit-valid
address
- fall back to the legacy address for compatibility with existing
createdump output
- use the selected address for all subsequent thread-info entries
## Motivation
Apple Silicon LLDB rejects the legacy `0x7fffffff00000000` synthetic
segment and assigns sequential thread IDs beginning at zero. SOS cannot
then correlate LLDB threads with runtime OS thread IDs or retrieve the
selected thread context.
Coordinated writer change: dotnet/runtime#131962
## Related precedent
This follows @steveisok's coordinated Apple Silicon fix for
`SpecialDiagInfoAddress`:
- runtime writer: dotnet/runtime#130443
- diagnostics readers: #5823
## Testing
Draft pending coordinated macOS arm64 validation with the runtime writer
change.
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 7805386d-16fd-4306-bcc9-54d4ea7b65cf
@github-actionsgithub-actionsBot
locked and limited conversation to collaborators
Aug 11, 2026
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

Copilot code reviewCopilot
Copilot review effort
Applies to this pull request for everyone.Learn more about Copilot code review.
Copilot left review comments
@noahfalknoahfalknoahfalk approved these changes
@hoyosjshoyosjshoyosjs approved these changes

Assignees

@steveisoksteveisok

Labels

area-Diagnostics-coreclr

Projects


None yet


Milestone

11.0-preview7

Development

Successfully merging this pull request may close these issues.

4 participants

@steveisok@noahfalk@hoyosjs

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS - #130443
Merged
steveisok merged 1 commit into
dotnet:mainfrom 
steveisok:fix-specialdiaginfo
Jul 10, 2026
Merged
createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS#130443
steveisok merged 1 commit into
dotnet:mainfrom 
steveisok:fix-specialdiaginfo
Conversation
@steveisok
@steveisoksteveisok
commented
Jul 9, 2026

Copy link


Copy Markdown

Member
Summary
Fixes the createdump (write) side of the SpecialDiagInfo issue addressed on the

reader side in dotnet/diagnostics#5823.
On Apple Silicon, the legacy macOS SpecialDiagInfo address 0x7fffffff10000000

is above the 47-bit user-space VM limit. createdump still writes a segment at

that address, but lldb's MachO core reader refuses to return reads above
0x7FFF_FFFFFFFF, so SOS reports:
Special diagnostics info read failed
and falls through to the slower managed-side path (or fails outright on older

builds without that fallback).
Change
src/coreclr/debug/createdump/specialdiaginfo.h now selects the address by arch

on macOS:
  • arm64 macOS → 0x00007ffffff10000 (47-bit valid; same address already
    
used on Linux/other 64-bit)
  • x86_64 macOS → 0x7fffffff10000000 (legacy, unchanged)
All other platforms (Linux/other 64-bit, 32-bit) are unchanged.
The matching diagnostics reader (dotnet/diagnostics#5823) probes both the new

and legacy addresses, so dumps produced by older createdump binaries remain

readable — no regression.
Notes
  • SpecialThreadInfoAddress (0x7fffffff00000000) is intentionally left as-is;
    
it's out of scope for this fix and lldb tolerates that region.
Note
This PR description was drafted with GitHub Copilot.
@steveisok
createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS
ba64543
The legacy macOS SpecialDiagInfo address 0x7fffffff10000000 is above Apple
Silicon's 47-bit user-space VM limit, so lldb's MachO core reader refuses to
return the segment and SOS reports "Special diagnostics info read failed".
Write the segment at the 47-bit-valid 0x00007ffffff10000 on arm64 macOS
(the same address already used on Linux 64-bit) while keeping the legacy
address on x86_64 macOS. This is the createdump-side counterpart to
dotnet/diagnostics#5823, whose reader probes both the new and legacy
addresses so older dumps remain readable.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: f5c2b675-e04f-4544-8338-ab6dc4701d7f
@steveisok
steveisok
requested review from
a team and CopilotJuly 9, 2026 23:34
@dotnet-policy-service
dotnet-policy-serviceBot
commented
Jul 9, 2026

Copy link


Copy Markdown

Contributor
Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag

See info in area-owners.md if you want to be subscribed.
CopilotAI
reviewed
Jul 9, 2026
View reviewed changes
CopilotAI
left a comment


Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview
This PR adjusts the fixed virtual address used for the “SpecialDiagInfo” dump segment on Apple Silicon macOS so it stays within the 47-bit user-space address range accepted by lldb’s Mach-O core reader, while preserving the legacy address on x86_64 macOS.
Changes:
  • Use a 47-bit-valid SpecialDiagInfoAddress on macOS arm64 (0x00007ffffff10000).
  • Keep the legacy macOS x86_64 SpecialDiagInfoAddress unchanged (0x7fffffff10000000).
@build-analysisbuild-analysisBot
mentioned this pull request
Jul 10, 2026

Open

3 tasks

This was referenced Jul 10, 2026

Closed


Closed

@steveisok
steveisok
merged commit a8110f2
into
dotnet:mainJul 10, 2026

111 of 113 checks passed

@steveisok
steveisok
deleted the

fix-specialdiaginfo

branch
July 10, 2026 23:16
@dotnet-maestrodotnet-maestroBot
mentioned this pull request
Jul 11, 2026
 Merged

@dotnet-milestone-botdotnet-milestone-botBot
added this to the 11.0-preview7 milestone
Jul 11, 2026
eiriktsarpalis pushed a commit
that referenced
this pull request
Jul 15, 2026
@steveisok@eiriktsarpalis
createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS (#…
f4cab58
…130443)
## Summary
Fixes the createdump (write) side of the SpecialDiagInfo issue addressed
on the
reader side in dotnet/diagnostics#5823.
On Apple Silicon, the legacy macOS SpecialDiagInfo address
`0x7fffffff10000000`
is above the 47-bit user-space VM limit. createdump still writes a
segment at
that address, but lldb's MachO core reader refuses to return reads above
`0x7FFF_FFFFFFFF`, so SOS reports:
`Special diagnostics info read failed`
and falls through to the slower managed-side path (or fails outright on
older
builds without that fallback).
## Change
`src/coreclr/debug/createdump/specialdiaginfo.h` now selects the address
by arch
on macOS:
- **arm64 macOS** → `0x00007ffffff10000` (47-bit valid; same address
already
used on Linux/other 64-bit)
- **x86_64 macOS** → `0x7fffffff10000000` (legacy, unchanged)
All other platforms (Linux/other 64-bit, 32-bit) are unchanged.
The matching diagnostics reader (dotnet/diagnostics#5823) probes both
the new
and legacy addresses, so dumps produced by older createdump binaries
remain
readable — no regression.
## Notes
- `SpecialThreadInfoAddress` (`0x7fffffff00000000`) is intentionally
left as-is;
it's out of scope for this fix and lldb tolerates that region.
> [!NOTE]
> This PR description was drafted with GitHub Copilot.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

This was referenced Aug 6, 2026
 Merged

 Merged

max-charlamb added a commit
that referenced
this pull request
Aug 7, 2026
@max-charlamb
createdump: fix macOS arm64 thread IDs in LLDB (#131962)
f659b2c
## Summary
- write the macOS arm64 createdump thread-info region at a 47-bit-valid
address
- emit OS thread IDs using LLDB's `process metadata` `LC_NOTE` format
- this is for future support so we can eventually remove the
`SpecialThreadInfo`
- retain the existing special thread-info segment while consumers
migrate to the LLDB format
## Motivation
Apple Silicon LLDB rejects the legacy `0x7fffffff00000000` synthetic
segment and falls back to sequential thread IDs beginning at zero. SOS
then cannot correlate LLDB threads with runtime OS thread IDs or
retrieve the selected thread context.
Coordinated SOS reader change:
dotnet/diagnostics#5953
## Related precedent
This follows @steveisok's coordinated Apple Silicon fix for
`SpecialDiagInfoAddress`:
- runtime writer: #130443
- diagnostics readers: dotnet/diagnostics#5823
## Testing
Draft pending coordinated diagnostics validation on macOS arm64.
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 7805386d-16fd-4306-bcc9-54d4ea7b65cf
max-charlamb added a commit
to dotnet/diagnostics
that referenced
this pull request
Aug 10, 2026
@max-charlamb
SOS: read macOS arm64 thread metadata from a valid address (#5953)
1b6da39
## Summary
- read macOS arm64 createdump thread metadata from the new 47-bit-valid
address
- fall back to the legacy address for compatibility with existing
createdump output
- use the selected address for all subsequent thread-info entries
## Motivation
Apple Silicon LLDB rejects the legacy `0x7fffffff00000000` synthetic
segment and assigns sequential thread IDs beginning at zero. SOS cannot
then correlate LLDB threads with runtime OS thread IDs or retrieve the
selected thread context.
Coordinated writer change: dotnet/runtime#131962
## Related precedent
This follows @steveisok's coordinated Apple Silicon fix for
`SpecialDiagInfoAddress`:
- runtime writer: dotnet/runtime#130443
- diagnostics readers: #5823
## Testing
Draft pending coordinated macOS arm64 validation with the runtime writer
change.
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 7805386d-16fd-4306-bcc9-54d4ea7b65cf
@github-actionsgithub-actionsBot
locked and limited conversation to collaborators
Aug 11, 2026
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

Copilot code reviewCopilot
Copilot review effort
Applies to this pull request for everyone.Learn more about Copilot code review.
Copilot left review comments
@noahfalknoahfalknoahfalk approved these changes
@hoyosjshoyosjshoyosjs approved these changes

Assignees

@steveisoksteveisok

Labels

area-Diagnostics-coreclr

Projects


None yet


Milestone

11.0-preview7

Development

Successfully merging this pull request may close these issues.

4 participants

@steveisok@noahfalk@hoyosjs

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS - #130443
Merged
steveisok merged 1 commit into
dotnet:mainfrom 
steveisok:fix-specialdiaginfo
Jul 10, 2026
Merged
createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS#130443
steveisok merged 1 commit into
dotnet:mainfrom 
steveisok:fix-specialdiaginfo
Conversation
@steveisok
@steveisoksteveisok
commented
Jul 9, 2026

Copy link


Copy Markdown

Member
Summary
Fixes the createdump (write) side of the SpecialDiagInfo issue addressed on the

reader side in dotnet/diagnostics#5823.
On Apple Silicon, the legacy macOS SpecialDiagInfo address 0x7fffffff10000000

is above the 47-bit user-space VM limit. createdump still writes a segment at

that address, but lldb's MachO core reader refuses to return reads above
0x7FFF_FFFFFFFF, so SOS reports:
Special diagnostics info read failed
and falls through to the slower managed-side path (or fails outright on older

builds without that fallback).
Change
src/coreclr/debug/createdump/specialdiaginfo.h now selects the address by arch

on macOS:
  • arm64 macOS → 0x00007ffffff10000 (47-bit valid; same address already
    
used on Linux/other 64-bit)
  • x86_64 macOS → 0x7fffffff10000000 (legacy, unchanged)
All other platforms (Linux/other 64-bit, 32-bit) are unchanged.
The matching diagnostics reader (dotnet/diagnostics#5823) probes both the new

and legacy addresses, so dumps produced by older createdump binaries remain

readable — no regression.
Notes
  • SpecialThreadInfoAddress (0x7fffffff00000000) is intentionally left as-is;
    
it's out of scope for this fix and lldb tolerates that region.
Note
This PR description was drafted with GitHub Copilot.
@steveisok
createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS
ba64543
The legacy macOS SpecialDiagInfo address 0x7fffffff10000000 is above Apple
Silicon's 47-bit user-space VM limit, so lldb's MachO core reader refuses to
return the segment and SOS reports "Special diagnostics info read failed".
Write the segment at the 47-bit-valid 0x00007ffffff10000 on arm64 macOS
(the same address already used on Linux 64-bit) while keeping the legacy
address on x86_64 macOS. This is the createdump-side counterpart to
dotnet/diagnostics#5823, whose reader probes both the new and legacy
addresses so older dumps remain readable.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: f5c2b675-e04f-4544-8338-ab6dc4701d7f
@steveisok
steveisok
requested review from
a team and CopilotJuly 9, 2026 23:34
@dotnet-policy-service
dotnet-policy-serviceBot
commented
Jul 9, 2026

Copy link


Copy Markdown

Contributor
Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag

See info in area-owners.md if you want to be subscribed.
CopilotAI
reviewed
Jul 9, 2026
View reviewed changes
CopilotAI
left a comment


Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview
This PR adjusts the fixed virtual address used for the “SpecialDiagInfo” dump segment on Apple Silicon macOS so it stays within the 47-bit user-space address range accepted by lldb’s Mach-O core reader, while preserving the legacy address on x86_64 macOS.
Changes:
  • Use a 47-bit-valid SpecialDiagInfoAddress on macOS arm64 (0x00007ffffff10000).
  • Keep the legacy macOS x86_64 SpecialDiagInfoAddress unchanged (0x7fffffff10000000).
@build-analysisbuild-analysisBot
mentioned this pull request
Jul 10, 2026

Open

3 tasks

This was referenced Jul 10, 2026

Closed


Closed

@steveisok
steveisok
merged commit a8110f2
into
dotnet:mainJul 10, 2026

111 of 113 checks passed

@steveisok
steveisok
deleted the

fix-specialdiaginfo

branch
July 10, 2026 23:16
@dotnet-maestrodotnet-maestroBot
mentioned this pull request
Jul 11, 2026
 Merged

@dotnet-milestone-botdotnet-milestone-botBot
added this to the 11.0-preview7 milestone
Jul 11, 2026
eiriktsarpalis pushed a commit
that referenced
this pull request
Jul 15, 2026
@steveisok@eiriktsarpalis
createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS (#…
f4cab58
…130443)
## Summary
Fixes the createdump (write) side of the SpecialDiagInfo issue addressed
on the
reader side in dotnet/diagnostics#5823.
On Apple Silicon, the legacy macOS SpecialDiagInfo address
`0x7fffffff10000000`
is above the 47-bit user-space VM limit. createdump still writes a
segment at
that address, but lldb's MachO core reader refuses to return reads above
`0x7FFF_FFFFFFFF`, so SOS reports:
`Special diagnostics info read failed`
and falls through to the slower managed-side path (or fails outright on
older
builds without that fallback).
## Change
`src/coreclr/debug/createdump/specialdiaginfo.h` now selects the address
by arch
on macOS:
- **arm64 macOS** → `0x00007ffffff10000` (47-bit valid; same address
already
used on Linux/other 64-bit)
- **x86_64 macOS** → `0x7fffffff10000000` (legacy, unchanged)
All other platforms (Linux/other 64-bit, 32-bit) are unchanged.
The matching diagnostics reader (dotnet/diagnostics#5823) probes both
the new
and legacy addresses, so dumps produced by older createdump binaries
remain
readable — no regression.
## Notes
- `SpecialThreadInfoAddress` (`0x7fffffff00000000`) is intentionally
left as-is;
it's out of scope for this fix and lldb tolerates that region.
> [!NOTE]
> This PR description was drafted with GitHub Copilot.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

This was referenced Aug 6, 2026
 Merged

 Merged

max-charlamb added a commit
that referenced
this pull request
Aug 7, 2026
@max-charlamb
createdump: fix macOS arm64 thread IDs in LLDB (#131962)
f659b2c
## Summary
- write the macOS arm64 createdump thread-info region at a 47-bit-valid
address
- emit OS thread IDs using LLDB's `process metadata` `LC_NOTE` format
- this is for future support so we can eventually remove the
`SpecialThreadInfo`
- retain the existing special thread-info segment while consumers
migrate to the LLDB format
## Motivation
Apple Silicon LLDB rejects the legacy `0x7fffffff00000000` synthetic
segment and falls back to sequential thread IDs beginning at zero. SOS
then cannot correlate LLDB threads with runtime OS thread IDs or
retrieve the selected thread context.
Coordinated SOS reader change:
dotnet/diagnostics#5953
## Related precedent
This follows @steveisok's coordinated Apple Silicon fix for
`SpecialDiagInfoAddress`:
- runtime writer: #130443
- diagnostics readers: dotnet/diagnostics#5823
## Testing
Draft pending coordinated diagnostics validation on macOS arm64.
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 7805386d-16fd-4306-bcc9-54d4ea7b65cf
max-charlamb added a commit
to dotnet/diagnostics
that referenced
this pull request
Aug 10, 2026
@max-charlamb
SOS: read macOS arm64 thread metadata from a valid address (#5953)
1b6da39
## Summary
- read macOS arm64 createdump thread metadata from the new 47-bit-valid
address
- fall back to the legacy address for compatibility with existing
createdump output
- use the selected address for all subsequent thread-info entries
## Motivation
Apple Silicon LLDB rejects the legacy `0x7fffffff00000000` synthetic
segment and assigns sequential thread IDs beginning at zero. SOS cannot
then correlate LLDB threads with runtime OS thread IDs or retrieve the
selected thread context.
Coordinated writer change: dotnet/runtime#131962
## Related precedent
This follows @steveisok's coordinated Apple Silicon fix for
`SpecialDiagInfoAddress`:
- runtime writer: dotnet/runtime#130443
- diagnostics readers: #5823
## Testing
Draft pending coordinated macOS arm64 validation with the runtime writer
change.
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 7805386d-16fd-4306-bcc9-54d4ea7b65cf
@github-actionsgithub-actionsBot
locked and limited conversation to collaborators
Aug 11, 2026
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

Copilot code reviewCopilot
Copilot review effort
Applies to this pull request for everyone.Learn more about Copilot code review.
Copilot left review comments
@noahfalknoahfalknoahfalk approved these changes
@hoyosjshoyosjshoyosjs approved these changes

Assignees

@steveisoksteveisok

Labels

area-Diagnostics-coreclr

Projects


None yet


Milestone

11.0-preview7

Development

Successfully merging this pull request may close these issues.

4 participants

@steveisok@noahfalk@hoyosjs

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS - #130443
Merged
steveisok merged 1 commit into
dotnet:mainfrom 
steveisok:fix-specialdiaginfo
Jul 10, 2026
Merged
createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS#130443
steveisok merged 1 commit into
dotnet:mainfrom 
steveisok:fix-specialdiaginfo
Conversation
@steveisok
@steveisoksteveisok
commented
Jul 9, 2026

Copy link


Copy Markdown

Member
Summary
Fixes the createdump (write) side of the SpecialDiagInfo issue addressed on the

reader side in dotnet/diagnostics#5823.
On Apple Silicon, the legacy macOS SpecialDiagInfo address 0x7fffffff10000000

is above the 47-bit user-space VM limit. createdump still writes a segment at

that address, but lldb's MachO core reader refuses to return reads above
0x7FFF_FFFFFFFF, so SOS reports:
Special diagnostics info read failed
and falls through to the slower managed-side path (or fails outright on older

builds without that fallback).
Change
src/coreclr/debug/createdump/specialdiaginfo.h now selects the address by arch

on macOS:
  • arm64 macOS → 0x00007ffffff10000 (47-bit valid; same address already
    
used on Linux/other 64-bit)
  • x86_64 macOS → 0x7fffffff10000000 (legacy, unchanged)
All other platforms (Linux/other 64-bit, 32-bit) are unchanged.
The matching diagnostics reader (dotnet/diagnostics#5823) probes both the new

and legacy addresses, so dumps produced by older createdump binaries remain

readable — no regression.
Notes
  • SpecialThreadInfoAddress (0x7fffffff00000000) is intentionally left as-is;
    
it's out of scope for this fix and lldb tolerates that region.
Note
This PR description was drafted with GitHub Copilot.
@steveisok
createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS
ba64543
The legacy macOS SpecialDiagInfo address 0x7fffffff10000000 is above Apple
Silicon's 47-bit user-space VM limit, so lldb's MachO core reader refuses to
return the segment and SOS reports "Special diagnostics info read failed".
Write the segment at the 47-bit-valid 0x00007ffffff10000 on arm64 macOS
(the same address already used on Linux 64-bit) while keeping the legacy
address on x86_64 macOS. This is the createdump-side counterpart to
dotnet/diagnostics#5823, whose reader probes both the new and legacy
addresses so older dumps remain readable.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: f5c2b675-e04f-4544-8338-ab6dc4701d7f
@steveisok
steveisok
requested review from
a team and CopilotJuly 9, 2026 23:34
@dotnet-policy-service
dotnet-policy-serviceBot
commented
Jul 9, 2026

Copy link


Copy Markdown

Contributor
Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag

See info in area-owners.md if you want to be subscribed.
CopilotAI
reviewed
Jul 9, 2026
View reviewed changes
CopilotAI
left a comment


Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview
This PR adjusts the fixed virtual address used for the “SpecialDiagInfo” dump segment on Apple Silicon macOS so it stays within the 47-bit user-space address range accepted by lldb’s Mach-O core reader, while preserving the legacy address on x86_64 macOS.
Changes:
  • Use a 47-bit-valid SpecialDiagInfoAddress on macOS arm64 (0x00007ffffff10000).
  • Keep the legacy macOS x86_64 SpecialDiagInfoAddress unchanged (0x7fffffff10000000).
@build-analysisbuild-analysisBot
mentioned this pull request
Jul 10, 2026

Open

3 tasks

This was referenced Jul 10, 2026

Closed


Closed

@steveisok
steveisok
merged commit a8110f2
into
dotnet:mainJul 10, 2026

111 of 113 checks passed

@steveisok
steveisok
deleted the

fix-specialdiaginfo

branch
July 10, 2026 23:16
@dotnet-maestrodotnet-maestroBot
mentioned this pull request
Jul 11, 2026
 Merged

@dotnet-milestone-botdotnet-milestone-botBot
added this to the 11.0-preview7 milestone
Jul 11, 2026
eiriktsarpalis pushed a commit
that referenced
this pull request
Jul 15, 2026
@steveisok@eiriktsarpalis
createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS (#…
f4cab58
…130443)
## Summary
Fixes the createdump (write) side of the SpecialDiagInfo issue addressed
on the
reader side in dotnet/diagnostics#5823.
On Apple Silicon, the legacy macOS SpecialDiagInfo address
`0x7fffffff10000000`
is above the 47-bit user-space VM limit. createdump still writes a
segment at
that address, but lldb's MachO core reader refuses to return reads above
`0x7FFF_FFFFFFFF`, so SOS reports:
`Special diagnostics info read failed`
and falls through to the slower managed-side path (or fails outright on
older
builds without that fallback).
## Change
`src/coreclr/debug/createdump/specialdiaginfo.h` now selects the address
by arch
on macOS:
- **arm64 macOS** → `0x00007ffffff10000` (47-bit valid; same address
already
used on Linux/other 64-bit)
- **x86_64 macOS** → `0x7fffffff10000000` (legacy, unchanged)
All other platforms (Linux/other 64-bit, 32-bit) are unchanged.
The matching diagnostics reader (dotnet/diagnostics#5823) probes both
the new
and legacy addresses, so dumps produced by older createdump binaries
remain
readable — no regression.
## Notes
- `SpecialThreadInfoAddress` (`0x7fffffff00000000`) is intentionally
left as-is;
it's out of scope for this fix and lldb tolerates that region.
> [!NOTE]
> This PR description was drafted with GitHub Copilot.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

This was referenced Aug 6, 2026
 Merged

 Merged

max-charlamb added a commit
that referenced
this pull request
Aug 7, 2026
@max-charlamb
createdump: fix macOS arm64 thread IDs in LLDB (#131962)
f659b2c
## Summary
- write the macOS arm64 createdump thread-info region at a 47-bit-valid
address
- emit OS thread IDs using LLDB's `process metadata` `LC_NOTE` format
- this is for future support so we can eventually remove the
`SpecialThreadInfo`
- retain the existing special thread-info segment while consumers
migrate to the LLDB format
## Motivation
Apple Silicon LLDB rejects the legacy `0x7fffffff00000000` synthetic
segment and falls back to sequential thread IDs beginning at zero. SOS
then cannot correlate LLDB threads with runtime OS thread IDs or
retrieve the selected thread context.
Coordinated SOS reader change:
dotnet/diagnostics#5953
## Related precedent
This follows @steveisok's coordinated Apple Silicon fix for
`SpecialDiagInfoAddress`:
- runtime writer: #130443
- diagnostics readers: dotnet/diagnostics#5823
## Testing
Draft pending coordinated diagnostics validation on macOS arm64.
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 7805386d-16fd-4306-bcc9-54d4ea7b65cf
max-charlamb added a commit
to dotnet/diagnostics
that referenced
this pull request
Aug 10, 2026
@max-charlamb
SOS: read macOS arm64 thread metadata from a valid address (#5953)
1b6da39
## Summary
- read macOS arm64 createdump thread metadata from the new 47-bit-valid
address
- fall back to the legacy address for compatibility with existing
createdump output
- use the selected address for all subsequent thread-info entries
## Motivation
Apple Silicon LLDB rejects the legacy `0x7fffffff00000000` synthetic
segment and assigns sequential thread IDs beginning at zero. SOS cannot
then correlate LLDB threads with runtime OS thread IDs or retrieve the
selected thread context.
Coordinated writer change: dotnet/runtime#131962
## Related precedent
This follows @steveisok's coordinated Apple Silicon fix for
`SpecialDiagInfoAddress`:
- runtime writer: dotnet/runtime#130443
- diagnostics readers: #5823
## Testing
Draft pending coordinated macOS arm64 validation with the runtime writer
change.
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 7805386d-16fd-4306-bcc9-54d4ea7b65cf
@github-actionsgithub-actionsBot
locked and limited conversation to collaborators
Aug 11, 2026
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

Copilot code reviewCopilot
Copilot review effort
Applies to this pull request for everyone.Learn more about Copilot code review.
Copilot left review comments
@noahfalknoahfalknoahfalk approved these changes
@hoyosjshoyosjshoyosjs approved these changes

Assignees

@steveisoksteveisok

Labels

area-Diagnostics-coreclr

Projects


None yet


Milestone

11.0-preview7

Development

Successfully merging this pull request may close these issues.

4 participants

@steveisok@noahfalk@hoyosjs

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS - #130443
Merged
steveisok merged 1 commit into
dotnet:mainfrom 
steveisok:fix-specialdiaginfo
Jul 10, 2026
Merged
createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS#130443
steveisok merged 1 commit into
dotnet:mainfrom 
steveisok:fix-specialdiaginfo
Conversation
@steveisok
@steveisoksteveisok
commented
Jul 9, 2026

Copy link


Copy Markdown

Member
Summary
Fixes the createdump (write) side of the SpecialDiagInfo issue addressed on the

reader side in dotnet/diagnostics#5823.
On Apple Silicon, the legacy macOS SpecialDiagInfo address 0x7fffffff10000000

is above the 47-bit user-space VM limit. createdump still writes a segment at

that address, but lldb's MachO core reader refuses to return reads above
0x7FFF_FFFFFFFF, so SOS reports:
Special diagnostics info read failed
and falls through to the slower managed-side path (or fails outright on older

builds without that fallback).
Change
src/coreclr/debug/createdump/specialdiaginfo.h now selects the address by arch

on macOS:
  • arm64 macOS → 0x00007ffffff10000 (47-bit valid; same address already
    
used on Linux/other 64-bit)
  • x86_64 macOS → 0x7fffffff10000000 (legacy, unchanged)
All other platforms (Linux/other 64-bit, 32-bit) are unchanged.
The matching diagnostics reader (dotnet/diagnostics#5823) probes both the new

and legacy addresses, so dumps produced by older createdump binaries remain

readable — no regression.
Notes
  • SpecialThreadInfoAddress (0x7fffffff00000000) is intentionally left as-is;
    
it's out of scope for this fix and lldb tolerates that region.
Note
This PR description was drafted with GitHub Copilot.
@steveisok
createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS
ba64543
The legacy macOS SpecialDiagInfo address 0x7fffffff10000000 is above Apple
Silicon's 47-bit user-space VM limit, so lldb's MachO core reader refuses to
return the segment and SOS reports "Special diagnostics info read failed".
Write the segment at the 47-bit-valid 0x00007ffffff10000 on arm64 macOS
(the same address already used on Linux 64-bit) while keeping the legacy
address on x86_64 macOS. This is the createdump-side counterpart to
dotnet/diagnostics#5823, whose reader probes both the new and legacy
addresses so older dumps remain readable.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: f5c2b675-e04f-4544-8338-ab6dc4701d7f
@steveisok
steveisok
requested review from
a team and CopilotJuly 9, 2026 23:34
@dotnet-policy-service
dotnet-policy-serviceBot
commented
Jul 9, 2026

Copy link


Copy Markdown

Contributor
Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag

See info in area-owners.md if you want to be subscribed.
CopilotAI
reviewed
Jul 9, 2026
View reviewed changes
CopilotAI
left a comment


Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview
This PR adjusts the fixed virtual address used for the “SpecialDiagInfo” dump segment on Apple Silicon macOS so it stays within the 47-bit user-space address range accepted by lldb’s Mach-O core reader, while preserving the legacy address on x86_64 macOS.
Changes:
  • Use a 47-bit-valid SpecialDiagInfoAddress on macOS arm64 (0x00007ffffff10000).
  • Keep the legacy macOS x86_64 SpecialDiagInfoAddress unchanged (0x7fffffff10000000).
@build-analysisbuild-analysisBot
mentioned this pull request
Jul 10, 2026

Open

3 tasks

This was referenced Jul 10, 2026

Closed


Closed

@steveisok
steveisok
merged commit a8110f2
into
dotnet:mainJul 10, 2026

111 of 113 checks passed

@steveisok
steveisok
deleted the

fix-specialdiaginfo

branch
July 10, 2026 23:16
@dotnet-maestrodotnet-maestroBot
mentioned this pull request
Jul 11, 2026
 Merged

@dotnet-milestone-botdotnet-milestone-botBot
added this to the 11.0-preview7 milestone
Jul 11, 2026
eiriktsarpalis pushed a commit
that referenced
this pull request
Jul 15, 2026
@steveisok@eiriktsarpalis
createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS (#…
f4cab58
…130443)
## Summary
Fixes the createdump (write) side of the SpecialDiagInfo issue addressed
on the
reader side in dotnet/diagnostics#5823.
On Apple Silicon, the legacy macOS SpecialDiagInfo address
`0x7fffffff10000000`
is above the 47-bit user-space VM limit. createdump still writes a
segment at
that address, but lldb's MachO core reader refuses to return reads above
`0x7FFF_FFFFFFFF`, so SOS reports:
`Special diagnostics info read failed`
and falls through to the slower managed-side path (or fails outright on
older
builds without that fallback).
## Change
`src/coreclr/debug/createdump/specialdiaginfo.h` now selects the address
by arch
on macOS:
- **arm64 macOS** → `0x00007ffffff10000` (47-bit valid; same address
already
used on Linux/other 64-bit)
- **x86_64 macOS** → `0x7fffffff10000000` (legacy, unchanged)
All other platforms (Linux/other 64-bit, 32-bit) are unchanged.
The matching diagnostics reader (dotnet/diagnostics#5823) probes both
the new
and legacy addresses, so dumps produced by older createdump binaries
remain
readable — no regression.
## Notes
- `SpecialThreadInfoAddress` (`0x7fffffff00000000`) is intentionally
left as-is;
it's out of scope for this fix and lldb tolerates that region.
> [!NOTE]
> This PR description was drafted with GitHub Copilot.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

This was referenced Aug 6, 2026
 Merged

 Merged

max-charlamb added a commit
that referenced
this pull request
Aug 7, 2026
@max-charlamb
createdump: fix macOS arm64 thread IDs in LLDB (#131962)
f659b2c
## Summary
- write the macOS arm64 createdump thread-info region at a 47-bit-valid
address
- emit OS thread IDs using LLDB's `process metadata` `LC_NOTE` format
- this is for future support so we can eventually remove the
`SpecialThreadInfo`
- retain the existing special thread-info segment while consumers
migrate to the LLDB format
## Motivation
Apple Silicon LLDB rejects the legacy `0x7fffffff00000000` synthetic
segment and falls back to sequential thread IDs beginning at zero. SOS
then cannot correlate LLDB threads with runtime OS thread IDs or
retrieve the selected thread context.
Coordinated SOS reader change:
dotnet/diagnostics#5953
## Related precedent
This follows @steveisok's coordinated Apple Silicon fix for
`SpecialDiagInfoAddress`:
- runtime writer: #130443
- diagnostics readers: dotnet/diagnostics#5823
## Testing
Draft pending coordinated diagnostics validation on macOS arm64.
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 7805386d-16fd-4306-bcc9-54d4ea7b65cf
max-charlamb added a commit
to dotnet/diagnostics
that referenced
this pull request
Aug 10, 2026
@max-charlamb
SOS: read macOS arm64 thread metadata from a valid address (#5953)
1b6da39
## Summary
- read macOS arm64 createdump thread metadata from the new 47-bit-valid
address
- fall back to the legacy address for compatibility with existing
createdump output
- use the selected address for all subsequent thread-info entries
## Motivation
Apple Silicon LLDB rejects the legacy `0x7fffffff00000000` synthetic
segment and assigns sequential thread IDs beginning at zero. SOS cannot
then correlate LLDB threads with runtime OS thread IDs or retrieve the
selected thread context.
Coordinated writer change: dotnet/runtime#131962
## Related precedent
This follows @steveisok's coordinated Apple Silicon fix for
`SpecialDiagInfoAddress`:
- runtime writer: dotnet/runtime#130443
- diagnostics readers: #5823
## Testing
Draft pending coordinated macOS arm64 validation with the runtime writer
change.
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 7805386d-16fd-4306-bcc9-54d4ea7b65cf
@github-actionsgithub-actionsBot
locked and limited conversation to collaborators
Aug 11, 2026
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

Copilot code reviewCopilot
Copilot review effort
Applies to this pull request for everyone.Learn more about Copilot code review.
Copilot left review comments
@noahfalknoahfalknoahfalk approved these changes
@hoyosjshoyosjshoyosjs approved these changes

Assignees

@steveisoksteveisok

Labels

area-Diagnostics-coreclr

Projects


None yet


Milestone

11.0-preview7

Development

Successfully merging this pull request may close these issues.

4 participants

@steveisok@noahfalk@hoyosjs

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS - #130443
Merged
steveisok merged 1 commit into
dotnet:mainfrom 
steveisok:fix-specialdiaginfo
Jul 10, 2026
Merged
createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS#130443
steveisok merged 1 commit into
dotnet:mainfrom 
steveisok:fix-specialdiaginfo
Conversation
@steveisok
@steveisoksteveisok
commented
Jul 9, 2026

Copy link


Copy Markdown

Member
Summary
Fixes the createdump (write) side of the SpecialDiagInfo issue addressed on the

reader side in dotnet/diagnostics#5823.
On Apple Silicon, the legacy macOS SpecialDiagInfo address 0x7fffffff10000000

is above the 47-bit user-space VM limit. createdump still writes a segment at

that address, but lldb's MachO core reader refuses to return reads above
0x7FFF_FFFFFFFF, so SOS reports:
Special diagnostics info read failed
and falls through to the slower managed-side path (or fails outright on older

builds without that fallback).
Change
src/coreclr/debug/createdump/specialdiaginfo.h now selects the address by arch

on macOS:
  • arm64 macOS → 0x00007ffffff10000 (47-bit valid; same address already
    
used on Linux/other 64-bit)
  • x86_64 macOS → 0x7fffffff10000000 (legacy, unchanged)
All other platforms (Linux/other 64-bit, 32-bit) are unchanged.
The matching diagnostics reader (dotnet/diagnostics#5823) probes both the new

and legacy addresses, so dumps produced by older createdump binaries remain

readable — no regression.
Notes
  • SpecialThreadInfoAddress (0x7fffffff00000000) is intentionally left as-is;
    
it's out of scope for this fix and lldb tolerates that region.
Note
This PR description was drafted with GitHub Copilot.
@steveisok
createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS
ba64543
The legacy macOS SpecialDiagInfo address 0x7fffffff10000000 is above Apple
Silicon's 47-bit user-space VM limit, so lldb's MachO core reader refuses to
return the segment and SOS reports "Special diagnostics info read failed".
Write the segment at the 47-bit-valid 0x00007ffffff10000 on arm64 macOS
(the same address already used on Linux 64-bit) while keeping the legacy
address on x86_64 macOS. This is the createdump-side counterpart to
dotnet/diagnostics#5823, whose reader probes both the new and legacy
addresses so older dumps remain readable.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: f5c2b675-e04f-4544-8338-ab6dc4701d7f
@steveisok
steveisok
requested review from
a team and CopilotJuly 9, 2026 23:34
@dotnet-policy-service
dotnet-policy-serviceBot
commented
Jul 9, 2026

Copy link


Copy Markdown

Contributor
Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag

See info in area-owners.md if you want to be subscribed.
CopilotAI
reviewed
Jul 9, 2026
View reviewed changes
CopilotAI
left a comment


Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview
This PR adjusts the fixed virtual address used for the “SpecialDiagInfo” dump segment on Apple Silicon macOS so it stays within the 47-bit user-space address range accepted by lldb’s Mach-O core reader, while preserving the legacy address on x86_64 macOS.
Changes:
  • Use a 47-bit-valid SpecialDiagInfoAddress on macOS arm64 (0x00007ffffff10000).
  • Keep the legacy macOS x86_64 SpecialDiagInfoAddress unchanged (0x7fffffff10000000).
@build-analysisbuild-analysisBot
mentioned this pull request
Jul 10, 2026

Open

3 tasks

This was referenced Jul 10, 2026

Closed


Closed

@steveisok
steveisok
merged commit a8110f2
into
dotnet:mainJul 10, 2026

111 of 113 checks passed

@steveisok
steveisok
deleted the

fix-specialdiaginfo

branch
July 10, 2026 23:16
@dotnet-maestrodotnet-maestroBot
mentioned this pull request
Jul 11, 2026
 Merged

@dotnet-milestone-botdotnet-milestone-botBot
added this to the 11.0-preview7 milestone
Jul 11, 2026
eiriktsarpalis pushed a commit
that referenced
this pull request
Jul 15, 2026
@steveisok@eiriktsarpalis
createdump: use 47-bit-valid SpecialDiagInfo address on arm64 macOS (#…
f4cab58
…130443)
## Summary
Fixes the createdump (write) side of the SpecialDiagInfo issue addressed
on the
reader side in dotnet/diagnostics#5823.
On Apple Silicon, the legacy macOS SpecialDiagInfo address
`0x7fffffff10000000`
is above the 47-bit user-space VM limit. createdump still writes a
segment at
that address, but lldb's MachO core reader refuses to return reads above
`0x7FFF_FFFFFFFF`, so SOS reports:
`Special diagnostics info read failed`
and falls through to the slower managed-side path (or fails outright on
older
builds without that fallback).
## Change
`src/coreclr/debug/createdump/specialdiaginfo.h` now selects the address
by arch
on macOS:
- **arm64 macOS** → `0x00007ffffff10000` (47-bit valid; same address
already
used on Linux/other 64-bit)
- **x86_64 macOS** → `0x7fffffff10000000` (legacy, unchanged)
All other platforms (Linux/other 64-bit, 32-bit) are unchanged.
The matching diagnostics reader (dotnet/diagnostics#5823) probes both
the new
and legacy addresses, so dumps produced by older createdump binaries
remain
readable — no regression.
## Notes
- `SpecialThreadInfoAddress` (`0x7fffffff00000000`) is intentionally
left as-is;
it's out of scope for this fix and lldb tolerates that region.
> [!NOTE]
> This PR description was drafted with GitHub Copilot.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

This was referenced Aug 6, 2026
 Merged

 Merged

max-charlamb added a commit
that referenced
this pull request
Aug 7, 2026
@max-charlamb
createdump: fix macOS arm64 thread IDs in LLDB (#131962)
f659b2c
## Summary
- write the macOS arm64 createdump thread-info region at a 47-bit-valid
address
- emit OS thread IDs using LLDB's `process metadata` `LC_NOTE` format
- this is for future support so we can eventually remove the
`SpecialThreadInfo`
- retain the existing special thread-info segment while consumers
migrate to the LLDB format
## Motivation
Apple Silicon LLDB rejects the legacy `0x7fffffff00000000` synthetic
segment and falls back to sequential thread IDs beginning at zero. SOS
then cannot correlate LLDB threads with runtime OS thread IDs or
retrieve the selected thread context.
Coordinated SOS reader change:
dotnet/diagnostics#5953
## Related precedent
This follows @steveisok's coordinated Apple Silicon fix for
`SpecialDiagInfoAddress`:
- runtime writer: #130443
- diagnostics readers: dotnet/diagnostics#5823
## Testing
Draft pending coordinated diagnostics validation on macOS arm64.
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 7805386d-16fd-4306-bcc9-54d4ea7b65cf
max-charlamb added a commit
to dotnet/diagnostics
that referenced
this pull request
Aug 10, 2026
@max-charlamb
SOS: read macOS arm64 thread metadata from a valid address (#5953)
1b6da39
## Summary
- read macOS arm64 createdump thread metadata from the new 47-bit-valid
address
- fall back to the legacy address for compatibility with existing
createdump output
- use the selected address for all subsequent thread-info entries
## Motivation
Apple Silicon LLDB rejects the legacy `0x7fffffff00000000` synthetic
segment and assigns sequential thread IDs beginning at zero. SOS cannot
then correlate LLDB threads with runtime OS thread IDs or retrieve the
selected thread context.
Coordinated writer change: dotnet/runtime#131962
## Related precedent
This follows @steveisok's coordinated Apple Silicon fix for
`SpecialDiagInfoAddress`:
- runtime writer: dotnet/runtime#130443
- diagnostics readers: #5823
## Testing
Draft pending coordinated macOS arm64 validation with the runtime writer
change.
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 7805386d-16fd-4306-bcc9-54d4ea7b65cf
@github-actionsgithub-actionsBot
locked and limited conversation to collaborators
Aug 11, 2026
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

Copilot code reviewCopilot
Copilot review effort
Applies to this pull request for everyone.Learn more about Copilot code review.
Copilot left review comments
@noahfalknoahfalknoahfalk approved these changes
@hoyosjshoyosjshoyosjs approved these changes

Assignees

@steveisoksteveisok

Labels

area-Diagnostics-coreclr

Projects


None yet


Milestone

11.0-preview7

Development

Successfully merging this pull request may close these issues.

4 participants

@steveisok@noahfalk@hoyosjs