This is an archive of the discontinued LLVM Phabricator instance.

[lldb][LocateModuleCallback] Fix LocateModuleCallbackTest
ClosedPublic

Authored by splhack on Jul 14 2023, 1:07 PM.

Diff Detail

Event Timeline

splhack created this revision.Jul 14 2023, 1:07 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 14 2023, 1:07 PM
splhack requested review of this revision.Jul 14 2023, 1:07 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 14 2023, 1:07 PM
JDevlieghere requested changes to this revision.Jul 14 2023, 2:56 PM

ASSERT_EQ should call operator== under the hood. Why would that be flakey on arm64? Can we achieve this by changing the implementation to reimplement this with FileSpec::Compare?

This revision now requires changes to proceed.Jul 14 2023, 2:56 PM

I ran the TargetTests under lldb to see (this test doesn't fail on my arm64 mac desktop ftr). ASSERT_EQ calls template <typename T1, typename T2> AssertionResult CmpHelperEQ() and that calls FileSpec::operator== on my desktop. Jonas suggested that we get the binary data dump of the FileSpec objects because there wasn't a method implemented in FileSpec that gtest knew to call to print the objects. I originally thought ASSERT_EQ might be doing a binary comparison of the object bytes when I saw the failing msg on the arm64 macos bot.

Would it be better to pass the GetPath() method on both of the FileSpec's we send to ASSERT_EQ so it is working with std::string's which it will know how to print if there is a comparison mismatch?

thanks @JDevlieghere @jasonmolenda, yeah GetPath() makes sense it could show the mismatch in human readable form.

splhack updated this revision to Diff 540594.Jul 14 2023, 4:17 PM

Use GetPath() instead of Compare().

My first thought was, but what about all the other unit tests doing this, and git grepping around, I think there's one in Interpreter/TestOptionValue.cpp and one in Interpreter/TestOptionValueFileColonLine.cpp. I'd like to see what @JDevlieghere thinks, this patch is fine to me but it is an unfortunate - surely there is some method we could implement in FileSpec to get the gtest stuff to print the path when there's a failure, but I didn't see it when I tried to read through the code.

Like reading third-party/unittest/googletest/include/gtest/gtest-printers.h, I thought I could add a static PrintTo method? but

index 6eb5b805d9d..93d98baa5be 100644
--- a/lldb/include/lldb/Utility/FileSpec.h
+++ b/lldb/include/lldb/Utility/FileSpec.h
@@ -12,4 +12,5 @@
 #include <functional>
 #include <optional>
+#include <ostream>
 #include <string>
 
@@ -198,4 +199,8 @@ public:
   static std::optional<Style> GuessPathStyle(llvm::StringRef absolute_path);
 
+  /// Print the file path in a FileSpec to the ostream, for gtest-printers unit
+  /// test failure printing.
+  static void PrintTo(const FileSpec &fspec, std::ostream *ostr);
+
   /// Case sensitivity of path.
   ///
diff --git a/lldb/source/Utility/FileSpec.cpp b/lldb/source/Utility/FileSpec.cpp
index eb34ef97cea..6f09c8448df 100644
--- a/lldb/source/Utility/FileSpec.cpp
+++ b/lldb/source/Utility/FileSpec.cpp
@@ -320,4 +320,8 @@ FileSpec::GuessPathStyle(llvm::StringRef absolute_path) {
 }
 
+void FileSpec::PrintTo(const FileSpec &fspec, std::ostream *ostr) {
+  *ostr << fspec.GetPath();
+}
+
 // Dump the object to the supplied stream. If the object contains a valid
 // directory name, it will be displayed followed by a directory delimiter, and

and making one of the FileSpecs not match, I still get the "24-byte object" printed for the ASSERT_EQ mismatch. I must have misunderstood the header.

FWIW when I was testing this locally, I was seeing paths like

(lldb) p uuid_view
(lldb_private::FileSpec) $0 = file: "AndroidModule.so" dir: "/var/folders/1b/976z5_5513l64wvrj15vkt800000gn/T/lldb/49966/LocateModuleCallbackTest-GetOrCreateModuleWithCachedModuleAndSymbol/remote-android/.cache/80008338-82A0-51E5-5922-C905D23890DA-BDDEFECC"

(lldb) p module_sp->GetFileSpec()
(const lldb_private::FileSpec) $1 = file: "AndroidModule.so" dir: "/var/folders/1b/976z5_5513l64wvrj15vkt800000gn/T/lldb/49966/LocateModuleCallbackTest-GetOrCreateModuleWithCachedModuleAndSymbol/remote-android/.cache/80008338-82A0-51E5-5922-C905D23890DA-BDDEFECC"

and I'm betting the real issue is that the arm64 bot account has something funky about TMPRDIR, so one of these is realpath'ed to a different filepath and the comparison failed. It would be a lot easier to understand what was actually happening on that bot if we could see the paths, but I don't think we're addressing the actual issue here. (we need to fix the printing first, then we can see what is going on with the bot)

splhack updated this revision to Diff 540648.Jul 15 2023, 12:56 AM

Tear down the module cache.

@jasonmolenda thank you for looking into this!
I was finally able to repro the test failure on arm64 macOS with this diff (the version with ASSERT_EQ(a_file_spec.GetPath(), b_file_spec.GetPath()) and this CMake config.

cmake \
    ../llvm \
    -G Ninja \
    -DCMAKE_BUILD_TYPE=RelWithDebInfo \
    -DCMAKE_EXPORT_COMPILE_COMMANDS=ON \
    -DLLVM_TARGETS_TO_BUILD=X86;ARM;AArch64 \
    -DLLDB_TEST_USER_ARGS="--build-dir;$(pwd);-t;--env;TERM=vt100" \
    -DLLDB_ENFORCE_STRICT_TEST_REQUIREMENTS=Off \
    -DLLDB_ENABLE_PYTHON=On \
    -DLLVM_ENABLE_ASSERTIONS:BOOL=TRUE \
    -DLLVM_ENABLE_MODULES=On \
    -DLLVM_ENABLE_PROJECTS="clang;lld;lldb;cross-project-tests" \
    -DLLVM_LIT_ARGS="-v --time-tests --shuffle --xunit-xml-output=$(pwd)/results.xml -v -j 8" \
    -DLLVM_VERSION_PATCH=99 \
    -DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi;compiler-rt" \
    -DPython3_EXECUTABLE=/usr/bin/python3 \
    -DSWIG_EXECUTABLE=/opt/brew/Cellar/swig@3/3.0.12/bin/swig
******************** TEST 'lldb-unit :: Target/./TargetTests/6/11' FAILED ********************
Script(shard):
--
GTEST_OUTPUT=json:/Users/user/Sources/llvm-project/build/tools/lldb/unittests/Target/./TargetTests-lldb-unit-45687-6-11.json GTEST_SHUFFLE=1 GTEST_TOTAL_SHARDS=11 GTEST_SHARD_INDEX=6 GTEST_RANDOM_SEED=20766 /Users/user/Sources/llvm-project/build/tools/lldb/unittests/Target/./TargetTests
--

Script:
--
/Users/user/Sources/llvm-project/build/tools/lldb/unittests/Target/./TargetTests --gtest_filter=LocateModuleCallbackTest.GetOrCreateModuleWithCachedModule
--
/Users/user/Sources/llvm-project/lldb/unittests/Target/LocateModuleCallbackTest.cpp:152: Failure
Expected equality of these values:
  a_file_spec.GetPath()
    Which is: "/Users/user/Sources/llvm-project/build/tools/lldb/unittests/Target/Inputs/AndroidModule.unstripped.so"
  b_file_spec.GetPath()
    Which is: "/var/folders/hv/pgk33lbd2snf__0bd0v30yyc0000gn/T/lit-tmp-qrocj9y_/lldb/45872/LocateModuleCallbackTest-GetOrCreateModuleWithCachedModule/remote-android/.cache/80008338-82A0-51E5-5922-C905D23890DA-BDDEFECC/AndroidModule.so"
/Users/user/Sources/llvm-project/lldb/unittests/Target/LocateModuleCallbackTest.cpp:280: Failure
Value of: module_sp->GetSymbolFileFileSpec()
  Actual: true
Expected: false

/Users/user/Sources/llvm-project/lldb/unittests/Target/LocateModuleCallbackTest.cpp:152
Expected equality of these values:
  a_file_spec.GetPath()
    Which is: "/Users/user/Sources/llvm-project/build/tools/lldb/unittests/Target/Inputs/AndroidModule.unstripped.so"
  b_file_spec.GetPath()
    Which is: "/var/folders/hv/pgk33lbd2snf__0bd0v30yyc0000gn/T/lit-tmp-qrocj9y_/lldb/45872/LocateModuleCallbackTest-GetOrCreateModuleWithCachedModule/remote-android/.cache/80008338-82A0-51E5-5922-C905D23890DA-BDDEFECC/AndroidModule.so"
/Users/user/Sources/llvm-project/lldb/unittests/Target/LocateModuleCallbackTest.cpp:280
Value of: module_sp->GetSymbolFileFileSpec()
  Actual: true
Expected: false

The root cause is that the module is cached in this specific test, GetOrCreateModuleWithCachedModule.
Because llvm-lit runs multiple tests in a same process by this CMake config.
Most runtime data is surely initialized by gtest SetUp but ModuleList global instance lives beyond the test lifespan.
Fixed it by tear down the cached module.

splhack retitled this revision from [lldb][LocateModuleCallback] Fix FileSpec compare to [lldb][LocateModuleCallback] Fix LocateModuleCallbackTest.Jul 15 2023, 12:57 AM
splhack edited the summary of this revision. (Show Details)
jasonmolenda accepted this revision.Jul 15 2023, 9:53 AM

Great catch, thanks for digging in on this!

This revision was not accepted when it landed; it landed in state Needs Review.Jul 15 2023, 12:17 PM
This revision was automatically updated to reflect the committed changes.

edit: local builds are failing for me, but on double checking I don't think it's this patch. CI is mostly green.