IssueTracker

This does not happen when the 3rd breakpoint is set before stopping in c++ code. What's happening is when LLDB has stopped the process, it also stops the jdwp thread, so the breakpoint set for java code cannot be processed.  When LLDB is resumed, there is a race between the 'user' thread executing that line and the breakpoint set. In this case, the user thread is (almost) always winning, so it appears the breakpoint is not (and maybe cannot) be hit.

I confirmed this by adding a Thread.sleep(x) before the 3rd breakpoint location. When x = 4, it will sometimes hit the breakpoint, sometimes miss it.

Fixing this will be tricky. We need to delay threads other than the jdwp thread until all messages that are already queued have been processed.  We don't have a way to know when we're ready for other threads to run though.  There are ways that could be implemented in the platform, for example checking if all jdwp actions are done before continuing through a native->java transition.

There is probably a hacky way to mitigate it by starting the jdwp thread first, possibly with some additional small delay before starting the others.

This should also be documented as a known issue with the dual debugger, but I don't think we will be able to fix this for 2.3.

Contents scrubbed on user request by admin.

My vote: lets leave this as high priority since it's kind of a gross race, and investigate platform fixes for P.  wdyt?

Unassigning for now. We will process them incrementally over time.

I have some same problem with bumblebee that break points wont works even for Kotlin codes!