[lldb][test][x86_64][win] Split assertion in TestBreakpointConditions

[kendalharland]

This PR splits the test assertion that verifies we're on the correct line and have the correct value of val to make the error message more clear. At present it just shows Assertion error: True != False

[llvmbot]

@llvm/pr-subscribers-lldb

Author: Kendal Harland (kendalharland)

Changes

On windows x86_64 this test stops on the set breakpoint when val == 1 when the breakpoint condition is set on the SBBreakpointLocation rather than the SBBreakpoint directly. Setting the condition on the breakpoint itself, seems to fix the issue.

This PR also splits the test assertion that verifies we're on the correct line and have the correct value of val to make the error message more clear. At present it just shows Assertion error: True != False

#100486

---

Full diff: https://github.com/llvm/llvm-project/pull/100487.diff

1 Files Affected:

• (modified) lldb/test/API/functionalities/breakpoint/breakpoint_conditions/TestBreakpointConditions.py (+9-5)

diff --git a/lldb/test/API/functionalities/breakpoint/breakpoint_conditions/TestBreakpointConditions.py b/lldb/test/API/functionalities/breakpoint/breakpoint_conditions/TestBreakpointConditions.py
index 50ba0317fd094..625ca916d20f1 100644
--- a/lldb/test/API/functionalities/breakpoint/breakpoint_conditions/TestBreakpointConditions.py
+++ b/lldb/test/API/functionalities/breakpoint/breakpoint_conditions/TestBreakpointConditions.py
@@ -155,13 +155,13 @@ def breakpoint_conditions_python(self):
             breakpoint.GetThreadIndex(), 1, "The thread index has been set correctly"
         )
 
+        # Set the condition on the breakpoint.
+        breakpoint.SetCondition("val == 3")
+
         # Get the breakpoint location from breakpoint after we verified that,
         # indeed, it has one location.
         location = breakpoint.GetLocationAtIndex(0)
         self.assertTrue(location and location.IsEnabled(), VALID_BREAKPOINT_LOCATION)
-
-        # Set the condition on the breakpoint location.
-        location.SetCondition("val == 3")
         self.expect(location.GetCondition(), exe=False, startstr="val == 3")
 
         # Now launch the process, and do not stop at entry point.
@@ -176,11 +176,15 @@ def breakpoint_conditions_python(self):
             thread.IsValid(),
             "There should be a thread stopped due to breakpoint condition",
         )
+
         frame0 = thread.GetFrameAtIndex(0)
         var = frame0.FindValue("val", lldb.eValueTypeVariableArgument)
-        self.assertTrue(
-            frame0.GetLineEntry().GetLine() == self.line1 and var.GetValue() == "3"
+        self.assertEqual(
+            frame0.GetLineEntry().GetLine(),
+            self.line1,
+            "The debugger stopped on the correct line",
         )
+        self.assertEqual(var.GetValue(), "3")
 
         # The hit count for the breakpoint should be 1.
         self.assertEqual(breakpoint.GetHitCount(), 1)

[kendalharland]

Uploaded a new patch set after realizing my original commit removed tests for the codepath where SBBReakpointLocation.SetCondition is used, which still needs to be tested on aarch64. The latest commit tests both SBBreakpointLocation.SetCondition and SBBreakpoint.SetCondition

[jimingham]

The only way that this could succeed on the breakpoint but fail on the location is that there is more than one location and the one the test is setting it on (the zeroth) is not the one that's hit. Since this test is "does a breakpoint condition on a location work" not "does this breakpoint always only produce one location" it might be better to just put the breakpoint on all the locations, and see if the one that is hit does work.

[kendalharland]

The only way that this could succeed on the breakpoint but fail on the location is that there is more than one location and the one the test is setting it on (the zeroth) is not the one that's hit. Since this test is "does a breakpoint condition on a location work" not "does this breakpoint always only produce one location" it might be better to just put the breakpoint on all the locations, and see if the one that is hit does work.

Thanks for the context! In #100477 I learned that the set of compilers I was using to build LLVM are different from the existing lldb-aarch64-windows builder. After fixing that, I am no longer seeing this test fail. I've removed the top commit and left only the one that splits the test assertion to produce a more clear failure message.

[kendalharland]

Hi @JDevlieghere, friendly reminder to PTAL when you can.