[JBoss JIRA] (JASSIST-158) Method calls with a parameter of long[] or double[] are compiled to incorrect bytecode resulting in errors such as java.lang.VerifyError: ... Inconsistent args_size for opc_invokeinterface
11:13 a.m.
Jens Deppe created JASSIST-158:
----------------------------------
Summary: Method calls with a parameter of long[] or double[] are compiled to
incorrect bytecode resulting in errors such as java.lang.VerifyError: ... Inconsistent
args_size for opc_invokeinterface
Key: JASSIST-158
URL: https://issues.jboss.org/browse/JASSIST-158
Project: Javassist
Issue Type: Bug
Reporter: Jens Deppe
Assignee: Shigeru Chiba
I believe this patch fixes the problem:
Method calls with a parameter of long[] or double[] are compiled to incorrect bytecode.
For example, the following piece of code...
long[] aLongArray;
PdxWriter writer;
...
writer.writeLongArray("aLongArray", aLongArray);
Produces code similar to this:
13: aload_1
14: ldc #32; //String aLongArray
16: aload_0
17: getfield #35; //Field aLongArray:[J
20: invokeinterface #39, 4; //InterfaceMethod
com/gemstone/gemfire/pdx/PdxWriter.writeLongArray:(Ljava/lang/String;[J)Lcom/gemstone/gemfire/pdx/PdxWriter;
25: pop
Following the code, it looks like getfield calculates an incorrect stackdepth when applied
to a long[] or double[], resulting in an incorrect number of args applied to
invokeinterface.
The following patch seems to fix things.
Index: src/main/javassist/compiler/MemberCodeGen.java
===================================================================
--- src/main/javassist/compiler/MemberCodeGen.java (revision 624)
+++ src/main/javassist/compiler/MemberCodeGen.java (working copy)
@@ -957,7 +957,7 @@
else
className = null;
- boolean is2byte = (c == 'J' || c == 'D');
+ boolean is2byte = ((c == 'J' || c == 'D') && dim == 0);
return is2byte;
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:13 a.m.
[
https://issues.jboss.org/browse/JASSIST-158?page=com.atlassian.jira.plugi...
]
Jens Deppe updated JASSIST-158:
-------------------------------
Affects Version/s: 3.16.1-GA
Method calls with a parameter of long[] or double[] are compiled to
incorrect bytecode resulting in errors such as java.lang.VerifyError: ... Inconsistent
args_size for opc_invokeinterface
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JASSIST-158
URL: https://issues.jboss.org/browse/JASSIST-158
Project: Javassist
Issue Type: Bug
Affects Versions: 3.16.1-GA
Reporter: Jens Deppe
Assignee: Shigeru Chiba
I believe this patch fixes the problem:
Method calls with a parameter of long[] or double[] are compiled to incorrect bytecode.
For example, the following piece of code...
long[] aLongArray;
PdxWriter writer;
...
writer.writeLongArray("aLongArray", aLongArray);
Produces code similar to this:
13: aload_1
14: ldc #32; //String aLongArray
16: aload_0
17: getfield #35; //Field aLongArray:[J
20: invokeinterface #39, 4; //InterfaceMethod
com/gemstone/gemfire/pdx/PdxWriter.writeLongArray:(Ljava/lang/String;[J)Lcom/gemstone/gemfire/pdx/PdxWriter;
25: pop
Following the code, it looks like getfield calculates an incorrect stackdepth when
applied to a long[] or double[], resulting in an incorrect number of args applied to
invokeinterface.
The following patch seems to fix things.
Index: src/main/javassist/compiler/MemberCodeGen.java
===================================================================
--- src/main/javassist/compiler/MemberCodeGen.java (revision 624)
+++ src/main/javassist/compiler/MemberCodeGen.java (working copy)
@@ -957,7 +957,7 @@
else
className = null;
- boolean is2byte = (c == 'J' || c == 'D');
+ boolean is2byte = ((c == 'J' || c == 'D') && dim == 0);
return is2byte;
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:15 a.m.
[
https://issues.jboss.org/browse/JASSIST-158?page=com.atlassian.jira.plugi...
]
Jens Deppe updated JASSIST-158:
-------------------------------
Description:
I believe this patch fixes the problem:
Method calls with a parameter of long[] or double[] are compiled to incorrect bytecode.
For example, the following piece of code...
{code}
long[] aLongArray;
PdxWriter writer;
...
writer.writeLongArray("aLongArray", aLongArray);
{code}
Produces code similar to this:
{code}
13: aload_1
14: ldc #32; //String aLongArray
16: aload_0
17: getfield #35; //Field aLongArray:[J
20: invokeinterface #39, 4; //InterfaceMethod
com/gemstone/gemfire/pdx/PdxWriter.writeLongArray:(Ljava/lang/String;[J)Lcom/gemstone/gemfire/pdx/PdxWriter;
25: pop
{code}
Following the code, it looks like getfield calculates an incorrect stackdepth when applied
to a long[] or double[], resulting in an incorrect number of args applied to
invokeinterface.
The following patch seems to fix things.
{code}
Index: src/main/javassist/compiler/MemberCodeGen.java
===================================================================
--- src/main/javassist/compiler/MemberCodeGen.java (revision 624)
+++ src/main/javassist/compiler/MemberCodeGen.java (working copy)
@@ -957,7 +957,7 @@
else
className = null;
- boolean is2byte = (c == 'J' || c == 'D');
+ boolean is2byte = ((c == 'J' || c == 'D') && dim == 0);
return is2byte;
}
{code}
was:
I believe this patch fixes the problem:
Method calls with a parameter of long[] or double[] are compiled to incorrect bytecode.
For example, the following piece of code...
long[] aLongArray;
PdxWriter writer;
...
writer.writeLongArray("aLongArray", aLongArray);
Produces code similar to this:
13: aload_1
14: ldc #32; //String aLongArray
16: aload_0
17: getfield #35; //Field aLongArray:[J
20: invokeinterface #39, 4; //InterfaceMethod
com/gemstone/gemfire/pdx/PdxWriter.writeLongArray:(Ljava/lang/String;[J)Lcom/gemstone/gemfire/pdx/PdxWriter;
25: pop
Following the code, it looks like getfield calculates an incorrect stackdepth when applied
to a long[] or double[], resulting in an incorrect number of args applied to
invokeinterface.
The following patch seems to fix things.
Index: src/main/javassist/compiler/MemberCodeGen.java
===================================================================
--- src/main/javassist/compiler/MemberCodeGen.java (revision 624)
+++ src/main/javassist/compiler/MemberCodeGen.java (working copy)
@@ -957,7 +957,7 @@
else
className = null;
- boolean is2byte = (c == 'J' || c == 'D');
+ boolean is2byte = ((c == 'J' || c == 'D') && dim == 0);
return is2byte;
}
Method calls with a parameter of long[] or double[] are compiled to
incorrect bytecode resulting in errors such as java.lang.VerifyError: ... Inconsistent
args_size for opc_invokeinterface
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JASSIST-158
URL: https://issues.jboss.org/browse/JASSIST-158
Project: Javassist
Issue Type: Bug
Affects Versions: 3.16.1-GA
Reporter: Jens Deppe
Assignee: Shigeru Chiba
I believe this patch fixes the problem:
Method calls with a parameter of long[] or double[] are compiled to incorrect bytecode.
For example, the following piece of code...
{code}
long[] aLongArray;
PdxWriter writer;
...
writer.writeLongArray("aLongArray", aLongArray);
{code}
Produces code similar to this:
{code}
13: aload_1
14: ldc #32; //String aLongArray
16: aload_0
17: getfield #35; //Field aLongArray:[J
20: invokeinterface #39, 4; //InterfaceMethod
com/gemstone/gemfire/pdx/PdxWriter.writeLongArray:(Ljava/lang/String;[J)Lcom/gemstone/gemfire/pdx/PdxWriter;
25: pop
{code}
Following the code, it looks like getfield calculates an incorrect stackdepth when
applied to a long[] or double[], resulting in an incorrect number of args applied to
invokeinterface.
The following patch seems to fix things.
{code}
Index: src/main/javassist/compiler/MemberCodeGen.java
===================================================================
--- src/main/javassist/compiler/MemberCodeGen.java (revision 624)
+++ src/main/javassist/compiler/MemberCodeGen.java (working copy)
@@ -957,7 +957,7 @@
else
className = null;
- boolean is2byte = (c == 'J' || c == 'D');
+ boolean is2byte = ((c == 'J' || c == 'D') && dim == 0);
return is2byte;
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5257
days inactive
5257
days old
2 comments
1 participants
participants (1)
-
Jens Deppe (JIRA)