JVMClassInfo$Initializer.setBootstrapMethod ArrayIndexOutOfBoundsException #53

gayanW · 2018-05-22T08:07:32Z

[junit] Picked up _JAVA_OPTIONS: -Xmx2048m -Xms512m
[junit] Running TypeNameTest
[junit]   running jpf with args:
[junit] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.701 sec
[junit] java.lang.ArrayIndexOutOfBoundsException: 1
[junit] 	at gov.nasa.jpf.jvm.JVMClassInfo$Initializer.setBootstrapMethod(JVMClassInfo.java:93)
[junit] 	at gov.nasa.jpf.jvm.ClassFile.setBootstrapMethod(ClassFile.java:659)
[junit] 	at gov.nasa.jpf.jvm.ClassFile.parseBootstrapMethodAttr(ClassFile.java:1422)
[junit] 	at gov.nasa.jpf.jvm.JVMClassInfo$Initializer.setClassAttribute(JVMClassInfo.java:80)
[junit] 	at gov.nasa.jpf.jvm.ClassFile.setClassAttribute(ClassFile.java:636)
[junit] 	at gov.nasa.jpf.jvm.ClassFile.parseClassAttributes(ClassFile.java:1306)
[junit] 	at gov.nasa.jpf.jvm.ClassFile.parse(ClassFile.java:875)
[junit] 	at gov.nasa.jpf.jvm.JVMClassInfo$Initializer.<init>(JVMClassInfo.java:48)
[junit] 	at gov.nasa.jpf.jvm.JVMClassInfo.<init>(JVMClassInfo.java:619)
[junit] 	at gov.nasa.jpf.jvm.JVMClassFileContainer$JVMClassFileMatch.createClassInfo(JVMClassFileContainer.java:58)
[junit] 	at gov.nasa.jpf.jvm.JVMClassFileContainer$JVMClassFileMatch.createClassInfo(JVMClassFileContainer.java:33)
[junit] 	at gov.nasa.jpf.vm.ClassLoaderInfo.getResolvedClassInfo(ClassLoaderInfo.java:353)
[junit] 	at gov.nasa.jpf.vm.SystemClassLoaderInfo.getResolvedClassInfo(SystemClassLoaderInfo.java:147)
[junit] 	at gov.nasa.jpf.vm.VM.getStartupSystemClassInfos(VM.java:445)
[junit] 	at gov.nasa.jpf.vm.VM.initializeMainThread(VM.java:564)
[junit] 	at gov.nasa.jpf.vm.SingleProcessVM.initialize(SingleProcessVM.java:130)
[junit] 	at gov.nasa.jpf.JPF.run(JPF.java:611)
[junit] 	at gov.nasa.jpf.util.test.TestJPF.createAndRunJPF(TestJPF.java:675)
[junit] 	at gov.nasa.jpf.util.test.TestJPF.noPropertyViolation(TestJPF.java:806)
[junit] 	at gov.nasa.jpf.util.test.TestJPF.verifyNoPropertyViolation(TestJPF.java:830)
[junit] 	at TypeNameTest.testArrayCloning(TypeNameTest.java:58)

The ClassFile parser seems to find just single bootstrap method argument, whereas in JVMClassInfo$Initializer.setBootstrapMethod it expects an element with index 1 in the bmArgs array.

jpf-core/src/main/gov/nasa/jpf/jvm/ClassFile.java

Lines 1386 to 1422 in 18a0c42

    
             /** 
        
              * BootstrapMethods_attribute { 
        
              *     u2 attribute_name_index; 
        
              *     u4 attribute_length; 
        
              *     u2 num_bootstrap_methods; 
        
              *     {   u2 bootstrap_method_ref; -> MethodHandle 
        
              *         u2 num_bootstrap_arguments; 
        
              *         u2 bootstrap_arguments[num_bootstrap_arguments]; 
        
              *     } bootstrap_methods[num_bootstrap_methods]; 
        
              * } 
        
              *  
        
              * pos is at num_bootstrap_methods 
        
             */ 
        
             public void parseBootstrapMethodAttr (ClassFileReader reader, Object tag){ 
        
               int nBootstrapMethods = readU2(); 
        
               setBootstrapMethodCount(reader, tag, nBootstrapMethods); 
        
               for (int i=0; i<nBootstrapMethods; i++){ 
        
                 int cpMhIdx = readU2(); 
        
                 int nArgs = readU2(); 
        
                 int[] bmArgs = new int[nArgs]; 
        
                 for (int j=0; j<nArgs; j++){ 
        
                   bmArgs[j] = readU2(); 
        
                 } 
        
                 // kind of this method handle 
        
                 int refKind = mhRefTypeAt(cpMhIdx); 
        
                 // CONSTANT_Methodref_info structure 
        
                 int mrefIdx = mhMethodRefIndexAt(cpMhIdx); 
        
                 String clsName = methodClassNameAt(mrefIdx); 
        
                 String mthName = methodNameAt(mrefIdx); 
        
                 String descriptor = methodDescriptorAt(mrefIdx); 
        
                 setBootstrapMethod(reader, tag, i, refKind, clsName, mthName, descriptor, bmArgs);

jpf-core/src/main/gov/nasa/jpf/jvm/JVMClassInfo.java

Lines 91 to 93 in 18a0c42

    
           public void setBootstrapMethod (ClassFile cf, Object tag, int idx, int refKind, String cls, String mth, String descriptor, int[] cpArgs) {     
        
             int lambdaRefKind = cf.mhRefTypeAt(cpArgs[1]);

This seems to happen when trying to create ClassInfo for startupSystemClasses. So for instance sysCl.getResolvedClassInfo("java.lang.Class") would throw java.lang.ArrayIndexOutOfBoundsException' exception.

sysCl.getResolvedClassInfo("java.lang.Object") however resolves fine.

References

Saved diff of Class.class for Java 8 and 10:
https://www.diffchecker.com/0A0yIEXK

Travis log:
https://travis-ci.org/javapathfinder/jpf-core/builds/381994510#L3057-L3083

The text was updated successfully, but these errors were encountered:

cyrille-artho · 2018-05-22T12:30:44Z

It seems that support for this attribute in jpf-core is specific to lambda expressions. The current code does not even check the number of arguments and whether a given bootstrap method is a lamba expression.
As a fix, please copy the entire array (which may be longer or shorter than two elements), and if you can find out how to check whether the bootstrap method is a lambda expression, check this in the method that returns element 1.
We don't need more accessor methods for the general case, as this functionality seems currently unused. Therefore, I'd like to focus on making this functionality safe and robust for the current special case.

cyrille-artho · 2018-05-23T14:39:39Z

This affects method public void setBootstrapMethod (ClassFile cf, Object tag, int idx, int refKind, String cls, String mth, String descriptor, int[] cpArgs) in JVMClassInfo.java.

cpArgs is bmArgs in ClassFile.java, which calls this function. The current code handles just a fixed number of arguments, and uses them in a specific way, to know how to use the lambda expression.

To make the code robust against crashes, the code should use the existing functionality if the length of cpArgs == 3, and otherwise just store that array but not evaluate it further.

cyrille-artho · 2018-06-13T13:31:10Z

It seems that to resolve this properly, we also need to look at ClassInfo.java:
Looking at this SO post again:

https://stackoverflow.com/questions/50831654/what-is-a-bootstrap-method-argument-java-bytecode/50836081#50836081

The first case is the one that's handled correctly by the current specific code in JPF:

#883 REF_invokeStatic java/lang/invoke/LambdaMetafactory.metafactory

This deals with lamdba expressions, which have a very specific structure. Perhaps arg 0 is always java/lang/Object, which is why it was ignored.

I suggest to check the u2 bootstrap_method_ref entry in the bytecode.

This is passed as "refKind" to setBootstrapMethod, and currently unchecked. If it matches the type above, we can execute the current code.

Otherwise, we should store the cpArgs information and NOT evaluate the specific arguments. We may still have to evaluate these arguments in a different way, e.g.:

#284 REF_invokeStatic java/lang/invoke/StringConcatFactory.makeConcatWithConstants:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/String;[Ljava/lang/Object;)Ljava/lang/invoke/CallSite;
Method arguments:
#285 \u0001\u0001

This creates a method that appends a particular string. If we do not cover this case (and only the lambda meta factory case), I hope we get rid of ArrayBounds problems, but we may get an incorrect output in some cases; we can fix this in a separate step.

cyrille-artho · 2018-06-13T14:44:45Z

I understand this better now: Lambda expressions get compiled into specific cases of bootstrap methods. Bootstrap methods are templates of methods, which are generated at run time, when the expression is encountered for the first time. The code in setLambdaDirectCallCode (JVMClassInfo) parses the necessary type descriptors and creates a new method that loads the arguments and calls the actual method that is referred to in the constant pool.

As I wrote in the new comment on the issue tracker, the first step would be to check whether we deal with the specific case that was (so far) the only case in Java 8. After that, we can try to generalize the code.

I hope we can see from the examples why arg0 was not used before, and how to update the code to find the right type descriptors for a different number of arguments.

cyrille-artho · 2018-06-13T15:50:57Z

It seems that input parameters start deliberately at 1; see the first loop (from 0) and the second one (from 1) in JVMClassInfo.setLambdaDirectCallCode:

    // expression and captured by the lexical scope. These variables  
    // are stored by the fields of the synthetic function object class
    int n = callerCi.getNumberOfInstanceFields();
    for(int i=0; i<n; i++) {
      cb.aload(0);
      FieldInfo fi = callerCi.getInstanceField(i);
      cb.getfield(fi.getName(), callerCi.getName(), Types.getTypeSignature(fi.getSignature(), false));
    }
    // adding bytecode instructions to load input parameters of the lambda expression
    n = miDirectCall.getArgumentsSize();
    for(int i=1; i<n; i++) {
      cb.aload(i);
    }```

gayanW · 2018-06-19T19:24:11Z

The value of the refKind parameter is always the same (6) for both working and failing scenarios.

As stated in below, BootstrapMethodInfo including setLambdaDirectCallCode, and setBootstrapMethod are written to handle only the special case where invokedynamic is used to compile lambda expressions.

jpf-core/src/main/gov/nasa/jpf/vm/BootstrapMethodInfo.java

Lines 23 to 28 in 18a0c42

    
            * For now, this is only used to capture boostrap methods for lambda expression, 
        
            * which link the method representing the lambda body to a single abstract method  
        
            * (SAM) declared in a functional interface. References to bootstrap methods are 
        
            * provided by the invokedynamic bytecode instruction.  
        
            */ 
        
           public class BootstrapMethodInfo {

As stated in the SO post

Bootstrap methods are used to resolve invokedynamic instruction.
invokedynamic is a general purpose mechanism, not only for lambdas

We'll also have different descriptors for the bootstrap methods LambdaMetafactory.metafactory and LambdaMetafactory.altMetafactory.

clsName = "java/lang/invoke/LambdaMetafactory"
mthName = "metafactory"
descriptor = "(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite;"

clsName = "java/lang/invoke/LambdaMetafactory"
mthName = "altMetafactory"
descriptor = "(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;[Ljava/lang/Object;)Ljava/lang/invoke/CallSite;"

So why not just check the value of clsName parameter, and only proceeds if it is equal to 'java/lang/invoke/LambdaMetafactory'? As it will make sure that only the bootstrap methods with lambda behavior is handled.

Working examples:

tag = {JVMClassInfo@1311} "ClassInfo[name=java.lang.CharSequence]"
nBootstrapMethods = 2

i = 0
cpMhIdx = 38
nArgs = 3
bmArgs = {int[3]@1312} 
refKind = 6
mrefIdx = 57
clsName = "java/lang/invoke/LambdaMetafactory"
mthName = "metafactory"
descriptor = "(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite;"

i = 1
cpMhIdx = 38
nArgs = 3
bmArgs = {int[3]@1321} 
refKind = 6
mrefIdx = 57
clsName = "java/lang/invoke/LambdaMetafactory"
mthName = "metafactory"
descriptor = "(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite;"

tag = {JVMClassInfo@1409} "ClassInfo[name=java.util.Map$Entry]"
nBootstrapMethods = 4

i = 0
cpMhIdx = 78
nArgs = 5
bmArgs = {int[5]@1410}
refKind = 6
mrefIdx = 119
clsName = "java/lang/invoke/LambdaMetafactory"
mthName = "altMetafactory"
descriptor = "(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;[Ljava/lang/Object;)Ljava/lang/invoke/CallSite;"

Failing cases:

tag = {JVMClassInfo@1714} "ClassInfo[name=java.lang.Class]"

idx = 0
refKind = 6
cls = "java/lang/invoke/StringConcatFactory"
mth = "makeConcatWithConstants"
descriptor = "(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/String;[Ljava/lang/Object;)Ljava/lang/invoke/CallSite;"

cyrille-artho · 2018-06-21T12:22:48Z

Let's try adding a check if "clsName" and see if this makes some of the tests pass. After that, let's look at the remaining cases.

Fix the (currently supported) behavior of Lambda expressions by adding an extra check.
(There should be at least one test failure less after this step; otherwise we need another test that shows a difference.)
Add the simple example (StringAppendTest) as a new test.
Please add this case first and try to ensure it fails. You may have to "print" statement to an assertion that compares the result against the expected value.
Try to generalize the code that generates bootstrap methods to handle such cases (maybe we can solve this by calling MethodHandle.invoke).

Documentation:

https://docs.oracle.com/javase/10/docs/api/java/lang/invoke/package-summary.html

https://docs.oracle.com/javase/10/docs/api/java/lang/invoke/MethodHandle.html#invokeWithArguments%28java.lang.Object...%29

cyrille-artho · 2018-06-21T12:33:02Z

public class StringAppendTest {
    public static void main(String[] args) {
	String str = new String("Hello, ");
	String out = str + "World!";
	assert(out.equals("Hello, World!"));
    }
}

gayanW · 2018-06-22T17:34:11Z

I added a clasName check in the setBootstrapMethod method like the following:

  if (!cls.equals("java/lang/invoke/LambdaMetafactory"))
     return;

After implementing the check, ArrayIndexOutOfBoundsException has disappeared . There's also a significant improvement in the test results:

Before:
Number of Tests Executed: 759
Number of Tests Failed: 564
Number of Test Errors: 1
Number of Tests Skipped: 0

After:
Number of Tests Executed: 760
Number of Tests Failed: 164
Number of Test Errors: 0
Number of Tests Skipped: 0

Before implementing clsName check:

[junit] Running gov.nasa.jpf.test.java.lang.StringTest
[junit] Tests run: 13, Failures: 13, Errors: 0, Skipped: 0, Time elapsed: 0.644 sec

After implementing clsName check:

[junit] Running gov.nasa.jpf.test.java.lang.StringTest
[junit] Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.566 sec

In the After case, I added the suggested StringAppendTest in to StringTest.java. Surprisingly that test also do pass. I'm currently not sure why.

I also test the same changes in the master branch with Java 8

Master branch with Java 8

In Java 8 all the test cases pass, which somewhat verifies that the existing functionalities are not affected by the extra clsName check.

Travis log: https://travis-ci.org/gayanW/jpf-core/builds/395538672

gayanW · 2018-06-23T03:46:51Z

It seems to me that verifyNoPropertyViolation() in the tests is what initiates JPF which cause methods to run through JPF. If not the tests are invoked directly.

Test 1

This test pass with no errors printed in the console.

@Test
public void testConcat() {
    String str = new String("Hello, ");
    String out = str + "World!";
    assert out.equals("Hello, World!");
}

Test 2

@Test
public void testConcat() {
    if (verifyNoPropertyViolation()) {
    String str = new String("Hello, ");
    String out = str + "World!";
        assert out.equals("Hello, World!");
    }
}

The test above also passes, but print out the following stacktrace.

[junit] Running gov.nasa.jpf.test.java.lang.StringTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.044 sec

[junit] Running gov.nasa.jpf.test.java.lang.StringTest
[junit]   running jpf with args:
[junit] gov.nasa.jpf.vm.ClassInfoException: class not found: java.io.Serializable
[junit]     at gov.nasa.jpf.vm.ClassLoaderInfo.getResolvedClassInfo(ClassLoaderInfo.java:363)
[junit]     at gov.nasa.jpf.vm.SystemClassLoaderInfo.getResolvedClassInfo(SystemClassLoaderInfo.java:147)
[junit]     at gov.nasa.jpf.vm.SystemClassLoaderInfo.loadClass(SystemClassLoaderInfo.java:182)
[junit]     at gov.nasa.jpf.vm.ClassInfo.resolveReferencedClass(ClassInfo.java:2414)
[junit]     at gov.nasa.jpf.vm.ClassInfo.loadInterfaces(ClassInfo.java:2366)
[junit]     at gov.nasa.jpf.vm.ClassInfo.resolveClass(ClassInfo.java:2383)
[junit]     at gov.nasa.jpf.vm.ClassInfo.resolveAndLink(ClassInfo.java:548)
[junit]     at gov.nasa.jpf.jvm.JVMClassInfo.<init>(JVMClassInfo.java:624)
[junit]     at gov.nasa.jpf.jvm.JVMClassFileContainer$JVMClassFileMatch.createClassInfo(JVMClassFileContainer.java:58)
[junit]     at gov.nasa.jpf.jvm.JVMClassFileContainer$JVMClassFileMatch.createClassInfo(JVMClassFileContainer.java:33)
[junit]     at gov.nasa.jpf.vm.ClassLoaderInfo.getResolvedClassInfo(ClassLoaderInfo.java:353)
[junit]     at gov.nasa.jpf.vm.SystemClassLoaderInfo.getResolvedClassInfo(SystemClassLoaderInfo.java:147)
[junit]     at gov.nasa.jpf.vm.VM.getStartupSystemClassInfos(VM.java:445)
[junit]     at gov.nasa.jpf.vm.VM.initializeMainThread(VM.java:564)
[junit]     at gov.nasa.jpf.vm.SingleProcessVM.initialize(SingleProcessVM.java:130)
[junit]     at gov.nasa.jpf.JPF.run(JPF.java:611)
[junit]     at gov.nasa.jpf.util.test.TestJPF.createAndRunJPF(TestJPF.java:675)
[junit]     at gov.nasa.jpf.util.test.TestJPF.noPropertyViolation(TestJPF.java:806)
[junit]     at gov.nasa.jpf.util.test.TestJPF.verifyNoPropertyViolation(TestJPF.java:830)
[junit]     at gov.nasa.jpf.test.java.lang.StringTest.testConcat(StringTest.java:307)

It looks like that the test is still executed.without resolving the ClassInfos for the model classes as it fails when trying to resolve the StartupSystemClassInfos.

May be we will not be able to assert:

Add the simple example (StringAppendTest) as a new test.
Please add this case first and try to ensure it fails. You may have to "print" statement to an assertion that compares the result against the expected value.

.. before we could fix the system class loading issue.

Let me know if you want me to proceed with just the step 1?

cyrille-artho · 2018-06-23T08:00:09Z

Good work on the initial fix, which solves a lot of problems. Test 1 executes on the host JVM; it therefore does not use JPF. It is therefore expected to pass. Test 2 actually uses JPF. It is good that it fails, because it is a very small test that makes it easier to debug what exactly needs to be supported. It would be great if we could support the remaining cases without having to implement a lot of diverse bootstrap methods by hand, with the generic method that I mentioned earlier. If this does not work, we'll have to implement the 10 or so cases that are currently part of the invoke package. Please continue to look into what exactly fails in test 2, and how it could be fixed. Gayan Weerakutti wrote:

…

It seems to me that verifyNoPropertyViolation() in the tests is what initiates JPF which run methods through JPF. Unless the tests are invoked directly. Test 1 This test pass with no errors printed in the console. ***@***.*** public void testConcat() { String str = new String("Hello, "); String out = str + "World!"; assert out.equals("Hello, World!"); } | Test 2 ***@***.*** public void testConcat() { if (verifyNoPropertyViolation()) { String str = new String("Hello, "); String out = str + "World!"; assert out.equals("Hello, World!"); } } | The test above also passes, but print out the following stacktrace. |[junit] Running gov.nasa.jpf.test.java.lang.StringTest [junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.044 sec [junit] Running gov.nasa.jpf.test.java.lang.StringTest [junit] running jpf with args: [junit] gov.nasa.jpf.vm.ClassInfoException: class not found: java.io.Serializable [junit] at gov.nasa.jpf.vm.ClassLoaderInfo.getResolvedClassInfo(ClassLoaderInfo.java:363) [junit] at gov.nasa.jpf.vm.SystemClassLoaderInfo.getResolvedClassInfo(SystemClassLoaderInfo.java:147) [junit] at gov.nasa.jpf.vm.SystemClassLoaderInfo.loadClass(SystemClassLoaderInfo.java:182) [junit] at gov.nasa.jpf.vm.ClassInfo.resolveReferencedClass(ClassInfo.java:2414) [junit] at gov.nasa.jpf.vm.ClassInfo.loadInterfaces(ClassInfo.java:2366) [junit] at gov.nasa.jpf.vm.ClassInfo.resolveClass(ClassInfo.java:2383) [junit] at gov.nasa.jpf.vm.ClassInfo.resolveAndLink(ClassInfo.java:548) [junit] at gov.nasa.jpf.jvm.JVMClassInfo.<init>(JVMClassInfo.java:624) [junit] at gov.nasa.jpf.jvm.JVMClassFileContainer$JVMClassFileMatch.createClassInfo(JVMClassFileContainer.java:58) [junit] at gov.nasa.jpf.jvm.JVMClassFileContainer$JVMClassFileMatch.createClassInfo(JVMClassFileContainer.java:33) [junit] at gov.nasa.jpf.vm.ClassLoaderInfo.getResolvedClassInfo(ClassLoaderInfo.java:353) [junit] at gov.nasa.jpf.vm.SystemClassLoaderInfo.getResolvedClassInfo(SystemClassLoaderInfo.java:147) [junit] at gov.nasa.jpf.vm.VM.getStartupSystemClassInfos(VM.java:445) [junit] at gov.nasa.jpf.vm.VM.initializeMainThread(VM.java:564) [junit] at gov.nasa.jpf.vm.SingleProcessVM.initialize(SingleProcessVM.java:130) [junit] at gov.nasa.jpf.JPF.run(JPF.java:611) [junit] at gov.nasa.jpf.util.test.TestJPF.createAndRunJPF(TestJPF.java:675) [junit] at gov.nasa.jpf.util.test.TestJPF.noPropertyViolation(TestJPF.java:806) [junit] at gov.nasa.jpf.util.test.TestJPF.verifyNoPropertyViolation(TestJPF.java:830) [junit] at gov.nasa.jpf.test.java.lang.StringTest.testConcat(StringTest.java:307) | It looks like that the test is still executed.without resolving the ClassInfos for the model classes as it fails when trying to resolve the StartupSystemClassInfos. May be we will not be able to assert: Add the simple example (StringAppendTest) as a new test. Please add this case first and try to ensure it fails. You may have to "print" statement to an assertion that compares the result against the expected value. .. before we could fix the system class loading issue. Let me know if you want me to proceed with just the step 1? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#53 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AG9eRzztEIBemqTtXTNjt1Gtnj6qm6l9ks5t_bougaJpZM4UIKYz>.

-- Regards, Cyrille Artho - http://artho.com/ We are all like soldiers, crouching behind the fortifications we have raised. -- Steven Erikson, "Midnight Tides"

gayanW · 2018-06-23T08:58:04Z

Test 2 actually uses JPF. It is good that it fails, because it is a very small test that makes it easier to debug what exactly needs to be supported.

Test 2 also passes. But with the above stacktrace. What I meant was that we won't be able to reproduce the case 2, without fixing the class loading issue first. As shown in the stacktrace, Test 2 fails to resolve any ClassInfos, yet it continues with the assertion assert out.equals("Hello, World!"), hence passing the test.

cyrille-artho · 2018-06-23T17:24:05Z

If the test fails with a stack trace from JPF itself, then the assertion is never executed. Hence there is no assertion failure; the execution stops before the assertion is reached. The challenge is now in finding where/when exactly JPF throws ClassInfoException (which class(es) are loaded, which class is being loaded) and trying to figure out how to fix this. Gayan Weerakutti wrote:

…

Test 2 actually uses JPF. It is good that it fails, because it is a very small test that makes it easier to debug what exactly needs to be supported. Test 2 also passes. But with the above stacktrace. What I meant was that we won't be able to reproduce the case 2, without fixing the class loading issue first. As shown in the stacktrace Test 2 fails to resolve any ClassInfos, yet it continues with the assertion |assert out.equals("Hello, World!")|, hence passing the test. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#53 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AG9eRzBnU3p35_WSx0JCO80wi80ug2btks5t_gMcgaJpZM4UIKYz>.

-- Regards, Cyrille Artho - http://artho.com/ We are all like soldiers, crouching behind the fortifications we have raised. -- Steven Erikson, "Midnight Tides"

gayanW · 2018-06-24T06:53:29Z

ClassInfoException is related to the sun.boot.class.path issue and is not directly related to this one. It will be good to create a new issue for it. Once that is being fixed, StringAppend test inhere should also fail.

I'll create a new issue for it with detailed information, so we could come up with a solution. I expects it have more implementation changes in addition to be able to just retrive the boot class path. (Like changes to generated class URIs)

cyrille-artho · 2018-06-25T08:04:05Z

Yes, please work on that and create a new issue. It's good to get an overview of all pending problems (at least as far as we can tell now) before we try to fix them one by one. Gayan Weerakutti wrote:

…

ClassInfoException is related to the sun.boot.class.path <https://stackoverflow.com/q/50451536/3647002> issue and is not directly related to this one. It will be good to create a new issue for it. Once that is being fixed, StringAppend test inhere should also fail. I'll create a new issue for it with detailed information, so we could come up with a solution. I expects it have more implementation changes in addition to be able to just retrive the boot class path. (Like changes to generated class URIs) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#53 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AG9eRy4C8H_SiYs6eW4ACIEbsH3_sl2Fks5t_zdqgaJpZM4UIKYz>.

-- Regards, Cyrille Artho - http://artho.com/ None are more hopelessly enslaved than those who falsely believe they are free. -- Goethe

gayanW · 2018-07-19T16:25:33Z

It is necessary to construct and handle BootstrapMethodInfo for the special case (StringConcatFactory#makeConcatWithConstants) for the tests with string concatenation to pass.

We can construct BootstrapMethodInfo using a constructor similar to BootstrapMethodInfo(JVMClassInfo.this, cpArgs) without evaluating the cpArgs further as discussed before, but it'll still fail in JVMClassInfo#setLambdaDirectCallCode as setLambdaDirectCallCode method expects a BootstrapMethodInfo with a lambdaBody and a samDescriptor.

[junit] java.lang.NullPointerException
[junit]     at gov.nasa.jpf.jvm.JVMClassInfo.setLambdaDirectCallCode(JVMClassInfo.java:839)
[junit]     at gov.nasa.jpf.jvm.JVMClassInfo.<init>(JVMClassInfo.java:669)
[junit]     at gov.nasa.jpf.jvm.JVMClassInfo.createFuncObjClassInfo(JVMClassInfo.java:650)
[junit]     at gov.nasa.jpf.vm.ClassLoaderInfo.getResolvedFuncObjType(ClassLoaderInfo.java:478)
[junit]     at gov.nasa.jpf.vm.FunctionObjectFactory.getFunctionObject(FunctionObjectFactory.java:30)
[junit]     at gov.nasa.jpf.jvm.bytecode.INVOKEDYNAMIC.execute(INVOKEDYNAMIC.java:121)
[junit]     at gov.nasa.jpf.vm.ThreadInfo.executeInstruction(ThreadInfo.java:1908)
[junit]     at gov.nasa.jpf.vm.ThreadInfo.executeTransition(ThreadInfo.java:1859)
[junit]     at gov.nasa.jpf.vm.SystemState.executeNextTransition(SystemState.java:765)
[junit]     at gov.nasa.jpf.vm.VM.forward(VM.java:1722)
[junit]     at gov.nasa.jpf.search.Search.forward(Search.java:579)
[junit]     at gov.nasa.jpf.search.DFSearch.search(DFSearch.java:79)
[junit]     at gov.nasa.jpf.JPF.run(JPF.java:614)
[junit]     at gov.nasa.jpf.util.test.TestJPF.createAndRunJPF(TestJPF.java:675)
[junit]     at gov.nasa.jpf.util.test.TestJPF.noPropertyViolation(TestJPF.java:806)
[junit]     at gov.nasa.jpf.util.test.TestMultiProcessJPF.mpVerifyNoPropertyViolation(TestMultiProcessJPF.java:72)
[junit]     at gov.nasa.jpf.vm.multiProcess.StringTest.testInterns(StringTest.java:36)

I'm still not sure how to evaluate the lambdaBody, and samDescriptor for the special case (with single bmArg).

Failing case

  1: #210 REF_invokeStatic java/lang/invoke/StringConcatFactory.makeConcatWithConstants:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/String;[Ljava/lang/Object;)Ljava/lang/invoke/CallSite;
    Method arguments:
      #211 some text here

Working case

  0: #83 REF_invokeStatic java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite;
    Method arguments:
      #84 (Ljava/lang/Object;)Ljava/lang/Object;
      #85 REF_invokeInterface java/lang/annotation/Annotation.annotationType:()Ljava/lang/Class;
      #86 (Ljava/lang/annotation/Annotation;)Ljava/lang/Class;

FYI: evaluated values for an instance of the working case:

i = 0   cpMhIdx: 83     nArgs 3 bmArgs = 84 85 86
refKind = 6             #6 = Methodref
clsName                 java/lang/invoke/LambdaMetafactory
mthName                 metafactory
descriptor              "(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite;"

lambdaRefKind           9
clsName                 java.lang.annotation.Annotation
eclosingLambdaCls       ClassInfo[name=java.lang.annotation.Annotation]
mthName                 annotationType
signature               ()Ljava/lang/Class;

*lambdaBody             MethodInfo[java.lang.annotation.Annotation.annotationType()Ljava/lang/Class;]

*samDescriptor          (Ljava/lang/annotation/Annotation;)Ljava/lang/Class;

* - used in gov.nasa.jpf.jvm.JVMClassInfo#setLambdaDirectCallCode

cyrille-artho · 2019-08-23T00:38:55Z

Resolved, at least for parsing the bytecode in several cases we tested, as part of PR#210.

gayanW mentioned this issue Jun 8, 2018

Refactor URLClassLoaderTest.testGetPackage to testGetDefinedPackage #80

Merged

gayanW mentioned this issue Jul 19, 2018

Add a new constructor BootstrapMethodInfo(enclosingClass, cpArgs) #101

Merged

cyrille-artho closed this as completed Aug 23, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

JVMClassInfo$Initializer.setBootstrapMethod ArrayIndexOutOfBoundsException #53

JVMClassInfo$Initializer.setBootstrapMethod ArrayIndexOutOfBoundsException #53

gayanW commented May 22, 2018

cyrille-artho commented May 22, 2018

cyrille-artho commented May 23, 2018

cyrille-artho commented Jun 13, 2018

cyrille-artho commented Jun 13, 2018

cyrille-artho commented Jun 13, 2018 •

edited

Loading

gayanW commented Jun 19, 2018 •

edited

Loading

cyrille-artho commented Jun 21, 2018 •

edited

Loading

cyrille-artho commented Jun 21, 2018

gayanW commented Jun 22, 2018 •

edited

Loading

gayanW commented Jun 23, 2018 •

edited

Loading

cyrille-artho commented Jun 23, 2018 via email

gayanW commented Jun 23, 2018 •

edited

Loading

cyrille-artho commented Jun 23, 2018 via email

gayanW commented Jun 24, 2018

cyrille-artho commented Jun 25, 2018 via email

gayanW commented Jul 19, 2018

cyrille-artho commented Aug 23, 2019

JVMClassInfo$Initializer.setBootstrapMethod ArrayIndexOutOfBoundsException #53

JVMClassInfo$Initializer.setBootstrapMethod ArrayIndexOutOfBoundsException #53

Comments

gayanW commented May 22, 2018

cyrille-artho commented May 22, 2018

cyrille-artho commented May 23, 2018

cyrille-artho commented Jun 13, 2018

cyrille-artho commented Jun 13, 2018

cyrille-artho commented Jun 13, 2018 • edited Loading

gayanW commented Jun 19, 2018 • edited Loading

Working examples:

Failing cases:

cyrille-artho commented Jun 21, 2018 • edited Loading

cyrille-artho commented Jun 21, 2018

gayanW commented Jun 22, 2018 • edited Loading

Master branch with Java 8

gayanW commented Jun 23, 2018 • edited Loading

Test 1

Test 2

cyrille-artho commented Jun 23, 2018 via email

gayanW commented Jun 23, 2018 • edited Loading

cyrille-artho commented Jun 23, 2018 via email

gayanW commented Jun 24, 2018

cyrille-artho commented Jun 25, 2018 via email

gayanW commented Jul 19, 2018

cyrille-artho commented Aug 23, 2019

cyrille-artho commented Jun 13, 2018 •

edited

Loading

gayanW commented Jun 19, 2018 •

edited

Loading

cyrille-artho commented Jun 21, 2018 •

edited

Loading

gayanW commented Jun 22, 2018 •

edited

Loading

gayanW commented Jun 23, 2018 •

edited

Loading

gayanW commented Jun 23, 2018 •

edited

Loading