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

David Holmes david.holmes at oracle.com
Sun Aug 11 22:40:49 PDT 2013 

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