RFR(S) 8020675: Trying to print to a pdf file with PDFill PDF&Image Writer 10.0 Build 4

Calvin Cheung calvin.cheung at oracle.com
Wed Aug 21 13:21:05 PDT 2013 

I was thinking about updating the bug synopsis.
How about the following?
invalid jar file in the bootclasspath can lead to jvm fatal error

Calvin

On 8/21/2013 12:29 PM, Yumin Qi wrote:
> Not a review, only a suggestion, the bug description should be 
> modified. Confused.
>
> Yumin
>
> On 8/21/2013 11:49 AM, Calvin Cheung wrote:
>> Can someone review this?
>>
>> Latest version:
>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>
>> Previous version without using TRAPS:
>> http://cr.openjdk.java.net/~ccheung/8020675/webrev.00/
>>
>> thanks,
>> Calvin
>>
>> On 8/12/2013 11:19 PM, Calvin Cheung wrote:
>>> Hi David,
>>>
>>> I cloned the hotspot repo corresponding to 7u25 b15 and debugged a 
>>> bit more and found that the error was thrown at a very early stage 
>>> within the init_globals() called from create_vm(). Below is the call 
>>> stack:
>>>      jvm.dll!ClassLoader::create_class_path_entry(char * path, stat 
>>> st, ClassPathEntry * * new_entry, bool lazy)  Line 508 C++
>>>      jvm.dll!LazyClassPathEntry::resolve_entry()  Line 303 + 0x24 
>>> bytes    C++
>>>      jvm.dll!LazyClassPathEntry::open_stream(const char * name) Line 
>>> 322 + 0x8 bytes C++
>>>      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
>>> __the_thread__)  Line 898 + 0x17 bytes    C++
>>>      jvm.dll!SystemDictionary::load_instance_class(Symbol * 
>>> class_name, Handle class_loader, Thread * __the_thread__) Line 1362 
>>> + 0x14 bytes    C++
>>> jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * 
>>> name, Handle class_loader, Handle protection_domain, Thread * 
>>> __the_thread__)  Line 758 + 0x18 bytes    C++
>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>> Handle class_loader, Handle protection_domain, Thread * 
>>> __the_thread__)  Line 206 + 0x15 bytes    C++
>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>> Thread * __the_thread__)  Line 211 + 0x23 bytes C++
>>> jvm.dll!SystemDictionary::initialize_wk_klass(SystemDictionary::WKID 
>>> id, int init_opt, Thread * __the_thread__)  Line 1935 + 0xd bytes    
>>> C++
>>> jvm.dll!SystemDictionary::initialize_wk_klasses_until(SystemDictionary::WKID 
>>> limit_id, SystemDictionary::WKID & start_id, Thread * 
>>> __the_thread__)  Line 1949 + 0x11 bytes    C++
>>> jvm.dll!SystemDictionary::initialize_preloaded_classes(Thread * 
>>> __the_thread__)  Line 2011 + 0xf bytes    C++
>>>      jvm.dll!SystemDictionary::initialize(Thread * __the_thread__)  
>>> Line 1904 + 0x9 bytes    C++
>>>      jvm.dll!Universe::genesis(Thread * __the_thread__)  Line 353 + 
>>> 0x9 bytes    C++
>>>      jvm.dll!universe2_init()  Line 1009 + 0x9 bytes    C++
>>> >   jvm.dll!init_globals()  Line 114    C++
>>>      jvm.dll!Threads::create_vm(JavaVMInitArgs * args, bool * 
>>> canTryAgain)  Line 3220 + 0x5 bytes    C++
>>>      jvm.dll!JNI_CreateJavaVM(JavaVM_ * * vm, void * * penv, void * 
>>> args)  Line 5133 + 0xd bytes    C++
>>>      java.exe!011013bd()
>>>      [Frames below may be incorrect and/or missing, no symbols 
>>> loaded for java.exe]
>>>      java.exe!01101e2f()
>>>      java.exe!0110c807()
>>>      java.exe!0110a5a1()
>>>      java.exe!0110c845()
>>>      java.exe!0110a62b()
>>>      kernel32.dll!767633aa()
>>>      ntdll.dll!77739ef2()
>>>      ntdll.dll!77739ec5()
>>>
>>> The error was thrown in the method below:
>>> bool Exceptions::special_exception(Thread* thread, const char* file, 
>>> int line, Symbol* h_name, const char* message) {
>>>   // bootstrapping check
>>>   if (!Universe::is_fully_initialized()) {
>>>     if (h_name == NULL) {
>>>       // atleast an informative message.
>>>       vm_exit_during_initialization("Exception", message);
>>>     } else {
>>>       vm_exit_during_initialization(h_name, message);               
>>> <=====here
>>>     }
>>>     ShouldNotReachHere();
>>>   }
>>> }
>>>
>>> Note that it happened in the early stage during create_vm(), so the 
>>> (!Universe::is_fully_initialized()) was true.
>>>
>>> The class it was trying to load was sun/misc/AtomicLongCSImpl which 
>>> I couldn't find in 7u25.
>>> It was going through all the jar files in the bootclasspath and 
>>> finally got to the foo.jar which has 0-byte and got "error in 
>>> opening jar file" and then THROW_MSG().
>>> So I think it's just a coincident in 7u25 where the correct error 
>>> was thrown.
>>>
>>> In hs25, it didn't try to load the sun/misc/AtomicLongCSImpl class 
>>> and thus it didn't hit the "error in opening jar file" (for the 
>>> foo.jar) early until it passed the point when the vm is considered 
>>> "initialized" - is_init_completed() is true. So when THROW_MSG() was 
>>> called when it tried to load the class specified by the test case 
>>> ("xxx"), it triggered the fatal error in ~ExceptionMark(). Call 
>>> stack up to the THROWN_MSG() as follows:
>>>      jvm.dll!ClassLoader::create_class_path_entry(char * path, stat 
>>> st, ClassPathEntry * * new_entry, bool lazy)  Line 508 C++
>>>      jvm.dll!LazyClassPathEntry::resolve_entry()  Line 303 + 0x24 
>>> bytes    C++
>>> >    jvm.dll!LazyClassPathEntry::open_stream(const char * name)  
>>> Line 322 + 0x8 bytes    C++
>>>      jvm.dll!ClassLoader::load_classfile(Symbol * h_name, Thread * 
>>> __the_thread__)  Line 900 + 0x17 bytes C++
>>>      jvm.dll!SystemDictionary::load_instance_class(Symbol * 
>>> class_name, Handle class_loader, Thread * __the_thread__) Line 1301 
>>> + 0x14 bytes    C++
>>> jvm.dll!SystemDictionary::resolve_instance_class_or_null(Symbol * 
>>> name, Handle class_loader, Handle protection_domain, Thread * 
>>> __the_thread__)  Line 779 + 0x18 bytes    C++
>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>> Handle class_loader, Handle protection_domain, Thread * 
>>> __the_thread__)  Line 232 + 0x15 bytes    C++
>>>      jvm.dll!SystemDictionary::resolve_or_null(Symbol * class_name, 
>>> Thread * __the_thread__)  Line 237 + 0x23 bytes C++
>>>      jvm.dll!JVM_FindClassFromBootLoader(JNIEnv_ * env, const char * 
>>> name)  Line 773 + 0x12 bytes    C++
>>>      java.dll!69461e8c()
>>>      [Frames below may be incorrect and/or missing, no symbols 
>>> loaded for java.dll]
>>>      jvm.dll!GrowableArray<Metadata *>::append(Metadata * const & 
>>> elem)  Line 207    C++
>>>      jvm.dll!os::write_memory_serialize_page(JavaThread * thread) 
>>> Line 375 + 0x11 bytes    C++
>>>      jvm.dll!InterfaceSupport::serialize_memory(JavaThread * 
>>> thread)  Line 40 + 0x9 bytes    C++
>>>
>>> I'll try using TRAPS all the way through the call chain probably 
>>> starting from ClassLoader::load_classfile().
>>>
>>> thanks,
>>> Calvin
>>>
>>> On 8/11/2013 10:40 PM, David Holmes wrote:
>>>> Hi Calvin,
>>>>
>>>> I don't think this works. As I said previously the expectations of 
>>>> this code with regard to Java exceptions seems to be that it 
>>>> doesn't expect them at all. If you are using TRAPS etc then it 
>>>> should be used all the way through the call chain. What we have now 
>>>> is this call sequence:
>>>>
>>>> void ClassLoader::initialize() {
>>>>   assert(_package_hash_table == NULL, "should have been initialized 
>>>> by now.");
>>>>   EXCEPTION_MARK;
>>>>   ...
>>>>   setup_bootstrap_search_path();
>>>>     -> update_class_path_entry_list(path, false);
>>>>       ->  create_class_path_entry((char *)path, st, &new_entry, 
>>>> LazyBootClassLoader, CHECK);
>>>>
>>>> So if we return after the call to create_class_path_entry with an 
>>>> exception pending we will crash when we hit the EXCEPTION_MARK.
>>>>
>>>> It may be that the EXCEPTION_MARK needs replacing with an explicit 
>>>> exception check and a vm_exit_during_initialization, if this 
>>>> exception can readily occur at runtime. But further analysis of all 
>>>> this code needs to be undertaken.
>>>>
>>>> David
>>>> -----
>>>>
>>>> On 10/08/2013 8:11 AM, Calvin Cheung wrote:
>>>>> I've updated the webrev with 2 changes:
>>>>> 1) added the TRAPS as the last parameter to the
>>>>> create_class_path_entry() method;
>>>>> 2) added a jtreg test case.
>>>>>
>>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/
>>>>>
>>>>> Please take a look again.
>>>>>
>>>>> One more response in-lined below...
>>>>>
>>>>> On 8/8/2013 4:11 PM, Ioi Lam wrote:
>>>>>> |I found one version of JDK7 that does not crash:||
>>>>>> ||
>>>>>> sc11136754 ~$
>>>>>> /net/jre.us.oracle.com/p/v31/jdk/7/all/b24/binaries/linux-amd64/bin/java 
>>>>>>
>>>>>> -showversion -cp . -Xbootclasspath/a:foo.jar test2
>>>>>> Error occurred during initialization of VM
>>>>>> java/lang/ClassNotFoundException: error in opening JAR file foo.jar
>>>>>> |
>>>>>
>>>>> |I noticed that it started breaking in 7u40 b01; it was still working
>>>>> with 7u25.
>>>>> It may have something to do with when the set_init_completed() is 
>>>>> called:
>>>>> ExceptionMark::~ExceptionMark() {
>>>>>    if (_thread->has_pending_exception()) {
>>>>>      Handle exception(_thread, _thread->pending_exception());
>>>>>      _thread->clear_pending_exception(); // Needed to avoid infinite
>>>>> recursion
>>>>>      if (is_init_completed()) {
>>>>>        exception->print();
>>>>>        fatal("ExceptionMark destructor expects no pending 
>>>>> exceptions");
>>>>>      } else {
>>>>>        vm_exit_during_initialization(exception);
>>>>>      }
>>>>>    }
>>>>> }
>>>>>
>>>>> Before 7u40, I think the code path got to the "else" branch of
>>>>> ~ExceptionMark() and we just printed an error and exit.
>>>>>
>>>>> set_init_completed() is only called from Threads::create_vm() and 
>>>>> that
>>>>> method didn't change much between 7u25 and 7u40 except for some NMT
>>>>> initialization - MemTracker::bootstrap_single_thread(),
>>>>> MemTracker::start(), etc. But I thought NMT isn't enabled by default?
>>>>>
>>>>> Debugging with hs25, the set_init_completed() always happened before
>>>>> create_class_path_entry() and both calls were done within the same
>>>>> thread - "vm startup".
>>>>>
>>>>> thanks,
>>>>> Calvin
>>>>>
>>>>>
>>>>> |
>>>>>> |||
>>>>>> ||
>>>>>> ||- Ioi
>>>>>> |
>>>>>> On 08/08/2013 02:26 PM, Ioi Lam wrote:
>>>>>>> |I found an official version that's closest to the Redhat version
>>>>>>> (OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode). It still
>>>>>>> crashes.||
>>>>>>> ||
>>>>>>> ||sc11136754 ~$
>>>>>>> /java/re/jdk/6_25/latest/binaries/linux-amd64/bin/java -showversion
>>>>>>> -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>> ||java version "1.6.0_25"||
>>>>>>> ||Java(TM) SE Runtime Environment (build 1.6.0_25-b06)||
>>>>>>> ||Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode)||
>>>>>>> ||
>>>>>>> ||java.lang.ClassNotFoundException ||
>>>>>>> || - klass: 'java/lang/ClassNotFoundException'||
>>>>>>> ||#||
>>>>>>> ||# A fatal error has been detected by the Java Runtime 
>>>>>>> Environment:||
>>>>>>> ||#||
>>>>>>> ||#  Internal Error (exceptions.cpp:397), pid=29955,
>>>>>>> tid=140608485558016||
>>>>>>> ||#  fatal error: ExceptionMark destructor expects no pending
>>>>>>> exceptions||
>>>>>>> ||#||
>>>>>>> ||# JRE version: 6.0_25-b06||
>>>>>>> ||# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.0-b11 mixed mode
>>>>>>> linux-amd64 compressed oops)||
>>>>>>> ||# An error report file with more information is saved as:||
>>>>>>> ||# /home/iklam/hs_err_pid29955.log||
>>>>>>> ||#||
>>>>>>> ||# If you would like to submit a bug report, please visit:||
>>>>>>> ||# http://java.sun.com/webapps/bugreport/crash.jsp||
>>>>>>> ||#||
>>>>>>> ||Aborted (core dumped)||
>>>>>>> |
>>>>>>> - Ioi
>>>>>>>
>>>>>>> On 08/08/2013 02:18 PM, David Holmes wrote:
>>>>>>>> On 9/08/2013 4:52 AM, Ioi Lam wrote:
>>>>>>>>> |Hmmm, I used JDK6 from OEL 6.0 (derived from RedHat), which
>>>>>>>>> apparently
>>>>>>>>> works differently
>>>>>>>>> (better?) than the official JDK6 build. Maybe Redhat fixed 
>>>>>>>>> this in
>>>>>>>>> their
>>>>>>>>> own repo??||
>>>>>>>>
>>>>>>>> Their hotspot version is much later - hs20 vs hs17
>>>>>>>>
>>>>>>>> David
>>>>>>>> -----
>>>>>>>>
>>>>>>>>> ||
>>>>>>>>> |
>>>>>>>>> |==OEL6================================================
>>>>>>>>> ||
>>>>>>>>> ||sc11136754 ~$ uname -a||
>>>>>>>>> ||Linux sc11136754 2.6.39-100.5.1.el6uek.x86_64 #1 SMP Tue Mar 6
>>>>>>>>> 20:26:00 EST 2012 x86_64 x86_64 x86_64 GNU/Linux||
>>>>>>>>> ||sc11136754 ~$ type java||
>>>>>>>>> ||java is hashed (/usr/bin/java)||
>>>>>>>>> ||sc11136754 ~$ java -version||
>>>>>>>>> ||java version "1.6.0_22"||
>>>>>>>>> ||OpenJDK Runtime Environment (IcedTea6 1.10.4)
>>>>>>>>> (rhel-1.41.1.10.4.el6-x86_64)||
>>>>>>>>> ||OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)||
>>>>>>>>> ||sc11136754 ~$ java -showversion -cp . -Xbootclasspath/a:foo.jar
>>>>>>>>> test2||
>>>>>>>>> ||Error occurred during initialization of VM||
>>>>>>>>> ||java/lang/ClassNotFoundException: error in opening JAR file
>>>>>>>>> foo.jar||
>>>>>>>>> ||
>>>>>>>>> ==OFFICIAL============================================
>>>>>>>>> ||
>>>>>>>>> sc11136754 ~$ 
>>>>>>>>> /java/re/jdk/6_22/latest/binaries/linux-amd64/bin/java
>>>>>>>>> -showversion -cp . -Xbootclasspath/a:foo.jar test2
>>>>>>>>> java version "1.6.0_22"
>>>>>>>>> Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
>>>>>>>>>
>>>>>>>>> #
>>>>>>>>> # A fatal error has been detected by the Java Runtime 
>>>>>>>>> Environment:
>>>>>>>>> #
>>>>>>>>> #  Internal Error (exceptions.cpp:367), pid=25167, 
>>>>>>>>> tid=140510319580928
>>>>>>>>> #  Error: ExceptionMark destructor expects no pending exceptions
>>>>>>>>> #
>>>>>>>>> # JRE version: 6.0_22-b04
>>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (17.1-b03 mixed mode
>>>>>>>>> linux-amd64 )
>>>>>>>>> # An error report file with more information is saved as:
>>>>>>>>> # /home/iklam/hs_err_pid25167.log
>>>>>>>>> #
>>>>>>>>> # If you would like to submit a bug report, please visit:
>>>>>>>>> # http://java.sun.com/webapps/bugreport/crash.jsp
>>>>>>>>> #
>>>>>>>>> |
>>>>>>>>> |======================================================
>>>>>>>>> ||
>>>>>>>>> ||- Ioi|
>>>>>>>>>
>>>>>>>>> On 08/08/2013 11:08 AM, Calvin Cheung wrote:
>>>>>>>>>> Hi Ioi, David,
>>>>>>>>>>
>>>>>>>>>> On 8/7/2013 7:15 PM, Ioi Lam wrote:
>>>>>>>>>>> |JDK6 seems to handle this better. I have written a simple
>>>>>>>>>>> stand-alone test case that doesn't require truncating JAR 
>>>>>>>>>>> files in
>>>>>>>>>>> the JDK:||
>>>>>>>>>>> ||
>>>>>>>>>>> ||=========================||
>>>>>>>>>>> ||/*||
>>>>>>>>>>> ||javac test2.java||
>>>>>>>>>>> ||rm -f foo.jar||
>>>>>>>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>>>>>> ||touch foo.jar||
>>>>>>>>>>> ||java -cp . -Xbootclasspath/a:foo.jar test2||
>>>>>>>>>>> ||*/||
>>>>>>>>>>> ||
>>>>>>>>>>> ||public class test2 {||
>>>>>>>>>>> ||    public static void main(String args[]) {||
>>>>>>>>>>> ||        try {||
>>>>>>>>>>> ||System.out.println(Class.forName("javax.crypto.MacSpi"));||
>>>>>>>>>>> ||System.out.println(Class.forName("xxx"));||
>>>>>>>>>>> ||        } catch (Throwable t) {||
>>>>>>>>>>> ||            t.printStackTrace();||
>>>>>>>>>>> ||        }||
>>>>>>>>>>> ||    }||
>>>>>>>>>>> ||}||
>>>>>>>>>>> ||=========================||
>>>>>>>>>>> | |
>>>>>>>>>>> ||JDK6 works fine, but JDK7 would crash with the second 
>>>>>>>>>>> "java -cp .
>>>>>>>>>>> -Xbootclasspath/a:foo.jar test2" command.||
>>>>>>>>>>> |
>>>>>>>>>> |I saw crash with the latest 6 update release with both test 
>>>>>>>>>> cases.
>>>>>>>>>> The crash seems to be at the same spot.
>>>>>>>>>> |
>>>>>>>>>>> |||
>>>>>>>>>>> ||So I think the correct fix is to restore the JDK6 behavior 
>>>>>>>>>>> (not
>>>>>>>>>>> sure if it's already the same with your patch, but worth 
>>>>>>>>>>> checking),
>>>>>>>>>>> and also add a new jtreg test into hotspot.||
>>>>>>>>>>> |
>>>>>>>>>> |I checked the jdk 6 code and those 3 methods which I changed 
>>>>>>>>>> look
>>>>>>>>>> the
>>>>>>>>>> same as jdk 8.
>>>>>>>>>> Sure, I can add a jtreg test.
>>>>>>>>>> |
>>>>>>>>>>> |||
>>>>>>>>>>> ||Thanks||
>>>>>>>>>>> ||- Ioi||
>>>>>>>>>>> ||
>>>>>>>>>>> ||On 08/07/2013 06:47 PM, David Holmes wrote:||
>>>>>>>>>>> |
>>>>>>>>>>>> |Hi Calvin, ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||It seems to me that this code has a general problem with
>>>>>>>>>>>> exceptions. If exceptions can be posted then methods should be
>>>>>>>>>>>> declared with a last parameter of TRAPS and called with a 
>>>>>>>>>>>> CHECK_
>>>>>>>>>>>> macro. The way this code is written it does not seem to 
>>>>>>>>>>>> expect any
>>>>>>>>>>>> exceptions to be possible. I would check with Karen on 
>>>>>>>>>>>> this. ||
>>>>>>>>>>>> |
>>>>>>>>>> |I was thinking about that but that would involves a bit more
>>>>>>>>>> changes.
>>>>>>>>>> I can give it a try.
>>>>>>>>>> |
>>>>>>>>>>>> || |
>>>>>>>>>>>> ||This addition seems unused: ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||+   Thread* THREAD = thread; ||
>>>>>>>>>>>> |
>>>>>>>>>> |It is required for the THROW_MSG().
>>>>>>>>>> It won't be needed if the method is declared with TRAPS as 
>>>>>>>>>> the last
>>>>>>>>>> parameter (I think).
>>>>>>>>>>
>>>>>>>>>> thanks,
>>>>>>>>>> Calvin
>>>>>>>>>> |
>>>>>>>>>>>> || |
>>>>>>>>>>>> ||Thumbs up on the removal of the EXCEPTION_MARKs prior to 
>>>>>>>>>>>> throwing
>>>>>>>>>>>> exceptions - don't know what the thought process was there 
>>>>>>>>>>>> :) ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||David ||
>>>>>>>>>>>> | |
>>>>>>>>>>>> ||On 8/08/2013 10:25 AM, Calvin Cheung wrote: ||
>>>>>>>>>>>> |
>>>>>>>>>>>>> |Please review this small fix for fixing a fatal error in ||
>>>>>>>>>>>>> ||~ExceptionMark() triggered by ClassNotFoundException in ||
>>>>>>>>>>>>> ||ClassLoader::create_class_path_entry(). I could reproduce
>>>>>>>>>>>>> similar
>>>>>>>>>>>>> crash ||
>>>>>>>>>>>>> ||by trying to load a class from an empty jar which is in 
>>>>>>>>>>>>> the ||
>>>>>>>>>>>>> ||bootclasspath. The following program can trigger the 
>>>>>>>>>>>>> crash if
>>>>>>>>>>>>> the ||
>>>>>>>>>>>>> ||jce.jar is invalid (e.g. 0-byte): ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||public class TestForName { ||
>>>>>>>>>>>>> ||     public static void main(String[] args) { ||
>>>>>>>>>>>>> ||         try { ||
>>>>>>>>>>>>> ||             Class cls =
>>>>>>>>>>>>> Class.forName("javax.crypto.KeyGenerator"); ||
>>>>>>>>>>>>> ||             System.out.println("Class = " + 
>>>>>>>>>>>>> cls.getName()); ||
>>>>>>>>>>>>> ||         } catch (ClassNotFoundException cnfe) { ||
>>>>>>>>>>>>> ||             cnfe.printStackTrace(); ||
>>>>>>>>>>>>> ||         } ||
>>>>>>>>>>>>> ||     } ||
>>>>>>>>>>>>> ||} ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||The fix also changes the assert() in
>>>>>>>>>>>>> LazyClassPathEntry::resolve_entry() ||
>>>>>>>>>>>>> ||to a NULL check. Otherwise, the assert() will fail under 
>>>>>>>>>>>>> the
>>>>>>>>>>>>> above test ||
>>>>>>>>>>>>> ||scenario. ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||With the fix, the following ClassNotFoundException will be
>>>>>>>>>>>>> thrown ||
>>>>>>>>>>>>> ||instead of a crash: ||
>>>>>>>>>>>>> ||java.lang.ClassNotFoundException: 
>>>>>>>>>>>>> javax.crypto.KeyGenerator ||
>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:365) ||
>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:354) ||
>>>>>>>>>>>>> ||         at 
>>>>>>>>>>>>> java.security.AccessController.doPrivileged(Native
>>>>>>>>>>>>> Method) ||
>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>> java.net.URLClassLoader.findClass(URLClassLoader.java:353) ||
>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:423) ||
>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) 
>>>>>>>>>>>>> ||
>>>>>>>>>>>>> ||         at
>>>>>>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:356) ||
>>>>>>>>>>>>> ||         at java.lang.Class.forName0(Native Method) ||
>>>>>>>>>>>>> ||         at java.lang.Class.forName(Class.java:258) ||
>>>>>>>>>>>>> ||         at TestForName.main(TestForName.java:6) ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||webrev: 
>>>>>>>>>>>>> http://cr.openjdk.java.net/~ccheung/8020675/webrev/ ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||JBS: https://jbs.oracle.com/bugs/browse/JDK-8020675 ||
>>>>>>>>>>>>> ||bug: http://bugs.sun.com/view_bug.do?bug_id=8020675 ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||Tests: ||
>>>>>>>>>>>>> ||     jprt, vm.quick.testlist ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> ||thanks, ||
>>>>>>>>>>>>> ||Calvin ||
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> | |
>>>>>>>>>>>>> |
>>>>>>>>>>> |
>>>>>>>>>>> |
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>
>

More information about the hotspot-runtime-dev mailing list