This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Fix string summary of an empty NSPathStore2
ClosedPublic

Authored by teemperor on Sep 25 2019, 1:02 AM.

Details

Summary

Printing a summary for an empty NSPathStore2 string currently prints random bytes behind the empty string pointer from memory (rdar://55575888).

It seems the reason for this is that the SourceSize parameter in the ReadStringAndDumpToStreamOptions - which is supposed to contain the string
length - actually uses the length 0 as a magic value for saying "read as much as possible from the buffer" which is clearly wrong for empty strings.

This patch adds another flag that indicates if we have know the string length or not and makes this behaviour dependent on that (which seemingly
was the original purpose of this magic value).

Diff Detail

Event Timeline

teemperor created this revision.Sep 25 2019, 1:02 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 25 2019, 1:02 AM
teemperor updated this revision to Diff 221702.Sep 25 2019, 3:19 AM
teemperor edited the summary of this revision. (Show Details)
  • Land the NFC test additions to other string classes as separate NFC commits.
  • Rebase on the already landed refactoring.
aprantl added inline comments.Sep 25 2019, 9:44 AM
lldb/include/lldb/DataFormatters/StringPrinter.h
181

I don't know the LLDB rules that well: is the convention really GetHas instead of Has?

lldb/source/DataFormatters/StringPrinter.cpp
546

why unconditionally call GetSourceSize? Should we move it into the else?

563

Why call GetBytes() if sourceSize is 0? Should we reverse the two conditions?

  • GetHasSourceSize -> HasSourceSize
  • Moved some code around according to feedback.
teemperor marked 3 inline comments as done.Oct 10 2019, 12:41 AM
aprantl accepted this revision.Oct 10 2019, 8:26 AM
This revision is now accepted and ready to land.Oct 10 2019, 8:26 AM
shafik added inline comments.Oct 10 2019, 9:30 AM
lldb/source/DataFormatters/StringPrinter.cpp
544

Why not just make this uint32_t making this auto gains us nothing but now I am left wondering do the types match later on when we use max_size.

teemperor updated this revision to Diff 251184.Mar 18 2020, 3:11 PM
  • Rebased the patch.

This has been (really) delayed because of the whole unit test I wanted to write, but I'll just land this as-is (as having this broken even longer just because I haven't written that new unit test seems silly).

This revision was automatically updated to reflect the committed changes.