Fix regression in jModulesInfo packet handling
authorPavel Labath <labath@google.com>
Mon, 18 Dec 2017 14:31:44 +0000 (14:31 +0000)
committerPavel Labath <labath@google.com>
Mon, 18 Dec 2017 14:31:44 +0000 (14:31 +0000)
commit8c92c899c6f4a895d3ebe990b684e1c30df12bc7
tree610a661273cb6d78f37454770eafb7754b398a34
parent11e5917d2aecff32546644e91132f8efb565b4c9
Fix regression in jModulesInfo packet handling

The recent UUID cleanups exposed a bug in the parsing code for the
jModulesInfo response, which was passing wrong value for the second
argument to UUID::SetFromStringRef (it passed the length of the string,
whereas the correct value should be the number of decoded bytes we
expect to receive).

This was not picked up by tests, because they test with 16-byte uuids,
for which the function happens to do the right thing even if the length
does not match (if the length does not match, the function does not
update m_num_uuid_bytes member, but that member is already 16 to begin
with).

I fix that and add a test with 20-byte uuid to catch if this regresses.
I have also added more safeguards into the parsing code to fail if we
cannot parse the entire uuid field we recieve. While testing the latter
part, I noticed that the "negative" jModulesInfo tests were succeeding
because we were sending malformed json (and not because the json
contents was invalid), so I make those tests a bit more robuts as well.

llvm-svn: 320985
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp