Logging a stack trace is a useful way to tell why a method is being called. But it's not always so easy to log a backtrace.
Tools like dtrace and linux-perf can log stack traces when you hit a "tracepoint", which are very helpful for answering questions like "who is filling up this disk", "what is causing so much network traffic". These can be pretty handy for testing hypotheses when seeing production bugs.
I would like to log a backtrace whenever I hit a method in an obfuscated Android app.
If you have the source code to the app, and the app is in debug mode (not obfuscated by ProGuard), this is easy: open Android Studio, click in the left-margin of the source code to add a breakpoint, untick the "Suspend" checkbox and tick the "Logging Options – Stack trace" checkbox.
Now whenever the code hits that line, a backtrace will be logged to the debug console.
But if your app is obfuscated, then from the virtual machine's perspective, all the code has obfuscated line numbers like
(PG:1), so clicking in the code margin of
MyProblematicClass.myProblematicMethod doesn't work. We have the
proguard_map.txt, so we know what the function is we want to break on: perhaps
MyProblematicClass.myProblematicMethod() maps to
ile.a(), and we'd like to log a stack trace anytime that method is hit.
IntelliJ/Android Studio has a "Method Breakpoint" but it's implemented by tracing every method execution in your app, which will make your app grind to a halt. What we really want is to only have the overhead when we hit the method; like a normal line breakpoint does, which keeps performance snappy under debugger.
I couldn't find a way to add a breakpoint on a method name in IntelliJ/Android Studio, nor in Eclipse; both unfortunately seem to assume you will only add a breakpoint by clicking in the margin of a source file.
However, the low-level command-line
jdb Java Debugger that ships with the JDK can add a method breakpoint, at low cost. It's a bit janky, but it works. Here's how to use it for Android apps:
First, close Android Studio (it will interfere with the debugger port)
Next, make sure your app is open that you want to trace.
Find your application's process ID:
$ adb shell pidof com.google.android.apps.maps 1160
Verify that this process has JDWP (you have to Ctrl-C after):
$ adb jdwp | grep 1160 1160 ^C
Forward a port from your computer to the JDWP of that process:
$ adb forward tcp:8700 jdwp:1160
$ jdb -attach localhost:8700 Set uncaught java.lang.Throwable Set deferred uncaught java.lang.Throwable Initializing jdb ... >
If it works, you will get a
> prompt. This will hang if you haven't closed Android Studio first.
Set up logging a backtrace every time the app stops at a breakpoint:
> monitor where
Tell the app to automatically 'resume' (continue) after logging the backtrace:
> monitor cont
Finally, attach the method breakpoint:
> stop at ile.a Set breakpoint ile.a
If your method is overloaded, you will have to specify the overload arguments, like this:
> stop at java.lang.String.indexOf(java.lang.String) Set breakpoint java.lang.String.indexOf(java.lang.String)
All going well, you should now get method backtraces whenever your code hits
Breakpoint hit: "thread=ThreadPool3", ile.a(), line=1 bci=0  ile.a (PG:1)  inr.b (PG:26)  lzq.f (PG:61)  lzq.d (PG:18)  lmw.run (PG:50)  irl.run (PG:2)  isj.run (PG:2)  java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1,167)  java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:641)  hbj.run (PG:102)  java.lang.Thread.run (Thread.java:920) TilePrepPool3 > > Breakpoint hit: "thread=DefaultPool5", ile.a(), line=1 bci=0  ile.a (PG:1)  iok.c (PG:1)  hlz.a (PG:308)  ifg.run (PG:6)  irl.run (PG:2)  isj.run (PG:2)  java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1,167)  java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:641)  hbj.run (PG:102)  java.lang.Thread.run (Thread.java:920) DefaultPool5 > >
These are obfuscated, but you can now deobfuscate them, and find out what method was responsible for
ile.a getting called (it was because of
Putting it all together into a bash one-liner (with inspiration from Poor Man's Profiler for the
/dev/zero trick to avoid sending EOF):
$ (echo "monitor where"; echo "monitor cont"; echo "stop at ile.a"; cat /dev/zero) | jdb -attach localhost:8700