Compile with Proguard gives SimException: "local variable type mismatch"
Asked Answered
A

4

49

When I compile my Android Application with Proguard enabled I get the following error:

-dex:
 [echo] Converting compiled files and external libraries into /home/ka/dev/workspace/ImPress/build/classes.dex...
[apply] 
[apply] UNEXPECTED TOP-LEVEL EXCEPTION:
[apply] com.android.dx.cf.code.SimException: local variable type mismatch: attempt to set or access a value of type java.io.File using a local variable of type java.lang.Object[]. This is symptomatic of .class transformation tools that ignore local variable information.
[apply]     at com.android.dx.cf.code.BaseMachine.throwLocalMismatch(BaseMachine.java:550)
[apply]     at com.android.dx.cf.code.BaseMachine.getLocalTarget(BaseMachine.java:405)
[apply]     at com.android.dx.cf.code.BaseMachine.storeResults(BaseMachine.java:532)
[apply]     at com.android.dx.cf.code.ValueAwareMachine.run(ValueAwareMachine.java:197)
[apply]     at com.android.dx.cf.code.RopperMachine.run(RopperMachine.java:291)
[apply]     at com.android.dx.cf.code.Simulator$SimVisitor.visitLocal(Simulator.java:608)
[apply]     at com.android.dx.cf.code.BytecodeArray.parseInstruction(BytecodeArray.java:526)
[apply]     at com.android.dx.cf.code.Simulator.simulate(Simulator.java:99)
[apply]     at com.android.dx.cf.code.Ropper.processBlock(Ropper.java:684)
[apply]     at com.android.dx.cf.code.Ropper.doit(Ropper.java:639)
[apply]     at com.android.dx.cf.code.Ropper.convert(Ropper.java:252)
[apply]     at com.android.dx.dex.cf.CfTranslator.processMethods(CfTranslator.java:252)
[apply]     at com.android.dx.dex.cf.CfTranslator.translate0(CfTranslator.java:131)
[apply]     at com.android.dx.dex.cf.CfTranslator.translate(CfTranslator.java:85)
[apply]     at com.android.dx.command.dexer.Main.processClass(Main.java:369)
[apply]     at com.android.dx.command.dexer.Main.processFileBytes(Main.java:346)
[apply]     at com.android.dx.command.dexer.Main.access$400(Main.java:59)
[apply]     at com.android.dx.command.dexer.Main$1.processFileBytes(Main.java:294)
[apply]     at com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:244)
[apply]     at com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:130)
[apply]     at com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:108)
[apply]     at com.android.dx.command.dexer.Main.processOne(Main.java:313)
[apply]     at com.android.dx.command.dexer.Main.processAllFiles(Main.java:233)
[apply]     at com.android.dx.command.dexer.Main.run(Main.java:185)
[apply]     at com.android.dx.command.dexer.Main.main(Main.java:166)
[apply]     at com.android.dx.command.Main.main(Main.java:90)
[apply] ...at bytecode offset 00000006
[apply] locals[0000]: Lcom/officemax/impress/ui/library/task/DocumentBrowserTask;
[apply] locals[0001]: [Ljava/lang/Object;
[apply] locals[0002]: <invalid>
[apply] ...while working on block 0006
[apply] ...while working on method doTaskJob:([Ljava/lang/Object;)Lcom/kaciula/utils/ui/BasicTaskResponse;
[apply] ...while processing doTaskJob ([Ljava/lang/Object;)Lcom/kaciula/utils/ui/BasicTaskResponse;
[apply] ...while processing com/officemax/impress/ui/library/task/DocumentBrowserTask.class
[apply] 
[apply] 1 error; aborting

How can I fix this problem?

Actinism answered 18/4, 2011 at 9:50 Comment(3)
I ended up reporting this because I felt like it was the better thing to do, rather than ignoring the already silent issue: sourceforge.net/tracker/…Skeie
Please let me know when you found a solution to this. I really need to shrink my apps because I use a lot of libraries.Actinism
I closed the bug. I think we have to live with the workarounds.Skeie
S
15

The actual Proguard part finishes, but then dex cannot convert the resulting bytecode anymore. Dex considers the LocalVariableTable incorrect. Eric Lafortune is the better source to explain why (see his answer).

The problem goes away if you not only don't obfuscate, but also skip the optimization step (-dontoptimize). But you want to have this for the size reduction. Another way to solve it is to drop the debug flags in javac and in dex. Only problem is that then you wouldn't have proper stacktraces either. You will get stacktrace lines without source file info or line numbers such as:

net.lp.collectionista.domain.items.book.BookItem.getCoverImageForFormField(Unkno‌​wn Source)

You can do this by adding debug="false" in the javac tag in the ant main-rules.xml (you may want to copy the part to a build.xml first). This will set a flag javac -g:none. You also have to configure dex and this is harder to do in the provided ant template. I copied the dex-helper macro, made sure it was being used, and added a condition tag surrounding the dex calls:

        <echo>Converting compiled files and external libraries into ${intermediate.dex.file}...</echo>
        <if condition="debug">
            <then>
                <apply executable="${dx}" failonerror="true" parallel="true">
                    <arg value="--dex" />
                    <arg value="--output=${intermediate.dex.file}" />
                    <extra-parameters />
                    <arg line="${verbose.option}" />
                    <arg path="${out.dex.input.absolute.dir}" />
                    <path refid="out.dex.jar.input.ref" />
                    <external-libs />
                </apply>
            </then>
            <else>
                <apply executable="${dx}" failonerror="true" parallel="true">
                    <arg value="--dex" />
                    <arg value="--output=${intermediate.dex.file}" />
                    <arg value="--no-locals" /><!-- otherwise dex fails on the proguard bytecode -->
                    <extra-parameters />
                    <arg line="${verbose.option}" />
                    <arg path="${out.dex.input.absolute.dir}" />
                    <path refid="out.dex.jar.input.ref" />
                    <external-libs />
                </apply>
            </else>
        </if>

It's the --no-locals that does it.

To mitigate the loss of stacktrace information you can use, respectively for line number information and class and method names information:

-keepattributes SourceFile, LineNumberTable
-keep,allowshrinking,allowoptimization class * { <methods>; }

This way you can do partial obfuscation, and still have equivalent good stacktraces. I still suggest you create and keep the mapping files upon release though.

On top of all this you shouldn't specify -keepattributes LocalVariableTable,LocalVariableTypeTable and equally -keepparameternames (if you do obfuscate, this by itself might get you into troubles as well). Note that the second implies the first, even though it may not be clear from its name that it affects attributes.

Personally, and in view of other problems with Proguard, I chose to do the obfuscation but mitigate the loss of stacktrace information. I haven't tried @plowman's proposal yet.

For more details you can find my version controlled project files here:

Skeie answered 2/11, 2011 at 18:52 Comment(2)
When you are using gradle you can add the following bit to add the --no-locals parameter to the dex step: project.tasks.withType(com.android.build.gradle.tasks.Dex) { additionalParameters=['--no-locals'] }Geo
@JohanPelgrim's suggested bit for adding --no-locals can be put into the buildTypes { release { block in the module's build.gradle. Thanks, Johan!Jainism
F
98

I ran into the same problem after adding the -dontobfuscate flag to my proguard.cfg file.

The solution ended up being that I needed to add this to my optimizations:

!code/allocation/variable

This makes my complete optimization string look like this:

-optimizations !field/removal/writeonly,!field/marking/private,!class/merging/*,!code/allocation/variable
Freed answered 28/9, 2011 at 18:20 Comment(7)
I wasn't even using -dontobfuscate but was getting errors, and making only this change solved the problem for me. Thanks!Breve
It would be useful if someone could confirm that this still occurs on ADT-20, which by now uses more intelligent ways to deal with libs, as well as ProGuard 4.7. And that this method solves that. The solution I described above is dated because the build.xml has been changed a lot, though the principle still applies.Skeie
@Skeie I can confirm that it still works on ADT-20, and that adding !code/allocation/variable to my local ProGuard configuration file works. Mine looks like: -optimizations !code/simplification/arithmetic,!code/simplification/cast,!field/*,!class/merging/*, !code/allocation/variableTocantins
I saw this error with ADT SDK tools r21.1 and platform-tools 16.0.2. Adding !code/allocation/variable to the optimizations fixed the error.Pueblo
This answer fixed a similar error for me with Android Studio 1.2.2. I was getting the error when trying to debug even though the debug buildType had minifyEnabled falseFrankel
Confirming that I got this error in Android Studio 1.3.2, and this answer solved it (as did @pjv's).Jainism
This is back again on studio 2.3 with the latest android build tools 25.0.2 and compiled for 25.Overstock
J
22

This is a bug in ProGuard. Its optimization step sometimes doesn't update the optional "LocalVariableTable" and "LocalVariableTypeTable" debug attributes inside class files entirely correctly. The Dalvik VM explicitly checks the debug attributes and rejects the class files if they are inconsistent.

You should check if the latest version of ProGuard fixes the problem. Otherwise, you should remove local variable names and types from the class files. You can ask the java compiler not to generate them (e.g. "javac -g:none"). You can also ask ProGuard not to keep them (don't specify "-keepattributes LocalVariableTable,LocalVariableTypeTable").

Jaramillo answered 19/4, 2011 at 20:0 Comment(8)
Thanks for the answer. I've added the latest version of proguard but the problem is still there. It gives the same exception but in one of my jars. Still, in my proguard.cfg I don't have "-keepattributes LocalVariableTable,LocalVariableTypeTable". Can I somehow explicitly say that I don't want proguard to keep local variable names etc.?Actinism
Did you change anything in proguard.cfg? Did you perhaps add "-dontobfuscate"?Jaramillo
dex has an option --no-locals However, updating the jars in <android install>/tools/proguard/lib/ to the latest 4.6 version fixed this for me. ( thanks @Eric ) Oddly, the shrinking (optimization) alone still shows these errors, but obfuscating and shrinking together succeeds.Calamus
@Eric, do you have a proguard bugtracker report for it? I still can't find a workaround (none of the above get me anywhere) that lets me keep -dontobfuscate, and we are not all java bytecode specialists.Skeie
Using -g:none on javac (by means of debug="false" in target "compile") and --no-locals on target "-dex" in ant, I could workaround this problem but it still smells horribly. I believe one limitation now is I will need to create different targets for my debug output (and that can only work without proguard), and maybe some problems with stacktraces.Skeie
Ok, so indeed I now get stack traces without line numbers, such as: net.lp.collectionista.domain.items.book.BookItem.getCoverImageForFormField(Unknown Source). But I of course don't get a mapping file either after optimization (and I'm using -dontobfuscate). How do i get my stack traces correct? This is a problem for me as I need to analyze crashes that happened on the users side.Skeie
I have the same problem. I need -dontobfuscate for stacktraces and other stuff. I just need to shrink the application size.Actinism
Any update on this? 4.8 doesn't resolve this bug. EDIT: plowman's solution, adding !code/allocation/variable, resolved the issueAubervilliers
S
15

The actual Proguard part finishes, but then dex cannot convert the resulting bytecode anymore. Dex considers the LocalVariableTable incorrect. Eric Lafortune is the better source to explain why (see his answer).

The problem goes away if you not only don't obfuscate, but also skip the optimization step (-dontoptimize). But you want to have this for the size reduction. Another way to solve it is to drop the debug flags in javac and in dex. Only problem is that then you wouldn't have proper stacktraces either. You will get stacktrace lines without source file info or line numbers such as:

net.lp.collectionista.domain.items.book.BookItem.getCoverImageForFormField(Unkno‌​wn Source)

You can do this by adding debug="false" in the javac tag in the ant main-rules.xml (you may want to copy the part to a build.xml first). This will set a flag javac -g:none. You also have to configure dex and this is harder to do in the provided ant template. I copied the dex-helper macro, made sure it was being used, and added a condition tag surrounding the dex calls:

        <echo>Converting compiled files and external libraries into ${intermediate.dex.file}...</echo>
        <if condition="debug">
            <then>
                <apply executable="${dx}" failonerror="true" parallel="true">
                    <arg value="--dex" />
                    <arg value="--output=${intermediate.dex.file}" />
                    <extra-parameters />
                    <arg line="${verbose.option}" />
                    <arg path="${out.dex.input.absolute.dir}" />
                    <path refid="out.dex.jar.input.ref" />
                    <external-libs />
                </apply>
            </then>
            <else>
                <apply executable="${dx}" failonerror="true" parallel="true">
                    <arg value="--dex" />
                    <arg value="--output=${intermediate.dex.file}" />
                    <arg value="--no-locals" /><!-- otherwise dex fails on the proguard bytecode -->
                    <extra-parameters />
                    <arg line="${verbose.option}" />
                    <arg path="${out.dex.input.absolute.dir}" />
                    <path refid="out.dex.jar.input.ref" />
                    <external-libs />
                </apply>
            </else>
        </if>

It's the --no-locals that does it.

To mitigate the loss of stacktrace information you can use, respectively for line number information and class and method names information:

-keepattributes SourceFile, LineNumberTable
-keep,allowshrinking,allowoptimization class * { <methods>; }

This way you can do partial obfuscation, and still have equivalent good stacktraces. I still suggest you create and keep the mapping files upon release though.

On top of all this you shouldn't specify -keepattributes LocalVariableTable,LocalVariableTypeTable and equally -keepparameternames (if you do obfuscate, this by itself might get you into troubles as well). Note that the second implies the first, even though it may not be clear from its name that it affects attributes.

Personally, and in view of other problems with Proguard, I chose to do the obfuscation but mitigate the loss of stacktrace information. I haven't tried @plowman's proposal yet.

For more details you can find my version controlled project files here:

Skeie answered 2/11, 2011 at 18:52 Comment(2)
When you are using gradle you can add the following bit to add the --no-locals parameter to the dex step: project.tasks.withType(com.android.build.gradle.tasks.Dex) { additionalParameters=['--no-locals'] }Geo
@JohanPelgrim's suggested bit for adding --no-locals can be put into the buildTypes { release { block in the module's build.gradle. Thanks, Johan!Jainism
M
6

I just had this resurface on Windows' Android Studio, and disabling Instant Run made things work again.

Microminiaturization answered 12/5, 2016 at 6:38 Comment(2)
Thank you! I had the same problem Android Studio 2.1.2 on OSX. Disabling Instant Run made this problem go away.Racket
This is back again on studio 2.3 with the latest android build tools 25.0.2 and compiled for 25.Overstock

© 2022 - 2024 — McMap. All rights reserved.