[all-commits] [llvm/llvm-project] be738c: [lldb-vscode] Fix data race in lldb-vscode when ru...

[walter erquinigo via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: be738c9d1c1612f5cb0a84227f5ced2726ae609e
      https://github.com/llvm/llvm-project/commit/be738c9d1c1612f5cb0a84227f5ced2726ae609e
  Author: Walter Erquinigo <wallace at fb.com>
  Date:   2022-05-17 (Tue, 17 May 2022)

  Changed paths:
    M lldb/tools/lldb-vscode/ProgressEvent.h

  Log Message:
  -----------
  [lldb-vscode] Fix data race in lldb-vscode when running with ThreadSanitizer

This patch fixes https://github.com/llvm/llvm-project/issues/54768. A ProgressEventReporter creates a dedicated thread that keeps checking whether there are new events that need to be sent to IDE as long as m_thread_should_exit is true. When the VSCode instance is destructed, it will set m_thread_should_exit to false, which caused a data race because at the same time its ProgressEventReporter is reading this value to determine whether it should quit. This fix simply uses mutex to ensure they cannot read and write this value at the same time.

Committed on behalf of PRESIDENT810

Reviewed By: clayborg, wallace

Differential Revision: https://reviews.llvm.org/D125073


  Commit: d8f4f1027a92883067ecd4b01030484cffeb24d3
      https://github.com/llvm/llvm-project/commit/d8f4f1027a92883067ecd4b01030484cffeb24d3
  Author: Walter Erquinigo <wallace at fb.com>
  Date:   2022-05-17 (Tue, 17 May 2022)

  Changed paths:
    M llvm/lib/Support/JSON.cpp
    M llvm/unittests/Support/JSONTest.cpp

  Log Message:
  -----------
  [llvm][json] Fix UINT64 json parsing

https://reviews.llvm.org/D109347 added support for UINT64 json numeric
types. However, it seems that it didn't properly test uint64_t numbers
larger than the int64_t because the number parsing logic doesn't
have any special handling for these large numbers.

This diffs adds a handler for large numbers, and besides that, fixes the
parsing of signed types by checking for errno ERANGE, which is the
recommended way to check if parsing fails because of out of bounds
errors. Before this diff, strtoll was always returning a number within
the bounds of an int64_t and the bounds check it was doing was completely
superfluous.

As an interesting fact about the old implementation, when calling strtoll
with "18446744073709551615", the largest uint64_t, End was S.end(), even
though it didn't use all digits. Which means that this check can only be
used to identify if the numeric string is malformed or not.

This patch also adds additional tests for extreme cases.

Differential Revision: https://reviews.llvm.org/D125322


Compare: https://github.com/llvm/llvm-project/compare/627928c58bd4...d8f4f1027a92