commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Bourg (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (BCEL-172) Searching bug
Date Thu, 24 Apr 2014 14:13:16 GMT

     [ https://issues.apache.org/jira/browse/BCEL-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Emmanuel Bourg updated BCEL-172:
--------------------------------

    Description: 
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}

  was:
It turned out that finder.search methods generates incorrect output.
For example:
finder.search("invokespecial")
Will find not only some INVOKESPECIAL opcodes but will return InstructionHandle arrays in
form:
[   invokespecial,    nextOpCode]
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
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)
because of situation, that after return there is no more instruction(so InstructionHandler
too) to get. It occurs especially for deafult constructors as they bytecode is like:
invokespecial
return.

Error exists because of errorneus instruction(line 230 in InstructionFinder.java, method search()):
int lenExpr = (endExpr - startExpr) + 1;
There should be no "+1" part because:
int endExpr = matcher.end();
(which is one line above)
returns index AFTER match.
So bug generally(I didn't tested properly) could be repaired with replacing errorneus line
with:
int lenExpr = (endExpr - startExpr);



> 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
>
> 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)

Mime
View raw message