dontpreverify leaves malformed preverification data
Java class file shrinker, optimizer, obfuscator, and preverifier
Brought to you by:
guardsquare
Menu
▾
▴
1 Attachments
#504 dontpreverify leaves malformed preverification data
Greetings, I happen to work for Google on an android app, and ran into an issue. I also come bearing a patch :-)
Steps to reproduce failure:
- Create a JAR that is already preverified (e.g. one compiled with JDK7)
- Feed that as input to Proguard with both -dontpreverify and -optimize
- Feed that JAR back into Proguard
Proguard will fail with a message saying the StackTableMap contains invalid verification types outside the range of 1-9:
Error: Can't read [/build/cas/2b7/2b7ca8993268c2fcbe8b9b3042f22679] (Can't process class [com/google/android/apps/plus/content/EsApiProvider.class] (Unknown verification type [79] in stack map frame))
ERROR: /google/src/cloud/gboyer/esa/google3/java/com/google/android/apps/plusone/BUILD:833:1: Generating streamlined input jar for main dex classes list //java/com/google/android/apps/plusone:PlusOnePre-v19-multidex_stripped_jar failed (Exit 1).
It appears that during optimization, the old preverification information is left in. However, the information is now nonsensical. My patch is to strip preverification information when no preverification info is provided.
Ick, I forgot to remove unused imports.
It's been a long time since I've used Sourceforge and Mercurial. Please let me if there is a more proper way to submit a patch.
Forgot to add, bug is also valid at tip. (My patch is based on tip).
Thanks for your report. The option -dontpreverify should be used with care. It can result in invalid preverification information, notably if at the same time, obfuscation is disabled (-dontobfuscate) or stack map table attributes are kept (-keepattributes StackMapTable). The obfuscation step by default removes the old stack map table attributes, and the preverification step recomputes them.
I would only use the option for applications that are transformed to Dalvik bytecode right away, in which case the stack map table attributes are irrelevant and ignored. I would not use it for libraries that may undergo further processing.
That being said, it's probably better to protect users from confusing cases like this one. I don't take external code contributions or patches, but I'll see what I can do.
I don't know why I didn't just think of removing that attribute.
We don't preverify since it nearly doubles the total runtime in the
particular config we are using.
On Mar 19, 2014 7:05 PM, "Eric Lafortune" lafortune@users.sf.net wrote:
Related
Bugs:
#504Actually, I think the problem is our combination of flags. This is for a
development build where we don't obfuscate, but keep some optimizations on,
and don't want to preverify because it's slow. The attribute filter is
applied however only as part of obfuscation. Perhaps if the attribute
filter could be run even when obfuscation is off, that'd solve the issue
for us.
We enable some optimization, otherwise we can't keep under the dex limit.
But it seems we can work around by either obfuscationg or enabling
preverify.
ProGuard now always clears preverification information if the option -dontpreverify is specified. Coming up in ProGuard 5.0 beta1.