Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Probe inserted at the beginning of a try-catch block should be included in the block. #265
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.
referenced this issue
Dec 16, 2014
Just curious, is this issue linked to the following Android issue?
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.
@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.