[
https://issues.apache.org/jira/browse/BCEL-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Bourg updated BCEL-144:
--------------------------------
Description:
When BCEL encounters a BranchInstruction offset that is >= 32767, it throws the
following exception:
{code}
com.sitraka.pas.sandbox.org.apache.bcel.generic.ClassGenException: Branch
target offset too large for short
at
com.sitraka.pas.sandbox.org.apache.bcel.generic.BranchInstruction.dump(BranchInstruction.java:99)
at
com.sitraka.pas.sandbox.org.apache.bcel.generic.InstructionList.getByteCode(InstructionList.java:993)
at
com.sitraka.pas.sandbox.org.apache.bcel.generic.MethodGen.getMethod(MethodGen.java:616)
{code}
BCEL-66 was previously filed about this exception and closed because the class
that was causing the error and the suggested solution were both violating the
rules of the language. My situation is a little different, so I am filing a new
bug.
I am inserting bytecodes into a method that is large, but within the limits
defined by the language. Due to the size of the method, a number of the branch
targets are large, but still small enough to fit in a short. After I insert
bytecodes, the method size is still smaller than the method size limit but the
large branch targets increase enough so that they no longer fit in a short and
the exception occurs.
I have solved the problem and am including a patch. My solution is to check the
InstructionList for any branch targets that are too large to fit in a short and
append a goto and a goto_w after every such instruction. I set the goto's
target to the instruction that followed the branch instruction before I did my
append so that the default behaviour is to maintain the original path of
execution and jump over the goto_w. I set the goto_w's target to the branch
instruction's target, then I set the branch instruction's target to the goto_w.
I am doing this only for IfInstructions because JSRs, GOTOs and Selects seem to
handle large branch targets in their implementations of updatePosition. This
works and is within the rules defined by the language as far as I can tell.
was:
When BCEL encounters a BranchInstruction offset that is >= 32767, it throws the
following exception:
com.sitraka.pas.sandbox.org.apache.bcel.generic.ClassGenException: Branch
target offset too large for short
at
com.sitraka.pas.sandbox.org.apache.bcel.generic.BranchInstruction.dump(BranchInstruction.java:99)
at
com.sitraka.pas.sandbox.org.apache.bcel.generic.InstructionList.getByteCode(InstructionList.java:993)
at
com.sitraka.pas.sandbox.org.apache.bcel.generic.MethodGen.getMethod(MethodGen.java:616)
..........
BCEL-66 was previously filed about this exception and closed because the class
that was causing the error and the suggested solution were both violating the
rules of the language. My situation is a little different, so I am filing a new
bug.
I am inserting bytecodes into a method that is large, but within the limits
defined by the language. Due to the size of the method, a number of the branch
targets are large, but still small enough to fit in a short. After I insert
bytecodes, the method size is still smaller than the method size limit but the
large branch targets increase enough so that they no longer fit in a short and
the exception occurs.
I have solved the problem and am including a patch. My solution is to check the
InstructionList for any branch targets that are too large to fit in a short and
append a goto and a goto_w after every such instruction. I set the goto's
target to the instruction that followed the branch instruction before I did my
append so that the default behaviour is to maintain the original path of
execution and jump over the goto_w. I set the goto_w's target to the branch
instruction's target, then I set the branch instruction's target to the goto_w.
I am doing this only for IfInstructions because JSRs, GOTOs and Selects seem to
handle large branch targets in their implementations of updatePosition. This
works and is within the rules defined by the language as far as I can tell.
Priority: Major
Environment: (was: Operating System: Windows XP
Platform: PC)
Affects Version/s: (was: unspecified)
Labels: PatchAvailable (was: )
Priority: (was: P2)
Severity: (was: normal)
> Branch target offset too large for short
> ----------------------------------------
>
> Key: BCEL-144
> URL: https://issues.apache.org/jira/browse/BCEL-144
> Project: Commons BCEL
> Issue Type: Bug
> Components: Main
> Reporter: cfeldmann
> Assignee: Apache Commons Developers
> Labels: PatchAvailable
> Attachments: large_branch_target_fix.patch
>
>
> When BCEL encounters a BranchInstruction offset that is >= 32767, it throws
> the following exception:
> {code}
> com.sitraka.pas.sandbox.org.apache.bcel.generic.ClassGenException: Branch
> target offset too large for short
> at
> com.sitraka.pas.sandbox.org.apache.bcel.generic.BranchInstruction.dump(BranchInstruction.java:99)
> at
> com.sitraka.pas.sandbox.org.apache.bcel.generic.InstructionList.getByteCode(InstructionList.java:993)
> at
> com.sitraka.pas.sandbox.org.apache.bcel.generic.MethodGen.getMethod(MethodGen.java:616)
> {code}
> BCEL-66 was previously filed about this exception and closed because the
> class that was causing the error and the suggested solution were both
> violating the rules of the language. My situation is a little different, so I
> am filing a new bug.
> I am inserting bytecodes into a method that is large, but within the limits
> defined by the language. Due to the size of the method, a number of the
> branch targets are large, but still small enough to fit in a short. After I
> insert bytecodes, the method size is still smaller than the method size limit
> but the large branch targets increase enough so that they no longer fit in a
> short and the exception occurs.
> I have solved the problem and am including a patch. My solution is to check
> the InstructionList for any branch targets that are too large to fit in a
> short and append a goto and a goto_w after every such instruction. I set the
> goto's target to the instruction that followed the branch instruction before
> I did my append so that the default behaviour is to maintain the original
> path of execution and jump over the goto_w. I set the goto_w's target to the
> branch instruction's target, then I set the branch instruction's target to
> the goto_w. I am doing this only for IfInstructions because JSRs, GOTOs and
> Selects seem to handle large branch targets in their implementations of
> updatePosition. This works and is within the rules defined by the language as
> far as I can tell.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
