[Lldb-commits] [lldb] r269025 - Fix race in TestExitDuringStep and unify pseudo_barrier handling

[Pavel Labath via lldb-commits]

Hmm.. So you actually needed to insert the additional "continue"
command. That is not good. I was hoping it would be enough to just
remove the strict check for the location numbers.

Working around it this way is quite ugly. Let's try something else.
Would getting rid of the do{}while loop in the macro fix the problem?
I added it to make the macro a bit more safe, but I don't think it's
really necessary...

It may be worth making this into a separate test case though, as this
should just work.

pl


On 11 May 2016 at 16:24, Ed Maste <emaste at freebsd.org> wrote:
> On 11 May 2016 at 10:10, Pavel Labath <labath at google.com> wrote:
>> Hi,
>>
>> so I think this is our old "compiler generates unpredictable number of
>> source locations for a line" friend again, which got triggered by a
>> random code reshuffle. Assuming the test still passes for you after
>> that, can you prepare a change to remove the "num_expected_locations =
>> 1" from the relevant lines?
>
> Indeed. I'm able to get the test passing with this ugly workaround:
>
> --- a/packages/Python/lldbsuite/test/functionalities/thread/thread_exit/TestThreadExit.py
> +++ b/packages/Python/lldbsuite/test/functionalities/thread/thread_exit/TestThreadExit.py
> @@ -31,16 +31,18 @@ class ThreadExitTestCase(TestBase):
>          self.runCmd("file " + exe, CURRENT_EXECUTABLE_SET)
>
>          # This should create a breakpoint with 1 location.
> +       # Note, Clang 3.4.1 on FreeBSD 10 produces debug info with two locations
> +       # for breakpoint 3. Work around that by requiring at least one location.
>          bp1_id = lldbutil.run_break_set_by_file_and_line (self,
> "main.cpp", self.break_1, num_expected_locations=1)
>          bp2_id = lldbutil.run_break_set_by_file_and_line (self,
> "main.cpp", self.break_2, num_expected_locations=1)
> -        bp3_id = lldbutil.run_break_set_by_file_and_line (self,
> "main.cpp", self.break_3, num_expected_locations=1)
> +        bp3_id = lldbutil.run_break_set_by_file_and_line (self,
> "main.cpp", self.break_3, num_expected_locations=-1)
>          bp4_id = lldbutil.run_break_set_by_file_and_line (self,
> "main.cpp", self.break_4, num_expected_locations=1)
>
>          # The breakpoint list should show 1 locations.
>          self.expect("breakpoint list -f", "Breakpoint location shown
> correctly",
>              substrs = ["1: file = 'main.cpp', line = %d, exact_match
> = 0, locations = 1" % self.break_1,
>                         "2: file = 'main.cpp', line = %d, exact_match
> = 0, locations = 1" % self.break_2,
> -                       "3: file = 'main.cpp', line = %d, exact_match
> = 0, locations = 1" % self.break_3,
> +                       "3: file = 'main.cpp', line = %d, exact_match
> = 0, locations = " % self.break_3,
>                         "4: file = 'main.cpp', line = %d, exact_match
> = 0, locations = 1" % self.break_4])
>
>          # Run the program.
> @@ -76,6 +78,10 @@ class ThreadExitTestCase(TestBase):
>
>          # Run to the fourth breakpoint
>          self.runCmd("continue")
> +       # bp3 may have multiple locations. Continue if we're still
> stopped there.
> +        if lldbutil.get_one_thread_stopped_at_breakpoint_id(process, bp3_id):
> +            self.runCmd("continue")
> +
>          stopped_thread =
> lldbutil.get_one_thread_stopped_at_breakpoint_id(process, bp4_id)
>          self.assertIsNotNone(stopped_thread, "Process is not stopped
> at breakpoint 4")