Probe inserted at the beginning of a try-catch block should be included in the block.

[allenhair]

We insert a probe before a label if it is a successor and also a target. If the label is also used to define the start of an try-catch block, the inserted probe will not be included in the block.

This causes some issues when dealing with synchronized blocks. Normally, the compiler adds a catch-all entry to the exception table which covers the synchronized block in order to call monitorexit if any exceptions are thrown. If we need to insert a probe before the label which is used to define the start of the try-catch block, the catch-all entry will no longer cover all code between the monitorenter and monitorexit calls. While the probe is unlikely to cause an exception, this approach is not strictly correct.

We should probably split labels if they define a jump target and the start of a try-catch block. That way, the probe can be inserted after the start of the try-catch block, but before the jump target.

[marchof]

@allenhair Thanks for this insight! I'm always stunned when people dive into this level of detail in the JaCoCo core...

Just curious: How did you discover this? Did the potentially missed monitorexit calls cause any issues for your?

[marchof]

If we pull this change in we need to increment the exec file version number as this will change probe placement in a incompatible way.

[diggybub]

Just curious, is this issue linked to the following Android issue?

https://code.google.com/p/android/issues/detail?id=80961

I've run into similar problems using jacoco on a project using a device with the Android ART Runtime. I keep getting a java.lang.VerifyError exception on a class using try/catch blocks.

[allenhair]

@marchof I'm using JaCoCo on Android and ran into this issue when using the ART runtime. ART performs bytecode verification and enforces that monitorexit must be called from all code-paths after a monitorenter. Because the probe is not covered by the catch-all block, bytecode verification will fail.

@diggybub Yes, this change will fix that issue.

[diggybub]

Thanks @allenhair!

[marchof]

Added a reproducer to the validation test suite which shows the problem of unprotected instructions inserted by JaCoCo. 5f625c7

[marchof]

Fixed on master.