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

[Ioi Lam]

|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.||
||
||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.||
||
||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. ||
> | |
> ||This addition seems unused: ||
> | |
> ||+   Thread* THREAD = thread; ||
> | |
> ||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/20130807/ef26289b/attachment-0001.html