-
Notifications
You must be signed in to change notification settings - Fork 14.3k
Make ValueObjectPrinter's handling of its ValueObject pointers more principled (NFC) #81314
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -177,7 +177,10 @@ class CommandObjectFrameDiagnose : public CommandObjectParsed { | |
|
||
DumpValueObjectOptions options; | ||
options.SetDeclPrintingHelper(helper); | ||
ValueObjectPrinter printer(valobj_sp.get(), &result.GetOutputStream(), | ||
// We've already handled the case where the value object sp is null, so | ||
// this is just to make sure future changes don't skip that: | ||
assert(valobj_sp.get() && "Must have a valid ValueObject to print"); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It is fine to assert here, but we should not crash if valobj_sp is NULL. I would rather log or report an error that crash if possible. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm of two minds about this. The current code does: if (!valobj_sp) { Then this code. So I could have just duplicated the check & error handling again before printing the thing, but that looked bogus to me. OTOH, I don't want someone to delete the check for some reason, so I put in the assert. I'm really defending against one of us removing a necessary check. But if that bugs you I'm happy to cut and paste the error handling here again. It just looked weird to me. |
||
ValueObjectPrinter printer(*valobj_sp, &result.GetOutputStream(), | ||
options); | ||
printer.PrintValueObject(); | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we should start using
std::weak_ptr<ValueObject>
instead of raw pointers. Someone is storing a shared pointer to the object somewhere in the value object tree, so having a weak pointer could help us to catch these things as we can askif (m_cached_valobj_wp.expired() == true)
and this would tell us that this was assigned to a valid object at one point, but it has been freed. The expired call will return false if the weak pointer was never set or if the weak pointer was cleared.