IssueTracker

I forgot to mention that this bug only happens when setting testCoverageEnabled to true in the Gradle file of the module.

debug {
        debuggable true
        testCoverageEnabled true
}

I have a very similar issue when trying to create a fragment.

Commenting this method would allow it to run fine.
private void pinLengthChanged(int pinLength){
    loginButton.setEnabled(pinLength == MAX_PIN_LENGTH);
}

Uncommenting this method would throw this exception:

11-26 10:17:12.207  31169-31169/io.thi.healthyu E/AndroidRuntime﹕ FATAL EXCEPTION: main
    Process: io.thi.healthyu, PID: 31169
    java.lang.VerifyError: Rejecting class libthi.thi.io.fragments.PinLoginFragment because it failed compile-time verification (declaration of 'libthi.thi.io.fragments.PinLoginFragment' appears in /data/app/io.thi.healthyu-1/base.apk)
            at libthi.thi.io.activities.LoginActivity.initializeFragments(LoginActivity.java:134)
            at libthi.thi.io.activities.BaseActivity.onCreate(BaseActivity.java:67)
            at android.app.Activity.performCreate(Activity.java:5933)
            at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1105)
            at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2251)
            at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2360)
            at android.app.ActivityThread.access$800(ActivityThread.java:144)
            at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1278)
            at android.os.Handler.dispatchMessage(Handler.java:102)
            at android.os.Looper.loop(Looper.java:135)
            at android.app.ActivityThread.main(ActivityThread.java:5221)
            at java.lang.reflect.Method.invoke(Native Method)
            at java.lang.reflect.Method.invoke(Method.java:372)
            at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:899)
            at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:694)

Tested on:
  * a Nexus 5 with Android API 21 (5.0) and ART

Compiled:
  * Android Studio Beta 0.8.14 build AI-135.1538390 (October 23, 2014)
  * OSX
  * Build tools 20.0.0

Confirmed Removing `testCoverageEnabled true` from the Gradle file prevents the VerifyError.

More details from the bugreport

11-26 14:27:28.017  2592  2592 I dex2oat : /system/bin/dex2oat --zip-fd=6 --zip-location=/data/app/fr.inra.arttest-1/base.apk --oat-fd=7 --oat-location=/data/dalvik-cache/arm/data@app@fr.inra.arttest-1@base.apk@classes.dex --instruction-set=arm --instruction-set-features=div --runtime-arg -Xms64m --runtime-arg -Xmx512m

11-26 14:27:28.090  2592  2594 W dex2oat : mismatched stack depths (depth=0, incoming depth=1)

11-26 14:27:28.090  2592  2594 I dex2oat : Verification error in void fr.inra.arttest.MyClass.myOtherMethod()

11-26 14:27:28.090  2592  2594 I dex2oat : void fr.inra.arttest.MyClass.myOtherMethod() failed to verify: expected to be within a catch-all for an instruction where a monitor is held

11-26 14:27:28.094  2592  2594 E dex2oat : Verification failed on class fr.inra.arttest.MyClass in /data/app/fr.inra.arttest-1/base.apk because: Verifier rejected class fr.inra.arttest.MyClass due to bad method void fr.inra.arttest.MyClass.myOtherMethod()

11-26 14:27:28.555  2592  2592 I dex2oat : dex2oat took 538.531ms (threads: 4)

"expected to be within a catch-all for an instruction where a monitor is held" was also seen in issue 36949180

quinn.j.n, as I hinted in #5, the real issue should be logged earlier during dex2oat compilation and could actually be a very different issue. If so, please open a new bug.

forgot to add this is now internal issue 36949180, in addition to being similar to 18098280

Here is the dexdump of the bad method:

  Virtual methods   -
    #0              : (in Lfr/inra/arttest/MyClass;)
      name          : 'myOtherMethod'
      type          : '()V'
      access        : 0x0001 (PUBLIC)
      code          -
      registers     : 7
      ins           : 1
      outs          : 3
      insns size    : 53 16-bit code units
01057c:                                        |[01057c] fr.inra.arttest.MyClass.myOtherMethod:()V
01058c: 1215                                   |0000: const/4 v5, #int 1 // #1
01058e: 7100 0f00 0000                         |0001: invoke-static {}, Lfr/inra/arttest/MyClass;.$jacocoInit:()[Z // method@000f
010594: 0c02                                   |0004: move-result-object v2
010596: 1a01 5500                              |0005: const-string v1, "ARTTEST" // string@0055
01059a: 1a03 db00                              |0007: const-string v3, "Execute myOtherMethod" // string@00db
01059e: 7120 0200 3100                         |0009: invoke-static {v1, v3}, Landroid/util/Log;.d:(Ljava/lang/String;Ljava/lang/String;)I // method@0002
0105a4: 5463 0b00                              |000c: iget-object v3, v6, Lfr/inra/arttest/MyClass;.myLock:Ljava/lang/Object; // field@000b
0105a8: 1d03                                   |000e: monitor-enter v3
0105aa: 1211                                   |000f: const/4 v1, #int 1 // #1
0105ac: 1214                                   |0010: const/4 v4, #int 1 // #1
0105ae: 4e04 0201                              |0011: aput-boolean v4, v2, v1
0105b2: 1a01 5500                              |0013: const-string v1, "ARTTEST" // string@0055
0105b6: 1a04 ce00                              |0015: const-string v4, "Do something on the synchronize block" // string@00ce
0105ba: 7120 0200 4100                         |0017: invoke-static {v1, v4}, Landroid/util/Log;.d:(Ljava/lang/String;Ljava/lang/String;)I // method@0002
0105c0: 1e03                                   |001a: monitor-exit v3
0105c2: 1231                                   |001b: const/4 v1, #int 3 // #3
0105c4: 4e05 0201                              |001c: aput-boolean v5, v2, v1
0105c8: 1251                                   |001e: const/4 v1, #int 5 // #5
0105ca: 4e05 0201                              |001f: aput-boolean v5, v2, v1
0105ce: 0e00                                   |0021: return-void
0105d0: 0d01                                   |0022: move-exception v1
0105d2: 1e03                                   |0023: monitor-exit v3
0105d4: 1223                                   |0024: const/4 v3, #int 2 // #2
0105d6: 1214                                   |0025: const/4 v4, #int 1 // #1
0105d8: 4e04 0203                              |0026: aput-boolean v4, v2, v3
0105dc: 2701                                   |0028: throw v1
0105de: 0d00                                   |0029: move-exception v0
0105e0: 1a01 5500                              |002a: const-string v1, "ARTTEST" // string@0055
0105e4: 1a03 5f00                              |002c: const-string v3, "An exception occurred" // string@005f
0105e8: 7130 0300 3100                         |002e: invoke-static {v1, v3, v0}, Landroid/util/Log;.e:(Ljava/lang/String;Ljava/lang/String;Ljava/lang/Throwable;)I // method@0003
0105ee: 1241                                   |0031: const/4 v1, #int 4 // #4
0105f0: 4e05 0201                              |0032: aput-boolean v5, v2, v1
0105f4: 28ea                                   |0034: goto 001e // -0016
      catches       : 4
        0x0005 - 0x0013
          Ljava/lang/Exception; -> 0x0029
        0x0013 - 0x001b
          <any> -> 0x0022
        0x0023 - 0x0024
          <any> -> 0x0022
        0x0026 - 0x0029
          Ljava/lang/Exception; -> 0x0029
      positions     :
        0x0005 line=19
        0x000c line=21
        0x0013 line=22
        0x001a line=23
        0x001b line=28
        0x001e line=29
        0x0022 line=23
        0x0029 line=25
        0x002a line=27
      locals        :
        0x001e - 0x0022 reg=0 e Ljava/lang/Exception;
        0x002a - 0x0035 reg=0 e Ljava/lang/Exception;
        0x0000 - 0x0035 reg=6 this Lfr/inra/arttest/MyClass;

It looks to me that the verifier is right, that catch block don't match up as expected with the instrumented bytecode.

From agampe:

This is my output from AOSP (note that the Fail code is about the same for lmp):

agampe@hh:/ssd/aosp-master2/art/tmp$ dex2oat --dex-file=app-debug.apk --dex-location=/system/framework/app-debug.apk --oat-file=app.oat --boot-image=/ssd/aosp-master2/art/tmp/dalvik-cache/boot.art --android-root=$ANDROID_HOST_OUT --runtime-arg -Xnorelocate --instruction-set=arm
dex2oat I 31774 31774 art/dex2oat/dex2oat.cc:1810] dex2oat --dex-file=app-debug.apk --dex-location=/system/framework/app-debug.apk --oat-file=app.oat --boot-image=/ssd/aosp-master2/art/tmp/dalvik-cache/boot.art --android-root=/ssd2/aosp-builds/hh/aosp-master2/host/linux-x86 --runtime-arg -Xnorelocate --instruction-set=arm
dex2oat W 31774 31806 art/runtime/verifier/register_line.cc:358] mismatched stack depths (depth=0, incoming depth=1)
dex2oat I 31774 31806 art/runtime/verifier/method_verifier.cc:297] Verification error in void fr.inra.arttest.MyClass.myOtherMethod()
dex2oat I 31774 31806 art/runtime/verifier/method_verifier.cc:297] void fr.inra.arttest.MyClass.myOtherMethod() failed to verify: void fr.inra.arttest.MyClass.myOtherMethod(): [0x11] expected to be within a catch-all for an instruction where a monitor is held
dex2oat I 31774 31806 art/runtime/verifier/method_verifier.cc:297]
dex2oat E 31774 31806 art/runtime/class_linker.cc:3661] Verification failed on class fr.inra.arttest.MyClass in /system/framework/app-debug.apk because: Verifier rejected class fr.inra.arttest.MyClass due to bad method void fr.inra.arttest.MyClass.myOtherMethod()
dex2oat I 31774 31774 art/dex2oat/dex2oat.cc:1619] dex2oat took 86.709ms (threads: 32) arena alloc=2MB java alloc=297KB native alloc=1558KB free=3MB

The aput-boolean at 0x11 can throw an NPE, and in that case the monitor is not correctly released.

It seems a lot like bdc is right in that your instrumentation is not updating exception tables correctly (note that the targets are correct, though, it's just the ranges that seem suspect).

jacocoInit makes me thinks this is a jacoco issue? is that something bundled with Android Studio?

Setting testCoverageEnabled to true does run the code through jacoco's instrumentation.

Raluca, can you take a look?

When I set try / catch inside synchronized block - application start working as usual.

So, the code is looking like this:

synchronized (this) {
   try {
      this.wait(testActionItem.getDelay());
   } catch (InterruptedException e) {
      /* Exception message can be captured here */
   }
}

Jacoco generates bad catch ranges, the first two exception ranges in comment #10 should be [0x0005,0x000f) and [0x000f,0x001b), i.e. 0x000f instead of 0x0013. The "const" instructions are irrelevant but the "0011 aput-boolean" is a throwing insn which belongs to the second catch.

ART is working as intended. See https://code.google.com/p/android/issues/detail?id=80823 , comments 5 and 6.

Also, we are working on fixing Jacoco. We don't want to have the same code work on the JVM in unit tests, but fail on ART for device tests.

I ran into the same issue.
I think this jacoco issue is related:
https://github.com/jacoco/jacoco/issues/265

Update: the patch has been merged to upstream Jacoco, we'll update the Gradle plugin as soon as the 0.7.3 release happens.

Meanwhile, you can use the latest snapshot build:

repositories {
  ...
  maven { url 'https://oss.sonatype.org/content/repositories/snapshots' }
}

android {
  ...
  jacoco {
      version '0.7.3-SNAPSHOT'
  }
}

I double-checked this works for the sample ArtTest.

0.7.3 is still not out. We'll update the default in 1.2 is possible.

Updated the Gradle plugin to use Jacoco version 0.7.4:
https://android-review.googlesource.com/#/c/138423/

Released in 1.3.0-beta3 or earlier.