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

Valery Silaev updated SANDBOX-318:
----------------------------------

    Description: 
AsmClassTransformer generates wrong bytecode for the method with 
Continuation.suspend code when there are constructor invocation instructions 
("new SomeClass()") exist in code.

The actual errors may be different, but all of them are VerifierErrors.
Here is an example java.lang.Runnable implementation that explains the problem:
//=========
package sampleFlow;

import java.util.Date;
import java.util.HashMap;
import java.util.Map;

import org.apache.commons.javaflow.Continuation;

public class Runner implements Runnable {
  final Object d = new Date();

  public void run() {
    // No problem for fields
    System.out.println(d);
                
    // No problem for primitives
    for (int i = 0; i < 3; i++)
      System.out.println(i);
                
    // No problem for "externalized" constructor call
    //final Map<String, String> map = newMap();
                
    // But direct constructor invocation always causes an error
    final Map<String, String> map = new HashMap<String, String>();

    map.put("A", "B");          
    System.out.println(map);
                
    Continuation.suspend();
    System.out.println("RESUMED, YES!");
  }

  protected Map<String, String> newMap() {
    return new HashMap<String, String>();
  }

}
//=========

Please see comments inside method run() -- when we have direct invocation "new 
HashMap<String, String>()" we got a verifier error:

org.objectweb.asm.tree.analysis.AnalyzerException: Error at instruction 30: 
Cannot pop operand off an empty stack.
        at org.objectweb.asm.tree.analysis.Analyzer.analyze(Unknown Source)
        at 
org.apache.commons.javaflow.bytecode.transformation.asm.ContinuationMethodAnalyzer$2.analyze(ContinuationMethodAnalyzer.java:124)
        at 
org.apache.commons.javaflow.bytecode.transformation.asm.ContinuationMethodAnalyzer.visitEnd(ContinuationMethodAnalyzer.java:135)
        at org.objectweb.asm.ClassReader.accept(Unknown Source)
        at org.objectweb.asm.ClassReader.accept(Unknown Source)

However, when we replace constructor call with miscellaneous method call, then 
error goes away.

Same error may be caused by implicit construction of StringBuilder like for 
expression "abc" + this.d (d is an instance field in example above)

The problem is not reproducible with BcelClassTransformer, but reproducible 
with all and every way continuable classes are instrumented (ant task, 
ContinuationClassLoader.forceLoadClass, ContinuationClassLoader.loadClass)


  was:
AsmClassTransformer generates wrong bytecode for the method with 
Continuation.suspend code when there are constructor invocation instructions 
("new SomeClass()") exist in code.

The actual errors may be different, but all of them are VerifierErrors.
Here is an example java.lang.Runnable implementation that explains the problem:
//=========
package sampleFlow;

import java.util.Date;
import java.util.HashMap;
import java.util.Map;

import org.apache.commons.javaflow.Continuation;

public class Runner implements Runnable { 

        final Object d = new Date();
        
        public void run() {
                // No problem for fields
                System.out.println(d);
                
                // No problem for primitives
                for (int i = 0; i < 3; i++)
                        System.out.println(i);
                
                // No problem for "externalized" constructor call
                //final Map<String, String> map = newMap();
                
                // But direct constructor invocation always causes an error
                final Map<String, String> map = new HashMap<String, String>();

                map.put("A", "B");              
                System.out.println(map);
                
                Continuation.suspend();
                System.out.println("RESUMED, YES!");
        }

        protected Map<String, String> newMap() {
                return new HashMap<String, String>();
        }
}
//=========

Please see comments inside method run() -- when we have direct invocation "new 
HashMap<String, String>()" we got a verifier error:

org.objectweb.asm.tree.analysis.AnalyzerException: Error at instruction 30: 
Cannot pop operand off an empty stack.
        at org.objectweb.asm.tree.analysis.Analyzer.analyze(Unknown Source)
        at 
org.apache.commons.javaflow.bytecode.transformation.asm.ContinuationMethodAnalyzer$2.analyze(ContinuationMethodAnalyzer.java:124)
        at 
org.apache.commons.javaflow.bytecode.transformation.asm.ContinuationMethodAnalyzer.visitEnd(ContinuationMethodAnalyzer.java:135)
        at org.objectweb.asm.ClassReader.accept(Unknown Source)
        at org.objectweb.asm.ClassReader.accept(Unknown Source)

However, when we replace constructor call with miscellaneous method call, then 
error goes away.

Same error may be caused by implicit construction of StringBuilder like for 
expression "abc" + this.d (d is an instance field in example above)

The problem is not reproducible with BcelClassTransformer, but reproducible 
with all and every way continuable classes are instrumented (ant task, 
ContinuationClassLoader.forceLoadClass, ContinuationClassLoader.loadClass)



> AsmClassTransformer generates wrong bytecode when constructor invocation exist
> ------------------------------------------------------------------------------
>
>                 Key: SANDBOX-318
>                 URL: https://issues.apache.org/jira/browse/SANDBOX-318
>             Project: Commons Sandbox
>          Issue Type: Bug
>          Components: Javaflow
>         Environment: Sun JDK 1.6.0_16, Windows XP SP3 32bit, ObjectWeb ASM 
> 3.1 and 3.2
>            Reporter: Valery Silaev
>            Priority: Critical
>
> AsmClassTransformer generates wrong bytecode for the method with 
> Continuation.suspend code when there are constructor invocation instructions 
> ("new SomeClass()") exist in code.
> The actual errors may be different, but all of them are VerifierErrors.
> Here is an example java.lang.Runnable implementation that explains the 
> problem:
> //=========
> package sampleFlow;
> import java.util.Date;
> import java.util.HashMap;
> import java.util.Map;
> import org.apache.commons.javaflow.Continuation;
> public class Runner implements Runnable {
>   final Object d = new Date();
>   public void run() {
>     // No problem for fields
>     System.out.println(d);
>               
>     // No problem for primitives
>     for (int i = 0; i < 3; i++)
>       System.out.println(i);
>               
>     // No problem for "externalized" constructor call
>     //final Map<String, String> map = newMap();
>               
>     // But direct constructor invocation always causes an error
>     final Map<String, String> map = new HashMap<String, String>();
>     map.put("A", "B");                
>     System.out.println(map);
>               
>     Continuation.suspend();
>     System.out.println("RESUMED, YES!");
>   }
>   protected Map<String, String> newMap() {
>     return new HashMap<String, String>();
>   }
> }
> //=========
> Please see comments inside method run() -- when we have direct invocation 
> "new HashMap<String, String>()" we got a verifier error:
> org.objectweb.asm.tree.analysis.AnalyzerException: Error at instruction 30: 
> Cannot pop operand off an empty stack.
>       at org.objectweb.asm.tree.analysis.Analyzer.analyze(Unknown Source)
>       at 
> org.apache.commons.javaflow.bytecode.transformation.asm.ContinuationMethodAnalyzer$2.analyze(ContinuationMethodAnalyzer.java:124)
>       at 
> org.apache.commons.javaflow.bytecode.transformation.asm.ContinuationMethodAnalyzer.visitEnd(ContinuationMethodAnalyzer.java:135)
>       at org.objectweb.asm.ClassReader.accept(Unknown Source)
>       at org.objectweb.asm.ClassReader.accept(Unknown Source)
> However, when we replace constructor call with miscellaneous method call, 
> then error goes away.
> Same error may be caused by implicit construction of StringBuilder like for 
> expression "abc" + this.d (d is an instance field in example above)
> The problem is not reproducible with BcelClassTransformer, but reproducible 
> with all and every way continuable classes are instrumented (ant task, 
> ContinuationClassLoader.forceLoadClass, ContinuationClassLoader.loadClass)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to