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

[Calvin Cheung]

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/5208b7a5/attachment.html