asm issueshttps://gitlab.ow2.org/asm/asm/-/issues2017-12-26T10:59:35Zhttps://gitlab.ow2.org/asm/asm/-/issues/308807AnalyzerException running CheckClassAdapter.verify() on java.lang.String2017-12-26T10:59:35ZteckAnalyzerException running CheckClassAdapter.verify() on java.lang.String```
Using the attached test program and ASM HEAD, I get this output:
Exception in thread "main" java.lang.AssertionError:
org.objectweb.asm.tree.analysis.AnalyzerException: Error at instruction 2:
Argument 2: expected Ljava/lang/CharSeq...```
Using the attached test program and ASM HEAD, I get this output:
Exception in thread "main" java.lang.AssertionError:
org.objectweb.asm.tree.analysis.AnalyzerException: Error at instruction 2:
Argument 2: expected Ljava/lang/CharSequence;, but found Ljava/lang/String;
at org.objectweb.asm.tree.analysis.Analyzer.analyze(Analyzer.java:289)
at org.objectweb.asm.util.CheckClassAdapter.verify(CheckClassAdapter.java:194)
at Test.main(Test.java:14)
Caused by: org.objectweb.asm.tree.analysis.AnalyzerException: Argument 2:
expected Ljava/lang/CharSequence;, but found Ljava/lang/String;
at
org.objectweb.asm.tree.analysis.BasicVerifier.naryOperation(BasicVerifier.java:401)
at org.objectweb.asm.tree.analysis.Frame.execute(Frame.java:567)
at org.objectweb.asm.tree.analysis.Analyzer.analyze(Analyzer.java:190)
... 2 more
matches(Ljava/lang/String;)Z
00000 String String : : ALOAD 1
00001 String String : String : ALOAD 0
00002 String String : String String : INVOKESTATIC
java/util/regex/Pattern.matches (Ljava/lang/String;Ljava/lang/CharSequence;)Z
00003 ? : IRETURN
Will also attach a patch in a few minutes
```https://gitlab.ow2.org/asm/asm/-/issues/308671visitMaxs fails in MethodWriter2017-12-26T11:00:14ZgodmarvisitMaxs fails in MethodWriter```
I think this happens for every class file. It may be a mistake in how I'm using it.
See attached test.
``````
I think this happens for every class file. It may be a mistake in how I'm using it.
See attached test.
```https://gitlab.ow2.org/asm/asm/-/issues/308425wrong label position , in Frame ( in StackMapTable) in stack/local for uninit...2017-12-26T11:00:35Zmarkovytchwrong label position , in Frame ( in StackMapTable) in stack/local for uninitialized types```
As it is said in MethodVisitor.visitFrame documentation :
" .......
local - .....Reference types are represented by String objects (representing
internal names), and uninitialized types by Label objects (this label
designates...```
As it is said in MethodVisitor.visitFrame documentation :
" .......
local - .....Reference types are represented by String objects (representing
internal names), and uninitialized types by Label objects (this label
designates the NEW instruction that created this uninitialized value)."
That means that such label object should ALWAYS be just before the appropriate
NEW instruction , this is not always true . Try the following :
run ASMLifier on the following method , taken from org/objectweb/asm/Type :
public static Type getObjectType(final String internalName) {
char[] buf = internalName.toCharArray();
return new Type(buf[0] == '[' ? ARRAY : OBJECT, buf, 0, buf.length);
}
the produced output is:
{
mv = cw.visitMethod(ACC_PUBLIC +
ACC_STATIC, "getObjectType", "(Ljava/lang/String;)
LJFBackComp/org/objectweb/asm/Type;", null, null);
mv.visitCode();
Label l0 = new Label();
mv.visitLabel(l0);
mv.visitLineNumber(217, l0);
mv.visitVarInsn(ALOAD, 0);
mv.visitMethodInsn(INVOKEVIRTUAL, "java/lang/String", "toCharArray", "()[C");
mv.visitVarInsn(ASTORE, 1);
Label l1 = new Label();
mv.visitLabel(l1); <-------------------------------------
mv.visitLineNumber(218, l1); <-------------------------------------
mv.visitTypeInsn(NEW, "JFBackComp/org/objectweb/asm/Type"); <------------
mv.visitInsn(DUP);
mv.visitVarInsn(ALOAD, 1);
mv.visitInsn(ICONST_0);
mv.visitInsn(CALOAD);
mv.visitIntInsn(BIPUSH, 91);
Label l2 = new Label();
mv.visitJumpInsn(IF_ICMPNE, l2);
mv.visitIntInsn(BIPUSH, 9);
Label l3 = new Label();
mv.visitJumpInsn(GOTO, l3);
mv.visitLabel(l2);
mv.visitFrame(Opcodes.F_FULL, 2, new Object[] {"java/lang/String", "[C"}, 2,
new Object[] {l1, l1});
mv.visitIntInsn(BIPUSH, 10);
mv.visitLabel(l3);
mv.visitFrame(Opcodes.F_FULL, 2, new Object[] {"java/lang/String", "[C"}, 3,
new Object[] {l1, l1, Opcodes.INTEGER});
mv.visitVarInsn(ALOAD, 1);
mv.visitInsn(ICONST_0);
mv.visitVarInsn(ALOAD, 1);
mv.visitInsn(ARRAYLENGTH);
mv.visitMethodInsn
(INVOKESPECIAL, "JFBackComp/org/objectweb/asm/Type", "<init>", "(I[CII)V");
mv.visitInsn(ARETURN);
Label l4 = new Label();
mv.visitLabel(l4);
mv.visitLocalVariable("internalName", "Ljava/lang/String;", null, l0, l4, 0);
mv.visitLocalVariable("buf", "[C", null, l1, l4, 1);
mv.visitMaxs(6, 2);
mv.visitEnd();
}
the expected order of arrowed instructions should be :
mv.visitLabel(l1);
mv.visitTypeInsn(NEW, "JFBackComp/org/objectweb/asm/Type");
mv.visitLineNumber(218, l1);
The problem is actually inside ClassReader , which does not takes that into
consideration . I can propose to move visitLineNumer invockation/s to the
end ,just where visitLocalVariable are .
```https://gitlab.ow2.org/asm/asm/-/issues/308365Explosive combination: MethodAdapter with COMPUTE_FRAMES2017-12-26T11:00:51ZmemeplexExplosive combination: MethodAdapter with COMPUTE_FRAMES```
I wrote a java transformer which is installed from a java agent premain. This
transformer just takes the input class bytecode and pass it through a
do-nothing class visitor which is implemented as follows:
class MyClassVisitor exten...```
I wrote a java transformer which is installed from a java agent premain. This
transformer just takes the input class bytecode and pass it through a
do-nothing class visitor which is implemented as follows:
class MyClassVisitor extends ClassAdapter {
public MyClassVisitor(ClassVisitor cv) {
super(cv);
}
@Override
public MethodVisitor visitMethod(int access, String name, String desc,
String signature, String[] exceptions) {
return new MethodAdapter(super.visitMethod(access, name, desc,
signature, exceptions));
}
}
The writer is created with COMPUTE_FRAMES flag. My application freezes during
startup. If I remove the COMPUTE_FRAMES flag, then everything goes fine. If I
remove the MethodAdapter from visitMethod, so that it's implemented as:
@Override
public MethodVisitor visitMethod(int access, String name, String desc,
String signature, String[] exceptions) {
return super.visitMethod(access, name, desc,
signature, exceptions);
}
everything goes fine too. This is strange, because the adapter is simply a
delegator. Here follows the complete transformer code, I don't know if you will
be able to reproduce the problem because it may depend on the specific classes
that are loaded during jvm bootup.
public class InstrumentationTransformer implements ClassFileTransformer {
public byte[] transform(ClassLoader loader, String className,
Class<?> classBeingRedefined, ProtectionDomain protectionDomain,
byte[] classfileBuffer) throws IllegalClassFormatException {
ClassReader reader = new ClassReader(classfileBuffer);
ClassWriter writer = new ClassWriter(reader,
ClassWriter.COMPUTE_FRAMES);
ClassVisitor visitor = new MyClassVisitor(writer);
reader.accept(visitor, 0);
return writer.toByteArray();
}
private static class MyClassVisitor extends ClassAdapter {
public MyClassVisitor(ClassVisitor cv) {
super(cv);
}
@Override
public MethodVisitor visitMethod(int access, String name, String desc,
String signature, String[] exceptions) {
return new MethodAdapter(super.visitMethod(access, name, desc,
signature, exceptions));
}
}
}
```https://gitlab.ow2.org/asm/asm/-/issues/309039Please do not "optimize" jars in default build2017-12-26T10:58:44ZshevekPlease do not "optimize" jars in default build```
Whatever the jar postprocessor in the default asm build is, it makes it almost
impossible to debug anything using the asm library. The cost of this
"optimizer" is considerable, and the benefit is marginal or nil. Please don't
do it. ...```
Whatever the jar postprocessor in the default asm build is, it makes it almost
impossible to debug anything using the asm library. The cost of this
"optimizer" is considerable, and the benefit is marginal or nil. Please don't
do it. It's fine as a test case, but inappropriate for the public release of
open source software. In order to use the asm library, I have to recompile it
myself without the optimizer, because the build system isn't exactly the
clearest ever.
Thanks.
S.
```https://gitlab.ow2.org/asm/asm/-/issues/310438missing ClassReader.accept(ClassVisitor,boolean) method breaks legacy code2017-12-26T10:57:18Zbradpeabodymissing ClassReader.accept(ClassVisitor,boolean) method breaks legacy code```
In trying to organize the .jar files in a recent project which involved
OpenEJB, I ran into some code which errors due to the fact that the
org.objectweb.asm.ClassReader.accept(ClassVisitor,boolean) method was removed
in a previous r...```
In trying to organize the .jar files in a recent project which involved
OpenEJB, I ran into some code which errors due to the fact that the
org.objectweb.asm.ClassReader.accept(ClassVisitor,boolean) method was removed
in a previous release and replaced with accept(ClassVisitor,int).
I was able to make everything work by just recompiling with this method added
in to org/objectweb/asm/ClassReader.java
/**
* Added this in for compatibility
* @param classVisitor
* @param skipDebug
* @deprecated
*/
public void accept(final ClassVisitor classVisitor, final boolean skipDebug)
{
accept(classVisitor, new Attribute[0], SKIP_DEBUG);
}
Can you add back in this method? It has no functional impact, is a very small
amount of mess, but would allow OpenEJB and possibly other projects which broke
between v2.x and 3.x to now work properly with the new code.
What do you think?
```https://gitlab.ow2.org/asm/asm/-/issues/310932ClassReader causes invalid length in LocalVariableTable2017-12-26T10:57:05ZllangleyClassReader causes invalid length in LocalVariableTable```
Hi,
The problem happens in ASM 3.1 and 3.0 (I worked with 3.1 sources).
After ASM works on it, the class cannot be loaded (see details later).
BCEL handles the class without a problem.
The code is the following:
cr = new ClassRea...```
Hi,
The problem happens in ASM 3.1 and 3.0 (I worked with 3.1 sources).
After ASM works on it, the class cannot be loaded (see details later).
BCEL handles the class without a problem.
The code is the following:
cr = new ClassReader(bytes);
ClassWriter cw = new ClassWriter(ClassWriter.COMPUTE_MAXS);
cr.accept(cw, 0);
return cw.toByteArray();
After this code works on the attached class, the class cannot be loaded with
the exception saying there is invalid length in LocalVariableTable in this
class.
The problematic method is newDataStoreId(javax.jdo.spi.PersistenceCapable,
kodo.meta.ClassMetaData);
Here is the information obtained using javap before and after the ASM
regarding this method:
Before:
LineNumberTable:
line 667: 95
line 668: 100
line 669: 107
LocalVariableTable:
Start Length Slot Name Signature
95 20 0 this Lkodo/jdbc/runtime/JDBCStoreManager;
95 20 1 pc Ljavax/jdo/spi/PersistenceCapable;
95 20 2 meta Lkodo/meta/ClassMetaData;
100 15 3 mapping Lkodo/jdbc/meta/ClassMapping;
107 8 4 id J
Code:
Stack=7, Locals=12, Args_size=3
After:
LineNumberTable:
line 667: 95
line 668: 100
line 669: 107
LocalVariableTable:
Start Length Slot Name Signature
95 -95 0 this Lkodo/jdbc/runtime/JDBCStoreManager;
95 -95 1 pc Ljavax/jdo/spi/PersistenceCapable;
95 -95 2 meta Lkodo/meta/ClassMetaData;
100 -100 3 mapping Lkodo/jdbc/meta/ClassMapping;
107 -107 4 id J
Code:
Stack=5, Locals=12, Args_size=3
The problem is that when the mv.visitLocalVariable(readUTF8(w + 4, c),
readUTF8(w + 6, c),
vsignature,
labels[start],
labels[start + length],
index);
is called from the ClassReader.accept(), the position of the labels
[start+lenght] is 0 in case of this particular method. Start is 95 , lenght is
20. The problematic labels[115] has position 0. Inside the
MethodWriter.visitLocalVariable the lenght is calculates as end.position -
start.position. Start's position is 95, end's position is 0, so the lenght is -
95.
It seems like the root cause is that the current code skips
MethodWriter.visitLabel() called from the line 1143 (in the beginning of the
while loop).
It skips label 115 because it points into the middle of the instruction:
114: astore 11
116: jsr 130
After label 114 is handled in the case ClassWriter.VAR_INSN (line 1340) for
the astore instruction, 2 is added to local var v that points into the byte[],
so next label that is handled is 116. 115 is skipped.
Hence the problem.
Also, I noticed that MaxStack is less then the original...
Thank you,
Lena.
```https://gitlab.ow2.org/asm/asm/-/issues/316482JarOptimizer removes directory entries in resulting jars2017-12-26T10:18:53ZkpiwkoJarOptimizer removes directory entries in resulting jars```
When:
Checking asm-4.0.jar content via any zip tool.
I expect:
org/
org/objectweb/
org/objectweb/asm/
org/objectweb/asm/AnnotationVisitor.class
...
I get:
org/objectweb/asm/AnnotationVisitor.class
...
e.g, all entries for directo...```
When:
Checking asm-4.0.jar content via any zip tool.
I expect:
org/
org/objectweb/
org/objectweb/asm/
org/objectweb/asm/AnnotationVisitor.class
...
I get:
org/objectweb/asm/AnnotationVisitor.class
...
e.g, all entries for directories are not packaged in the jar.
This causes a problem while trying to get asm resources from classpath:
http://bugs.sun.com/view_bug.do?bug_id=4761949
In particular, it breaks Spock integration with Arquillian:
https://issues.jboss.org/browse/ARQ-1429
I can provide a patch to JarOptimizer upon request.
```https://gitlab.ow2.org/asm/asm/-/issues/316479ASM5 5.0-alpha: Missing frame events2017-12-26T10:19:29ZmarchofASM5 5.0-alpha: Missing frame events```
I started some testing of our project with ASM 5.0-alpha and encountered an issue with frames.
EXPECTED BEHAVIOR
If you read a class file frames are always reported to the method MethodVisitor.visitFrame()
ACTUAL BEHAVIOR
The met...```
I started some testing of our project with ASM 5.0-alpha and encountered an issue with frames.
EXPECTED BEHAVIOR
If you read a class file frames are always reported to the method MethodVisitor.visitFrame()
ACTUAL BEHAVIOR
The method MethodVisitor.visitFrame() is only called if you specify ClassReader.EXPAND_FRAMES to
ClassReader.accept()
```https://gitlab.ow2.org/asm/asm/-/issues/307392MethodWriter generates invalid RuntimeInvisibleParameterAnnotations for enum ...2017-12-26T11:03:24ZyoleMethodWriter generates invalid RuntimeInvisibleParameterAnnotations for enum constructors```
If a parameter of an enum constructor is annotated and the constructor is
instrumented using ASM, the produced class file causes javac to crash. The
following stacktrace is produced:
java.lang.NullPointerException
at
com.sun.tools...```
If a parameter of an enum constructor is annotated and the constructor is
instrumented using ASM, the produced class file causes javac to crash. The
following stacktrace is produced:
java.lang.NullPointerException
at
com.sun.tools.javac.jvm.ClassReader.attachParameterAnnotations(ClassReader.java:898)
at com.sun.tools.javac.jvm.ClassReader.readMemberAttr(ClassReader.java:789)
at com.sun.tools.javac.jvm.ClassReader.readMemberAttrs(ClassReader.java:834)
at com.sun.tools.javac.jvm.ClassReader.readMethod(ClassReader.java:1235)
...
The reason for that is following: javac generates two hidden parameters passed
to the java.lang.Enum constructor, which should not be included in the
RuntimeInvisibleParameterAnnotations value. For example, if an enum constructor
has one actual parameter which is annotated, javac generates
RuntimeInvisibleParameterAnnotations with num_parameters=1, while ASM generates
the same attribute with num_parameters=3. The two hidden parameters should not
be taken into account when calculating the size of the panns/ipanns array in
MethodWriter.visitParameterAnnotation().
The problem was reproduced in ASM 2.1 but as far as I can see it's not fixed in
any later version.
See http://jetbrains.net/jira/browse/IDEADEV-19874 for the original bug report
which can be used to reproduce the problem.
```https://gitlab.ow2.org/asm/asm/-/issues/307600StackOverflowError in org.objectweb.asm.MethodWriter.findSubroutine()2018-01-20T11:28:52ZteckStackOverflowError in org.objectweb.asm.MethodWriter.findSubroutine()```
Running the attached program should give a stack overflow error.
If COMPUTE_MAXES is turned off in the ClassWriter, the issue does not happen.
I do not know which jsp compiler, nor java compiler produced the .class file.
``````
Running the attached program should give a stack overflow error.
If COMPUTE_MAXES is turned off in the ClassWriter, the issue does not happen.
I do not know which jsp compiler, nor java compiler produced the .class file.
```https://gitlab.ow2.org/asm/asm/-/issues/307684first line of &quot;finally&quot; block2017-12-26T11:01:38Zmindlessfirst line of "finally" block```
Hi-
Just wanted to cross reference this item:
http://sourceforge.net/tracker/index.php?func=detail&amp;aid=1362607&amp;group_id=130558&amp;atid=720015
I don't know if the problem is in ASM or in Cobertura's use of ASM, but thought
I...```
Hi-
Just wanted to cross reference this item:
http://sourceforge.net/tracker/index.php?func=detail&aid=1362607&group_id=130558&atid=720015
I don't know if the problem is in ASM or in Cobertura's use of ASM, but thought
I'd link this issue here just in case. Thanks for any input/analysis.
```https://gitlab.ow2.org/asm/asm/-/issues/307586Exception in ClassReader.readFrameType()2017-12-26T11:02:46ZyoleException in ClassReader.readFrameType()```
Got report about the following exception in ASM:
java.lang.ArrayIndexOutOfBoundsException: 1792
at org.objectweb.asm.ClassReader.readFrameType(ClassReader.java:1731)
at org.objectweb.asm.ClassReader.accept(ClassReader.java:1235...```
Got report about the following exception in ASM:
java.lang.ArrayIndexOutOfBoundsException: 1792
at org.objectweb.asm.ClassReader.readFrameType(ClassReader.java:1731)
at org.objectweb.asm.ClassReader.accept(ClassReader.java:1235)
at org.objectweb.asm.ClassReader.accept(ClassReader.java:394)
Unfortunately I don't have the class file on which that can be reproduced.
However, it would be very much desirable if ASM could handle even not quite
valid .class files without crashing.
```https://gitlab.ow2.org/asm/asm/-/issues/307530Reused LabelNodes in MethodNode2017-12-26T11:03:05Zdavid_schulerReused LabelNodes in MethodNode```
The getLabelNode(final Label l) method of class MethodNode reuses LabelNodes
of the given Label. This can lead to unexpected behaviour when the Labels carry
LabelNodes from another MethodNode.
See attached TestCase and proposed dif...```
The getLabelNode(final Label l) method of class MethodNode reuses LabelNodes
of the given Label. This can lead to unexpected behaviour when the Labels carry
LabelNodes from another MethodNode.
See attached TestCase and proposed diff.
diff -w -u -r1.29 MethodNode.java
--- MethodNode.java 17 Jun 2007 18:34:17 -0000 1.29
+++ MethodNode.java 7 Sep 2007 11:14:16 -0000
@@ -365,9 +365,7 @@
* @return the LabelNode corresponding to l.
*/
protected LabelNode getLabelNode(final Label l) {
- if (!(l.info instanceof LabelNode)) {
l.info = new LabelNode(l);
- }
return (LabelNode) l.info;
}
```https://gitlab.ow2.org/asm/asm/-/issues/306921SignatureReader does not handle inner class extends of other inner class2017-12-26T11:07:46ZquidryanSignatureReader does not handle inner class extends of other inner class```
I'm using the DependencyVisitor on java/util/AbstractList$ListItr. The
signature I'm getting is:
Ljava/util/AbstractList&lt;TE;&gt;.Itr;Ljava/util/ListIterator&lt;TE;&gt;;
That is from the declaration:
private class ListItr exten...```
I'm using the DependencyVisitor on java/util/AbstractList$ListItr. The
signature I'm getting is:
Ljava/util/AbstractList<TE;>.Itr;Ljava/util/ListIterator<TE;>;
That is from the declaration:
private class ListItr extends Itr implements ListIterator<E>
My problem is when SignatureReader.accept is called on that signature it passes
in "Itr" to visitInnerClassType. That is not the fully qualified name of Itr.
I would have expected java/util/ListIterator$Itr.
I've attached an example that grabs the signature and then tries to processes.
I'm not sure if the signature is wrong or the parsing of the signature is wrong.
```https://gitlab.ow2.org/asm/asm/-/issues/307242Patch to compile ASM 2.2.3 against Java 1.42017-12-26T11:04:26ZbspeakmonPatch to compile ASM 2.2.3 against Java 1.4```
SerialVersionUIDAdder throws an UnsupportedOperationException at line 434. It
passes the cause via a constructor, but that wasn't added until Java 1.5. It's
therefore breaking in my 1.4 build system.
I've attached a simple patch to ...```
SerialVersionUIDAdder throws an UnsupportedOperationException at line 434. It
passes the cause via a constructor, but that wasn't added until Java 1.5. It's
therefore breaking in my 1.4 build system.
I've attached a simple patch to pass the cause via a setter, which works in 1.4+.
```https://gitlab.ow2.org/asm/asm/-/issues/307012MethodWriter state inside Label is incorrectly reused on second tree traversal2017-12-26T11:04:52ZnbronsonMethodWriter state inside Label is incorrectly reused on second tree traversal```
MethodWriter stores state and forward reference information in the Label
object, which means that a given Label instance can only be used once to
generate code. tree.LabelNode, however, keeps a reference to the generated
Label, whic...```
MethodWriter stores state and forward reference information in the Label
object, which means that a given Label instance can only be used once to
generate code. tree.LabelNode, however, keeps a reference to the generated
Label, which means that if a tree is traversed twice to generate two copies of
a method the second traversal will incorrectly reuse the Label state from the
first code writing.
This manifests as either incorrectly generated code or an
ArrayIndexOutOfBoundsException from Label.resolve(). The javadoc for
Label.resolve() says that it will throw an IllegalArgumentException if it is
called from a MethodWriter other than the one that put() it, but that check is
not actually performed.
Attached is a class that we are using to work around the problem. It wraps a
MethodWriter, providing a one-to-one mapping between existing Label-s passed to
it and fresh Label-s passed to its wrapped mv.
Thank you - Nathan Bronson
```https://gitlab.ow2.org/asm/asm/-/issues/306349SerialVersionUIDAdder breaks compile if using JDK 1.42017-12-26T11:10:52ZfridrikSerialVersionUIDAdder breaks compile if using JDK 1.4```
When compiling with a JDK = 1.4 the following error occurs
compile-debug:
[mkdir] Created dir: /home/federico/Desktop/asm-2.2.3/output/build/tmp
[javac] Compiling 109 source files to
/home/federico/Desktop/asm-2.2.3/output/b...```
When compiling with a JDK = 1.4 the following error occurs
compile-debug:
[mkdir] Created dir: /home/federico/Desktop/asm-2.2.3/output/build/tmp
[javac] Compiling 109 source files to
/home/federico/Desktop/asm-2.2.3/output/build/tmp
[javac]
/home/federico/Desktop/asm-2.2.3/src/org/objectweb/asm/commons/SerialVersionUIDAdder.java:434:
cannot resolve symbol
[javac] symbol : constructor UnsupportedOperationException
(java.lang.Exception)
[javac] location: class java.lang.UnsupportedOperationException
[javac] throw new UnsupportedOperationException(e);
[javac] ^
[javac] 1 error
That is because the constructor UnsupportedOperationException(Throwable) was
introduced in java 1.5 and is not available on a jdk 1.4
As ant's javac task says source=1.3 target=1.2 I think that class should be patched
Attached you find the current patch used on the Gentoo GNU/Linux distro
Best regards
Federico Fissore
```https://gitlab.ow2.org/asm/asm/-/issues/304682asm 2.2.1 ifeq instruction read incorrectly2017-12-26T11:14:39ZAnonymousasm 2.2.1 ifeq instruction read incorrectly```
I am generating a class file with an ifeq instruction using ASM v.2.2.1. I
have verified the byte code using &quot;javap -verbose&quot; and if I use the
ASMifierClassVisitor it confirms that the byte code is correct. However, when...```
I am generating a class file with an ifeq instruction using ASM v.2.2.1. I
have verified the byte code using "javap -verbose" and if I use the
ASMifierClassVisitor it confirms that the byte code is correct. However, when
I use a subclass of method visitor instead of seeing an Opcodes.IFEQ
instruction visited I see the following instructions:
Opcodes.FLOAD
Opcodes.NOP
Opcodes.ICONST
The remaining instructions are correct. I believe that this is a bug, if not
please let me know what I am doing incorrectly. I'm not sure how to categorize
this issue so I'll leave that up to you.
Regards,
Bryan
```https://gitlab.ow2.org/asm/asm/-/issues/305715Bug in max stack computation with certain jsrs2017-12-26T11:13:39ZkbrBug in max stack computation with certain jsrs```
Certain jsr constructs break ASM's automatic maximum stack size
computation (passing the COMPUTE_MAXS flag to the ClassWriter). An
example of the style of bytecode causing the failure is as follows:
public static Method run:&quot;([...```
Certain jsr constructs break ASM's automatic maximum stack size
computation (passing the COMPUTE_MAXS flag to the ClassWriter). An
example of the style of bytecode causing the failure is as follows:
public static Method run:"([Ljava/lang/String;Ljava/io/PrintStream;)I"
stack 4 locals 4
{
iconst_0;
jsr L1;
L1: // returnAddress
astore 0;
ireturn;
}
If a class containing this method is read in and written out with
ASM's ClassReader and ClassWriter, the maximum stack size will
incorrectly be computed as 1 instead of 2. The reason is as follows.
The jsr instruction is visited during the writing process and an edge
with stack size two is correctly added between the first and second
basic block. The jsr instruction, not being an unconditional goto,
causes parsing to continue at the fall-through bytecode, which is a
Label corresponding to L1. visitLabel is then called and because
"compute == MAXS" is true the current block is terminated and an edge
drawn between the current block and the new block starting at L1. This
edge however uses the "current" stack size which does not correspond
to that containing the return address from the jsr (as it correctly
should not, if control were to actually fall through). This means that
there are two edges between the first and second basic block with
differing stack size. It happens that during class file reconstruction
the second of these is traversed and because this causes the PUSHED
flag to be set on the second basic block we never see the correct
stack size for the second basic block. This causes a VerifyError when
the reconstructed class is loaded.
Because of the "Gosling property" of Java bytecode it is not possible
to reach a given bytecode with more than one expression stack size.
Therefore if we already have a given Label as a successor of the
current basic block, that must be due to explicit control flow in this
basic block, and we should take that edge's stack size as the correct
stack size between the current block and the successor rather than
assuming that control falls through to the successor (which it might
not; in situations like jsr/ret we could only determine this by
tracing back to see which jsrs a given ret could possibly return to,
which is not currently done).
A patch for this bug is attached. The fix has been tested fairly well
and appears to address this problem without introducing any new ones.
```