• Type: Bug
• Component: core-libs
• Sub-Component: java.lang.invoke
• Affected Version: 7u91,8u33,8u51,8u60,9

• Priority: P3
• Status: Closed
• Resolution: Duplicate
• OS: generic
• CPU: generic

• Submitted: 2010-10-07
• Updated: 2024-04-12
• Resolved: 2017-02-23

Other
tbdResolved

JDK-8081512 is backported; patches have been applied to SQE testbases for 7u and 8u to use Unsafe.dAC instead of sun.invoke.anon functionality. Assigning to SQE for evaluation. 25-04-2016 This bug can be closed as soon as JDK-8081512 is fixed and backported; the problematic AnonymousClassLoader won't be part of the code base any more then. 08-12-2015 SQE OK to defer the fix from CPU15_04. It's not a security vulnerability. It should be fixed in PSU or jdk9, but CPU. 27-07-2015 This bug was filed in 2010. It recently showed up on the PSU matrixes due to added affectsVersions, but it was previously targeted to JDK 9. Suggest we add the defer-approved label to this and add 8-wnf. Since the bug is 5 years old it doesn't seem critical to fix in older releases. 22-06-2015 [~skovalev], why do you think that assert in VMAnonymousClasses is related to this bug (which is about hang up)? 11-11-2014 1. AnonymousClassLoader is not a public API and can be deprecated or removed. At this point it is just a front-end for Unsafe.defineAnonymousClass. 2. Tests which feed bad data to AnonymousClassLoader and/or Unsafe.defineAnonymousClass are somewhat useful, if they find bugs in the class file parser. 3. It is true that only trusted code will invoke Unsafe.defineAnonymousClass, so bad-data tests are of use only to the extent that they simulate unexpected but good inputs from trusted sources. Recommendations: A. Deprecate and/or remove AnonymousClassLoader. B. Adapt unit tests of AnonymousClassLoader to Unsafe.defineAnonymousClass, if they have a reasonable chance of exercising correct but rare paths in the class file parser. C. Fix known bugs in the class file parser, including this one. 27-05-2014 It was mentioned in this discussion thread that there may be external users of sun.invoke.anon.AnonymousClassLoader: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-April/006678.html QUOTE Rémi Forax: This feature is used not only by me but by other dynamic language runtime implementers, I think that at least General Electrics Magik use it too because it allows to spit bytecodes very fast at runtime (I don't know why Nashorn doesn't use it BTW). ENDQUOTE 27-05-2014 I haven't touched AnonymousClassLoader as well, but I got an impression that it duplicates Unsafe.defineAnonymousClass(). My guess is it was written as a stop-the-gap solution during JSR292 implementation until VM support is there. I'm in favor of deprecation and complete removal of this functionality. I checked and there are no usages of AnonymousClassLoader across JDK. 27-05-2014 As part of the compiler team I don't feel responsible for that part of the code. Since the library team is taking over JSR 292 I move it into the right component. 07-05-2014 Assigning this to hotspot compiler group because the bug is in jdk/src/share/classes/sun/invoke/anon/ConstantPoolParser.java (part of JSR 292?) 01-05-2014 The hangs are caused by an infinite loop in method resolveConstantPool() in jdk/src/share/classes/sun/invoke/anon/ConstantPoolParser.java. The infinite loop can be seen in the following (abbreviated) code excerpt from resolveConstantPool(). If 'beg' equals 'end' at the start of statement 'if (beg2 > i) beg2 = i;', then it will loop infinitely. Assume, for example, 'beg' and 'end' both equal 6 at that point. Then 'i' and 'beg2' will have the value 6, and 'end2' will be 5. Next, 'end2' will get set to 6 because 'end2 < i', then the continue statement will get executed. 'i' will get incremented to 7 and the inner loop will get exited. The outer loop will then set 'beg' to 6, 'end' to 6, and 'end2' to 5. Then the inner loop will be entered, and 'i' will once again have the value 6, starting the whole loop all over again with the same values. private void resolveConstantPool(Object[] values, ConstantPoolVisitor visitor) { for (int beg = 1, end = values.length-1, beg2, end2; beg <= end; beg = beg2, end = end2) { beg2 = end; end2 = beg-1; for (int i = beg; i <= end; i++) { ... byte tag = tags[i]; switch (tag) { ... case CONSTANT_Fieldref: // fall through: case CONSTANT_Methodref: // fall through: case CONSTANT_InterfaceMethodref: { Object className = values[array[0]]; Object nameAndType = values[array[1]]; if (!(className instanceof String) || !(nameAndType instanceof String[])) { // one more pass is needed if (beg2 > i) beg2 = i; if (end2 < i) end2 = i; continue; } ... } } } } } 01-05-2014 When run locally, the test is failing with: # ERROR: Test caught an exception: # ERROR: java.lang.NoSuchMethodError: sun.invoke.anon.AnonymousClassLoader: method <init>()V not found # ERROR: at vm.mlvm.anonloader.share.StressClassLoadingTest.run(StressClassLoadingTest.java:18) # ERROR: at vm.mlvm.share.MlvmTest.runMlvmTest(MlvmTest.java:225) # ERROR: at vm.mlvm.share.MlvmTest.launch(MlvmTest.java:141) # ERROR: at vm.mlvm.share.MlvmTest.launch(MlvmTest.java:111) # ERROR: at vm.mlvm.anonloader.stress.byteMutation.Test.main(Test.java:22) 25-04-2014 Classes loaded with the anonymous class loader are not verified because they inherit from a trusted class loader that isn't verified. The VM is correct to assume that these are well formed classes and does not need to verifiy them. 25-06-2013 Since this is really a class loading problem I'm moving it to runtime. 08-05-2013 The README of the test states: DESCRIPTION The test does the following in a cycle: 1. Take bytes from a valid class file 2. Set 1 to 5 bytes in random positions to random values 3. Try to load such class using AnonymousClassLoader In most cases the resulting class file is invalid and rejected by verifier. But this test is looking for pathological cases when the verifier or the AnonymousClassLoader code ends up in an infinite loop or when VM crashes. First, right now anonymous classes are not verified. Turning on verification at least does not crash the VM: cthaling@macbook:~$ java -Xverify:all -cp $VM8TESTBASE vm.mlvm.anonloader.stress.byteMutation.Test -stressIterationsFactor 100000 ### TRACE 1: RNG seed = 6944159277692808984 (0x605e9c12429cef18) # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: There were 28 hangups during parsing. The class files, which produced hangup were saved as hangXXX.class in the test directory. You may want to analyse them. Failing this test because of hangups. ### TRACE 1: TEST FAILED #> #> SUMMARY: Following errors occured #> during test execution: #> # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: Killing parser thread # ERROR: There were 28 hangups during parsing. The class files, which produced hangup were saved as hangXXX.class in the test directory. You may want to analyse them. Failing this test because of hangups. I don't know yet what to think of the test errors. 08-05-2013 Running with a debug VM shows: cthaling@macbook:~/ws/hotspot/make$ java -cp $VM8TESTBASE vm.mlvm.anonloader.stress.byteMutation.Test -stressIterationsFactor 100000 ### TRACE 1: RNG seed = -136260719375316415 (0xfe1be79900cb8a41) # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/classFileParser.hpp:318 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/Users/cthaling/ws/hotspot/src/share/vm/classfile/classFileParser.hpp:318), pid=31475, tid=26119 # fatal error: Invalid superclass index 96 in class file vm/mlvm/anonloader/share/AnonkTestee01 # # JRE version: Java(TM) SE Runtime Environment (8.0-b88) (build 1.8.0-ea-b88) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b32-internal-debug mixed mode bsd-amd64 compressed oops) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /Users/cthaling/ws/hotspot/make/hs_err_pid31475.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # Current thread is 26119 Dumping core ... Abort trap: 6 08-05-2013