-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
java.lang.IndexOutOfBoundsException: Index 12 out of bounds for length 12 #1739
Comments
I am able to reproduce this issue. The **void onItemClick(AdapterView<?> arg0, View arg1, int arg2, long arg3) ** method is causing it to crash on the MainActivity. it also crashes on the ColorListActivity class caused by the same onItemClick method within that class. Crash is caused because the codeReader.getRegistersCount() function is returning 12 to set the size of the regList on SmaliMethodNode.java. OutOfBounds occurs when the Smali.formatMthParamInfo function is attempting to set at least 13 registries. It crashes when in the for loop iterating over the types List. I need to do more testing to figure out why the incorrect number of registries is being returned. |
About to submit a pull request with a fix. See below for my analysis on what caused this issue. Bug Cause Fix |
@jmlitfi thanks for the fix, it looks good to me 👍 |
I was thinking about my fix last night and it only works if "for (ILocalVar var : dbgInfo.getLocalVars())" reads the registries in order. As far as I can tell it should always be in order but if you think getLocalVars() could return out of order it might make sense to save the start of the parameter registries and do a greater than instead of doing the == as I did. As long as we have a reliable way of checking if a registry is part of the parameters or local it should work. Agreed that a unit test makes sense. To assist in readability I think it would also help to add comments on which function handles which part of the bytecode format as it took a bit of time to narrow down which functions parse what. |
@skylot I am a bit concerned that your changes doesn't fix the actual problem. I dont think that using the var.getStartOffset() <= 0 is a reliable way of checking if something is a parameter. I could be wrong but I think you need to calculate the start of parameter registries (line.smaliMthNode.getParamRegStart()) then do a check if the variable reg number (var.getRegNum()) is greater than or equal to the start of the parameter registries. My understanding of the dex format from reading over https://source.android.com/docs/core/runtime/dex-format#debug-info-item is that parameters should be passed in the "parameter_names" array which is what JadX checked for originally as anything in the parameter_names array will get a -1 for getStartOffset(). I dont fully understand what is causing it but looking at the apk shared by kiber-io the first value of the parameter_names array is null (which JadX will skip). Directly after the "parameter_name" array the dex format will send the DBG variables with the first DBG variable having a getStartOffset() of 0. In the provided APK the first DBG variable is DBG_START_LOCAL_EXTENDED which comparing the registry number with the calculated start registry for the parameters I can tell it is the first parameter. |
See the below image for my debugging messages. The DebugInfoParser class handles parsing of the debug_info_item which populates the variables. I pushed my log statements to the https://github.com/jmlitfi/jadx/tree/issue_1739 branch to help with tracing the code flow. |
@jmlitfi I understand your confusion here, because in debug info first parameter ( .registers 10
.param p2, "arg1" # Landroid/view/View;
.param p3, "arg2" # I
.param p4, "arg3" # J
.line 69
.local p1, "arg0":Landroid/widget/AdapterView;, "Landroid/widget/AdapterView<*>;" |
@skylot Thanks for your commit. I have not tested but reading over your code I think it is a good way to handle this issue. |
When trying to switch the MainActivity class to smali view, an error occurs :(
APK: https://disk.yandex.ru/d/n6yXdRpi9pE3xg
The text was updated successfully, but these errors were encountered: