labath added a comment. In https://reviews.llvm.org/D46588#1093054, @aprantl wrote:
> In https://reviews.llvm.org/D46588#1092884, @labath wrote: > > > Out of curiosity, are there any plans to improve the lldb-mi test > > reliability situation? As it stands now, most of the lldb-mi tests are > > disabled one way or another due to them being flaky. > > > Thanks for bringing that up. I just looked at a few lldb-mi testcases and > they all seem to follow a pattern of `self.runCmd()` followed by > `self.expect()`. That in itself doesn't look like a particularly bad design > to me since it synchronizes commands and expected output tightly. Do we know > why the tests are flakey? Do they get out of sync, or is there something else? Short answer: I don't know. Noone was motived enough to get to the bottom of that. I tried looking at it once or twice, but I was put off by: - when the test fails you get a dump of the pexpect state, which is hard to comprehend - I tried enabling some logging but the log was full of useless messages because lldb-mi has a thread which does a 1 millisecond polls for events. I think it would help if instead of pexpect, we used some driver which is aware of the basics of lldb-mi protocol. This would make logging the execution of a test easier and it would solve the XFAIL issue -- right now, if lldb-mi does not produce expected output, pexpect will just hang until it times out, hoping that the right output might come eventually. And it would also make it possible to run the tests on windows. The 1ms wait also sounds like something that should be fixed regardless of whether it is causing any flakyness or not. Repository: rL LLVM https://reviews.llvm.org/D46588 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
