On 11/18/16 3:55 PM, Zachary Turner via lldb-dev wrote:
On line 708 of CommandObjectFrame.cpp, I'm looking at this code:
options.SetRootValueObjectName(name_cstr);
This code occurs inside the else block of an if/else. name_cstr is
declared prior to the if/else block and initialized to nullptr, but is
only ever set to something other than nullptr in the if branch.
So, this code is equivalent to
options.SetRootValueObjectName(nullptr);
Is this intended,
Probably not
and if not how would this bug manifest itself in terms of incorrect
behavior?
That I am not sure about.. I tried a couple obvious things, but I
couldn't make them fail. It's possible that some arcane combination of
options would do it. OTOH, my hunch is that we could simply fix the bug.
Trying a patch of the form
Index: source/Commands/CommandObjectFrame.cpp
===================================================================
--- source/Commands/CommandObjectFrame.cpp (revision 287375)
+++ source/Commands/CommandObjectFrame.cpp (working copy)
@@ -704,7 +704,7 @@
options.SetFormat(format);
options.SetVariableFormatDisplayLanguage(
valobj_sp->GetPreferredDisplayLanguage());
- options.SetRootValueObjectName(name_cstr);
+ options.SetRootValueObjectName(var_sp ?
var_sp->GetName().AsCString() : nullptr);
valobj_sp->Dump(result.GetOutputStream(), options);
}
}
is the first thing I would do. On the face of it, it looks correct
behavior (the "root name" is the name of the variable being displayed).
Still worth a test suite run of course - but if you run into any
regressions due to the change, it's worth bringing them up. It's
possible the test is testing the wrong behavior and we found our smoking
gun in terms of actual incorrect behavior.
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
