Skip to content

Conversation

@jhelferty-nv
Copy link
Contributor

When providing formatters for types in lldb, we need to iterate through the types to find the appropriate data. If we attempt to iterate into a leaf of an object that isn't valid (e.g., into a nullptr) then python will generate a warning/error message on the command line. If you're using lldb on the command line, and particularly when using the curses-based gui, this results in visible corruption.

This change validates each step along the way to avoid this issue.

(Coded by Claude)

When providing formatters for types in lldb, we need to iterate
through the types to find the appropriate data. If we attempt to
iterate into a leaf of an object that isn't valid (e.g., into a
nullptr) then python will generate a warning/error message on the
command line. If you're using lldb on the command line, and
particularly when using the curses-based gui, this results in visible
corruption.

This change validates each step along the way to avoid this issue.

(Coded by Claude)
@jhelferty-nv jhelferty-nv requested a review from a team as a code owner December 1, 2025 16:09
@jhelferty-nv jhelferty-nv self-assigned this Dec 1, 2025
@jhelferty-nv jhelferty-nv added the pr: non-breaking PRs without breaking changes label Dec 2, 2025
@jhelferty-nv jhelferty-nv requested a review from samestep December 2, 2025 05:11
Copy link
Contributor

@samestep samestep left a comment

Choose a reason for hiding this comment

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

Thanks for working on this! It is really unfortunate that there are so many sharp edges one needs to manually check for when writing LLDB scripts like this, in contrast to the Natvis files in this repo which seem relatively clean.

In general I like the idea of this PR, but I really really don't like this diff as it currently stands :/ it makes the code significantly less readable and maintainable. Is there any way to achieve the same goal in a more maintainable way? Perhaps by putting the validation into some sort of wrapper/helper class/functions, similar to the Children class that already exists here?

In the end though, I'm not actually using these currently and you are, so I'll defer to you on whether to merge this or not.

@jhelferty-nv
Copy link
Contributor Author

I mean, those are fair criticisms. I could try and push checks into a wrapper class. (It feels like there should be some python-y way to abstract that a bit using, I dunno, @decorators or something.) I think we'll still end up with branching in the actual formatters, but it might be reduced a bit.

Ideally we wouldn't need to hand-code any of this. My preferred solution is to have something that uses the .natvis files to generate the python formatters for us, instead of having to maintain the python formatters directly.

@jhelferty-nv jhelferty-nv marked this pull request as draft December 3, 2025 21:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

pr: non-breaking PRs without breaking changes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants