New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
smalidea: Inspect method parameters and local variables #737
Comments
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 #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 ( smali/smalidea/src/main/java/org/jf/smalidea/debugging/SmaliCodeFragmentFactory.java Line 324 in 8f7d1a8
|
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. |
I have the same issue with android 6.0.1 nexus 5. Debugging with android studio. |
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.The text was updated successfully, but these errors were encountered: