Repository navigation
LLDB sos commands don't write output to SBCommandReturnObject #4086
Description
Activity
Hello, any update on this issue?
I've just hit the same thing while trying to write some custom LLDB tooling which processes CLR data.
In particular I'm trying to capture the results ofip2mdinto a python stringI've been working on some changes that would lead to fixing this issue. It will take some bigger infrastructure changes to SOS to allow per command output.
I've been working on some changes that would lead to fixing this issue. It will take some bigger infrastructure changes to SOS to allow per command output.
Thanks for the reply!
In the meantime, do you have any suggestions for getting the C# method name (signature) from a given address in LLDB?
I was trying to use
ip2mdand extract the name portion of the output, but I'm now wondering if there's another way I can go about this more directly?- Maybe check out clrmd? https://github.com/microsoft/clrmd…On Tue, Jun 4, 2024, 19:37 Harry Rose ***@***.***> wrote: I've been working on some changes that would lead to fixing this issue. It will take some bigger infrastructure changes to SOS to allow per command output. Thanks for the reply! In the meantime, do you have any suggestions for getting the C# method name from a given address in LLDB? I was trying to use ip2md and extract the name portion of the output, but I'm now wondering if there's another way I can go about this more directly? — Reply to this email directly, view it on GitHub <#4086 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACHEX7UHFUG5KNQEH5FVJKLZFX3NVAVCNFSM6AAAAAA2RUCKEOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBYGA3DQOJZGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>
You can write managed C# SOS commands now using the above CLRMD. Some examples are in https://github.com/dotnet/diagnostics/tree/main/src/Microsoft.Diagnostics.ExtensionCommands.
I know this is an older issue at this point but thank you for filing it. I've been fighting this in a personal project for a while now and this issue captures what I was seeing.
Of course the right fix is to always use ClrMD and not try to screen scrape SOS. SOS is not an interface, and ClrMD is.
Even still this really breaks some diagnostic features, it's a bug, and I have a fix I'm working on.
- added a commit that references this issue
on Feb 18, 2026 - added a commit that references this issue
on Feb 18, 2026 - locked and limited conversation to collaborators
on Mar 26, 2026
Description
I had a custom lldb command written in python that calls clrstack on all threads listed by clrthreads. The command stopped working after I updated dotnet-sos to 7.0.410101 (it's still broken on 7.0.430602). The reason why it's broken is that it commands executed with SBCommandInterpreter.HandleCommand do not write their output to lldb.SBCommandReturnObject, I checked both output and error streams of the command and both are empty.
To reproduce this issue, you can use the following lldb command:
The command will print clrstack output on the console and 0 after that, this behavior is same for all sos commands.
If you use a lldb command, for example "bt" the provided snippet will print nothing and return some number greater than 0
Configuration
dotnet --info
.NET SDK:
Version: 7.0.100
Commit: e12b7af219
Runtime Environment:
OS Name: gentoo
OS Version: 2.13
OS Platform: Linux
RID: linux-x64
Base Path: /home/user/.dotnet/sdk/7.0.100/
Host:
Version: 7.0.0
Architecture: x64
Commit: d099f075e4
.NET SDKs installed:
7.0.100 [/home/user/.dotnet/sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 7.0.0 [/home/user/.dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 7.0.0 [/home/user/.dotnet/shared/Microsoft.NETCore.App]
Other architectures found:
None
Environment variables:
DOTNET_ROOT [/home/user/.dotnet]
global.json file:
Not found
Learn more:
https://aka.ms/dotnet/info
Download .NET:
https://aka.ms/dotnet/download
Regression?
Other information
It used to work before I updated, but I can't remember the exact version of dotnet-sos I had, something pretty old, probably 6.*