#549 ArrayIndexOutOfBoundsException

[Alexey Aksenov]

I used Proguard in SBT plugin at https://github.com/digimead/sbt-application. I get ArrayIndexOutOfBoundsException when launch tests.

When I run it as standalone process with

java -jar proguard-base-5.1.jar @proguard.cfg

I get

Note: there were 14 accesses to class members by means of introspection.
      You should consider explicitly keeping the mentioned class members
      (using '-keep' or '-keepclassmembers').
      (http://proguard.sourceforge.net/manual/troubleshooting.html#dynamicalclassmember)
Note: you're ignoring all warnings!
Error: 2

If you want to reproduce an error then you may use an attached archive.

Environment Java 7 & Java 8
Linux devbox 3.17.0-gentoo #1 SMP PREEMPT Wed Oct 15 10:21:18 MSK 2014 x86_64 Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz GenuineIntel GNU/Linux

[info] java.lang.ArrayIndexOutOfBoundsException: 4
[info]  at proguard.classfile.editor.InterfaceDeleter.visitSignatureAttribute(InterfaceDeleter.java:162)
[info]  at proguard.classfile.attribute.SignatureAttribute.accept(SignatureAttribute.java:97)
[info]  at proguard.classfile.ProgramClass.attributesAccept(ProgramClass.java:547)
[info]  at proguard.classfile.editor.InterfaceDeleter.visitProgramClass(InterfaceDeleter.java:92)
[info]  at proguard.shrink.ClassShrinker.visitProgramClass(ClassShrinker.java:78)
[info]  at proguard.classfile.visitor.MultiClassVisitor.visitProgramClass(MultiClassVisitor.java:85)
[info]  at proguard.shrink.UsedClassFilter.visitProgramClass(UsedClassFilter.java:62)
[info]  at proguard.classfile.ProgramClass.accept(ProgramClass.java:358)
[info]  at proguard.classfile.ClassPool.classesAccept(ClassPool.java:124)
[info]  at proguard.shrink.Shrinker.execute(Shrinker.java:153)
[info]  at proguard.ProGuard.shrink(ProGuard.java:286)
[info]  at proguard.ProGuard.execute(ProGuard.java:112)
[info]  at sbt.application.proguard.Proguard$$anonfun$proguardTask$1.apply(Proguard.scala:62)
[info]  at sbt.application.proguard.Proguard$$anonfun$proguardTask$1.apply(Proguard.scala:49)
[info]  at scala.Function9$$anonfun$tupled$1.apply(Function9.scala:35)
[info]  at scala.Function9$$anonfun$tupled$1.apply(Function9.scala:34)
[info]  at scala.Function1$$anonfun$compose$1.apply(Function1.scala:47)
[info]  at sbt.$tilde$greater$$anonfun$$u2219$1.apply(TypeFunctions.scala:40)
[info]  at sbt.std.Transform$$anon$4.work(System.scala:63)
[info]  at sbt.Execute$$anonfun$submit$1$$anonfun$apply$1.apply(Execute.scala:226)
[info]  at sbt.Execute$$anonfun$submit$1$$anonfun$apply$1.apply(Execute.scala:226)
[info]  at sbt.ErrorHandling$.wideConvert(ErrorHandling.scala:17)
[info]  at sbt.Execute.work(Execute.scala:235)
[info]  at sbt.Execute$$anonfun$submit$1.apply(Execute.scala:226)
[info]  at sbt.Execute$$anonfun$submit$1.apply(Execute.scala:226)
[info]  at sbt.ConcurrentRestrictions$$anon$4$$anonfun$1.apply(ConcurrentRestrictions.scala:159)
[info]  at sbt.CompletionService$$anon$2.call(CompletionService.scala:28)
[info]  at java.util.concurrent.FutureTask.run(FutureTask.java:262)
[info]  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
[info]  at java.util.concurrent.FutureTask.run(FutureTask.java:262)
[info]  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[info]  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[info]  at java.lang.Thread.run(Thread.java:745)

[Eric Lafortune]

Thanks for your report. I've studied this problem recently, and it turned out to be a corruption in the class signatures in the Scala runtime. I've reported it here:
https://issues.scala-lang.org/browse/SI-8931
The Scala team has now marked it as fixed and closed. The fix seems to have been merged into Scala 2.11.x a few days ago (not the current official 2.11.4). I don't know the easiest way to obtain it; please let us know if you do.

[Perry Nguyen]

On a related note, this issue does not occur on proguard 5.0.

Is there any way to make this work on a current version of proguard without having to wait for a new scala version release which can take ... forever?

[Eric Lafortune]

I don't have a work-around right now. You could try catching the exception and leaving the signature untouched -- the Scala runtime doesn't seem to be sensitive to it being inconsistent anyway.

[Perry Nguyen]

How would I catch the exception? I believe this would involve using my own fork of proguard that would catch this exception in InterfaceDelegater?

[Eric Lafortune]

Yes. ProGuard comes with its source code and some alternative ways to build it (make, bash, Ant,...) Catching and ignoring the exception in InterfaceDeleter should be easy. There may be other places though.

[Perry Nguyen]

Yeah, not an appealing solution for me at the moment. Building is no problem, and so is publishing to maven, but I don't want to fork for something that will be relatively short-lived. For now, my users will all be on proguard 5.0 unless they have bugs that specifically require 5.1 (and if using scala, are able to upgrade to 2.11.5)