labath added a comment.
In http://reviews.llvm.org/D18886#397843, @amccarth wrote:
> It's weird in that, if you run the test independently, it passes. But if you
> run it with the multiprocess test runner (ninja check-lldb), then it fails on
> this line:
>
> self.fail("Setting a breakpoint generated an unexpected event: %s" %
> lldb.SBDebugger.StateAsCString(lldb.SBProcess.GetStateFromEvent(event)))
>
> The state in this case is stopped.
I suspect this test has uncovered a problem in the ProcessWindows
implementation. The same problem we were solving here for ProcessGdbRemote.
Namely, the question here is what happens if we try to set a breakpoint while
the process is running. ProcessGdbRemote (and I expect ProcessWindows as well)
needs to stop the inferior to be able to set the breakpoint. However, since
this stop wasn't requested by the user, it should not generate any externally
visible stops. The process should be silently resumed after you are done with
it (I have no idea how is this supposed to be done with the non-gdb-remote
processes).
I suspect the test is flaky for you because of different timings when running
under heavy system load, but after the issue is fixed the test should pass 100%
of time. Unfortunately, I think this task will be up to you. :)
http://reviews.llvm.org/D18886
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
