> On Aug 10, 2018, at 11:13 AM, Adrian Prantl via lldb-dev
> <lldb-dev@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
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
