[llvm-dev] [lldb-dev] Failing LIT-based lldb-mi tests

[Adrian Prantl via llvm-dev]

> On Aug 10, 2018, at 1:47 PM, Александр Поляков <polyakov.alx at gmail.com> wrote:
> 
> Do you agree that we need to have a timeout in the -wait-for-breakpoint command? It could have default value and can be set with a command argument.

Before we continue to discuss -wait-for-breakpoint; where you actually able to verify my suspicion that that is what is happening on the bots? Fred suggested to me offline today that in synchronous mode, perhaps -exec-* should be waiting for the process to be stopped, which would also sound like a reasonable and less invasive solution to the problem.

-- adrian

> 
> пт, 10 авг. 2018 г. в 22:56, Adrian Prantl <aprantl at apple.com>:
> 
> 
> > On Aug 10, 2018, at 11:13 AM, Adrian Prantl via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> > 
> > [+lldb-dev, since this affects all bots equally]
> > 
> > Alexander, it looks like there is a race condition in some of the LIT-based lldb-mi tests.
> > 
> > For example, exec-next.test:
> > 
> >  # Test lldb-mi -exec-next command.
> > 
> >  # Check that we have a valid target created via '%lldbmi %t'.
> >  # CHECK: ^done
> > 
> >  -break-insert main
> >  # CHECK: ^done,bkpt={number="1"
> > 
> >  -exec-run
> >  # CHECK: ^running
> >  # CHECK: *stopped,reason="breakpoint-hit"
> > 
> >  -exec-next --thread 0
> >  # Check that exec-next can process the case of invalid thread ID.
> >  # CHECK: ^error,msg="Command 'exec-next'. Thread ID invalid"
> > 
> >  ...
> > 
> > Here we are not actually waiting for the breakpoint to be hit. Synchronous mode ensures that the lldb-mi driver waits for each command to be completed, but that only means that -exec-run only returns after the process has been launched and does not include waiting for the program to actually hit a breakpoint. So if the program runs very slowly (such as often happens on a very busy bot), the -exec-next and subsequent commands are scheduled before the breakpoint is hit. In order to fix this we either need to move any tests that schedule commands after hitting breakpoints back to Python, or we need to add a new -wait-for-breakpoint MI command for testing only to force a synchronization point.
> 
> In order to test my hypothesis, you could set the breakpoint in a different function than main and insert a sleep() into the program to simulate the condition on the bots, i.e.:
> 
>   void foo() {
>     // actual test code below
>     ...
>   }
> 
>   int main(int argc, char ** argv) {
>     sleep(10);
>     foo();
>   }
> 
> and in the test:
> 
>   # instead of main:
>   -break-insert foo
>   # and then :-)
>   -some-command-that-would-fail-if-executed-before-breakpoint-is-hit
> 
> -- adrian
> 
> 
> -- 
> Alexander