jingham added a comment. The comments in llvm.org/pr18522 seem to me to be bugs that the test is uncovering, not bugs in the test itself. It looks like we hit a breakpoint on thread A, and try to run the condition on thread B. In some cases, thread B isn't really alive yet, and so the attempt to add a stack frame to it fails. But the whole code path down from StopInfoBreakpoint::PerformAction down to UserExpression::Execute etc all take an execution context that specifies the thread. So I'm not sure how this would happen. It also seems like sometimes they were getting spurious interrupts that were being interpreted as breakpoint hits. That's again clearly a bug in the platform layer.
This is a really simple test at the Python level, though it does trigger some complex behavior under the hood. If it is failing just because it is taking too long for the test timeout, then that should get fixed once Todd does his "run the tests that failed and are marked flakey one by one after the main run is over" work. But in the meantime it wouldn't hurt to reduce the amount of work it does, and see if that clears up at least the timeouts. But some of the comments in that PR make it sound like it is uncovering actual bugs in handling breakpoint conditions in multi-threaded programs. It looked like in the discussion, the test is failing AFTER the continue, at which point all the test is doing is to wait for the program to stop running. So that must be some real bug in handling breakpoint conditions. In that case for sure the answer is to fix the code not the test. And of course, those bugs are going to make testing "many threads x ANYTHING x breakpoint conditions" fail, regardless of what ANYTHING is... OTOH it makes sense to add a test for JUST breakpoint thread ID's, since that we do seem to be able to handle reliably on more systems. http://reviews.llvm.org/D15241 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
