JesusFreke
smalidea: Inspect method parameters and local variables
It seem that there is no way to inspect v0, v1,... or p1, p2,... inside intelij unless the method parameters were explained with .param or the locals were explained with .local?
When I key in p1 into the watch window, intelij evaluate to "Internal error" which is correct because p1 is not a variable name, it's the virtual variable understood by smali compiler only.
Any way to inspect these? It seems that even jdb won't show these local variables without .local added to the source code.
Can you explain what you mean exactly? You're saying if you add source code to the decompiled smali, you're able to get the debugger to show the values? What do you have to add? Can you show an example?
Works for me already, but not in some cases (see https://github.com/JesusFreke/smali/issues/691)
I was looking into this a bit this evening, and it looks like there may be a bug in art that is preventing the retrieval of register values containing objects, unless there is a named local variable associated with the register. I haven't figured out why yet, it'll definitely require more digging. But if that's the case, fixing it will require a change in art itself, and so it may not be available for a while, and then only on the new versions of Android.
I found this post published in April last year which seems to describe the problem: https://www.pnfsoftware.com/blog/debugging-android-apps-on-android-pie-and-above/
The author was asking for pointers to AOSP commits for those changes, nothing in the comments though.
i hate the direction in which google is taking android. ive been saying the free software community has to fork away from google for years.
In this case, I think it's simply a bug. There is code in art to try to infer the register type in case the debug information is not there, but it doesn't seem to be working - https://android.googlesource.com/platform/art/+/a9bbc08daad6d601c870c8493323f57b70373336/openjdkjvmti/ti_method.cc#765
This is admittedly a bit of an esoteric case, because normal debuggers typically will only be querying the value of registers that do have the debugging information associated with them. It's a use case that is completely unsupported by jdi, and requires significant hacks to even get it to work (https://github.com/JesusFreke/smali/blob/8f7d1a897df243a8fafcaec6c193477e73f54ef3/smalidea/src/main/java/org/jf/smalidea/debugging/SmaliCodeFragmentFactory.java#L324 - eww!!)
normal debuggers typically will only be querying the value of registers that do have the debugging information associated with them
That is one of the reasons listed by the author of the blog linked above to say that it may actually be a feature. Was a bug filed for this?
I'm just planning on investigating and either gathering more info, or hopefully submitting a patch to fix the bug.
See, e.g. https://android.googlesource.com/platform/art/+/e48fd0b4780efadc6b3433fe7a56aa5be2a84325, which is specifically about adding support for this case.
Actually, I just realized - that support was added fairly recently - last year. But it doesn't look like it's in Android 10 (https://android.googlesource.com/platform/art/+/refs/heads/android10-release/openjdkjvmti/ti_method.cc). I'll see if I can do a build from master and see if it's working.
Actually, I just realized - that support was added fairly recently - last year. But it doesn't look like it's in Android 10 (https://android.googlesource.com/platform/art/+/refs/heads/android10-release/openjdkjvmti/ti_method.cc). I'll see if I can do a build from master and see if it's working.
I have the same issue with android 6.0.1 nexus 5. Debugging with android studio. Also sometimes, especially with variables p0, p1, p2, the debugger crash when i inspect their value. sometimes the whole process crash and I need to restart the app to debug again. The "this" reference always works tough
