Infeasible
Status Update
Comments
an...@google.com <an...@google.com> #2
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.
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.
[Deleted User] <[Deleted User]> #3
Contents scrubbed on user request by admin.
ks...@google.com <ks...@google.com> #4
My vote: lets leave this as high priority since it's kind of a gross race, and investigate platform fixes for P. wdyt?
an...@google.com <an...@google.com>
em...@google.com <em...@google.com> #5
Unassigning for now. We will process them incrementally over time.
ar...@google.com <ar...@google.com>
ma...@gmail.com <ma...@gmail.com> #6
I have some same problem with bumblebee that break points wont works even for Kotlin codes!
Description
Android Studio 2.3 Canary 3
Build #AI-162.3561852, built on December 9, 2016
JRE: 1.8.0_112-release-b05 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
NDK: 14.0.3529234 rc1
LLDB: 2.3.3549278
Steps to reproduce:
1. Import the sample Audio Echo
2. Open the file MainActivity.java and place a break point at the line
status_view = (TextView)findViewById(R.id.statusView);
3. Open the file audio_main.cpp and put a breakpoint in the method
Java_com_google_sample_echo_MainActivity_createSLEngine(
JNIEnv *env, jclass type, jint sampleRate, jint framesPerBuf) {
4. Hit the debug button. First the breakpoint set in step 2 will get hit . Press F9 and then the one in step 3
5. Now open the file MainActivity.java and place a break point at the line
isPlaying = false;
6. Now press F9 again to resume
Expected result:
Breakpoint set in step 6 should get hit
Actual result:
Breakpoint is not hit