labath added a comment. In http://reviews.llvm.org/D16767#341259, @amccarth wrote:
> I was chasing this same bug on Windows before I noticed you were working on > it. I patched in your latest diff, and the problem still occurs. That is not surprising. These fixes (r259344, and this one) are implemented in the os-specific classes: ProcessFreeBSD (used on freebsd, obviously), and ProcessGdbRemote (used on arches using lldb-server: linux, osx). I don't really like that, as I think this functionality could be abstracted to a common place, but that seems to be the way things are done currently. You could probably fix this by doing something similar in ProcessWindows. I.e., when you get a "stopped by single-step" event from the OS, check whether there is a breakpoint under your instruction, and if it is, report that as a breakpoint hit instead. > > FAIL: test_continue > > (TestConsecutiveBreakpoints.ConsecutiveBreakpointsTestCase) > > > > > > Test that continue stops at the second breakpoint. > > > > > > ---------------------------------------------------------------------- > > > > > > Traceback (most recent call last): > > > > > > File > > "D:\src\llvm\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", > > line 552, in wrapper > > > return func(self, *args, **kwargs) > > > File > > "D:\src\llvm\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\breakpoint\consecutive_breakpoints\TestConsecutiveBreakpoints.py", > > line 58, in test_continue > > > self.assertEquals(self.process.GetState(), lldb.eStateStopped) > > > > > > AssertionError: 10 != 5 > This is what the original test was doing. It just fails slightly sooner, because I added a new assert (10 is eStateExited, so your inferior exits because it failed to stop at the second breakpoint). > > FAIL: test_single_step > > (TestConsecutiveBreakpoints.ConsecutiveBreakpointsTestCase) > > > > > > Test that single step stops at the second breakpoint. > > > > > > ---------------------------------------------------------------------- > > > > > > Traceback (most recent call last): > > > > > > File > > "D:\src\llvm\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", > > line 552, in wrapper > > > return func(self, *args, **kwargs) > > > File > > "D:\src\llvm\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\breakpoint\consecutive_breakpoints\TestConsecutiveBreakpoints.py", > > line 76, in test_single_step > > > self.assertIsNotNone(self.thread, "Expected one thread to be stopped at > > breakpoint 2") > > > > > > AssertionError: unexpectedly None : Expected one thread to be stopped at > > breakpoint 2 > This is sort of testing the same thing, only it's using a single step command instead. I added it "by the way", while I was adding the third test. The failure mode is different as I didn't put the assert on the process state (I probably should do that). Hopefully you will be able to fix both failures in one go. > > RESULT: FAILED (1 passes > This is the regression introduced by the first patch. Without my fix the single step operation wouldn't stop correctly because of the thread-specific breakpoint. You want to make sure you don't regress here while fixing the first two. I am going ahead and committing this, as I don't think it will cause any regressions on your side. Let me know if you have any concerns. http://reviews.llvm.org/D16767 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
