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 11:52:07 PDT 2013


|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??||
||
|
|==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/571869e7/attachment-0001.html 


More information about the hotspot-runtime-dev mailing list