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

Ioi Lam ioi.lam at oracle.com
Thu Aug 8 14:26:54 PDT 2013 

|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 ||
>>>>>> | |
>>>>>> | |
>>>>>> |
>>>> |
>>>> |
>>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130808/3c942d69/attachment-0001.html

More information about the hotspot-runtime-dev mailing list