You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Emmanuel Bourg (JIRA)" <ji...@apache.org> on 2014/04/24 16:19:19 UTC
[jira] [Reopened] (BCEL-172) Searching bug
[ https://issues.apache.org/jira/browse/BCEL-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Bourg reopened BCEL-172:
---------------------------------
> Searching bug
> -------------
>
> Key: BCEL-172
> URL: https://issues.apache.org/jira/browse/BCEL-172
> Project: Commons BCEL
> Issue Type: Bug
> Components: Main
> Affects Versions: 5.2
> Reporter: AK
> Fix For: 6.0
>
>
> It turned out that finder.search methods generates incorrect output.
> For example:
> {code}
> finder.search("invokespecial")
> {code}
> Will find not only some INVOKESPECIAL opcodes but will return InstructionHandle arrays in form:
> {code}
> [ invokespecial, nextOpCode]
> {code}
> So instead of returning x matching opcode(s) it returns x+1 matching opcodes in one IntructionHandle array. This generates problem when invoking {{finder.search("invokespecial return")}} which will throw
> {code}
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException
> at java.lang.System.arraycopy(Native Method)
> at org.apache.bcel.util.InstructionFinder.getMatch(InstructionFinder.java:171)
> at org.apache.bcel.util.InstructionFinder.search(InstructionFinder.java:231)
> at org.apache.bcel.util.InstructionFinder.search(InstructionFinder.java:250)
> at Transform.transformMethod(Transform.java:66)
> at Transform.main(Transform.java:25)
> {code}
> because of situation, that after return there is no more instruction (so InstructionHandler too) to get. It occurs especially for default constructors as they bytecode is like:
> {code}
> invokespecial
> return.
> {code}
> Error exists because of erroneous instruction(line 230 in InstructionFinder.java, method {{search()}}):
> {code}
> int lenExpr = (endExpr - startExpr) + 1;
> {code}
> There should be no "+1" part because:
> {code}
> int endExpr = matcher.end();
> {code}
> (which is one line above)
> returns index AFTER match.
> So bug generally (I didn't tested properly) could be repaired with replacing erroneous line with:
> {code}
> int lenExpr = (endExpr - startExpr);
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)