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
Thu Aug 8 14:18:00 PDT 2013 

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