How to find calling thread stack trace from breakpoint?

Question

I have a Thread in my Android code and while debugging, I need to set a breakpoint inside the thread. However, once I am at the breakpoint inside the thread, I can't see the stacktrace of the calling thread. At this point, I usually need to set a new breakpoint at the calling thread and take it from there.

As you can see in the above image, the stack trace in the debugger shows run() as the top-level method. How can I move up in the stack trace, or switch threads to see start() and whatever came before it?

right click > analyse > "dataflow from here", see where it's run and put a breakpoint there — HopefullyHelpful, May 11 '17 at 15:42
Thanks @HopefullyHelpful but I don't want to have to set a new breakpoint each time. I would like to know how I can step into it without having to re-run my code. — The Hungry Androider, May 11 '17 at 15:59
if you are halting all threads in the options menu, then maybe you can jump into another thread with the debugger. — HopefullyHelpful, May 11 '17 at 16:06
Oh interesting! I'm trying to find this in Settings but no luck yet. Wanna show me where it is? — The Hungry Androider, May 11 '17 at 16:39

score 2 · Accepted Answer · answered May 15 '17 at 18:19

You cannot or shouldn't see the stacktrace of the first thread that created another thread. The way it works in multithreading is each will be working in parallel. What could happen is the first thread calls the creation of the second thread and then continues to execute other methods or work, while the OS takes care of creating the second thread and starting at certain time (usually ASAP) to do some execution as well. The second thread will be containing an almost stacktrace as the first method it is executing is run. It'll fill as the code accesses other methods and empties as it exits/finishes the methods it was executing. Hence a code like this:

Log.i("FirstThread", "creating secondThread");
Thread secondThread = new Thread(new Runnable() {
    @Override
    public void run() {
        Log.i("SecondThread", "run called");
    }
});
secondThread.start();
Log.i("FirstThread", "finished creating secondThread");

might end up with the following log:

FirstThread: creating secondThread
FirstThread: finished creating secondThread
SecondThread: run called

Bottom line is the first log will always be the first since the thread second thread is created after it, but the second and the third logs could switch at different times and trials (one comes before the other and vice versa). That's because they are working in parallel and the OS is managing the time the second thread starts and the resources for it do the execution.

You could see what the other thread is executing, however it could be the main UI thread of Android that you'll be seeing, so it could be not executing your code and be executing other things related to drawing your UI and system related stuff, hence to keep your application working.

To do so, just right click on the break point that you've placed within the thread, enable Suspend and choose All as the image below, then press Done:

Thanks for taking the time to explain this thoroughly. This makes sense. — The Hungry Androider, May 16 '17 at 12:28

How to find calling thread stack trace from breakpoint?

1 Answers1