RFR(S) 8020675: Trying to print to a pdf file with PDFill PDF&Image Writer 10.0 Build 4
Calvin Cheung
calvin.cheung at oracle.com
Fri Aug 9 15:11:28 PDT 2013
I've updated the webrev with 2 changes:
1) added the TRAPS as the last parameter to the
create_class_path_entry() method;
2) added a jtreg test case.
http://cr.openjdk.java.net/~ccheung/8020675/webrev/
Please take a look again.
One more response in-lined below...
On 8/8/2013 4:11 PM, Ioi Lam wrote:
> |I found one version of JDK7 that does not crash:||
> ||
> sc11136754 ~$
> /net/jre.us.oracle.com/p/v31/jdk/7/all/b24/binaries/linux-amd64/bin/java
> -showversion -cp . -Xbootclasspath/a:foo.jar test2
> Error occurred during initialization of VM
> java/lang/ClassNotFoundException: error in opening JAR file foo.jar
> |
|I noticed that it started breaking in 7u40 b01; it was still working
with 7u25.
It may have something to do with when the set_init_completed() is called:
ExceptionMark::~ExceptionMark() {
if (_thread->has_pending_exception()) {
Handle exception(_thread, _thread->pending_exception());
_thread->clear_pending_exception(); // Needed to avoid infinite
recursion
if (is_init_completed()) {
exception->print();
fatal("ExceptionMark destructor expects no pending exceptions");
} else {
vm_exit_during_initialization(exception);
}
}
}
Before 7u40, I think the code path got to the "else" branch of
~ExceptionMark() and we just printed an error and exit.
set_init_completed() is only called from Threads::create_vm() and that
method didn't change much between 7u25 and 7u40 except for some NMT
initialization - MemTracker::bootstrap_single_thread(),
MemTracker::start(), etc. But I thought NMT isn't enabled by default?
Debugging with hs25, the set_init_completed() always happened before
create_class_path_entry() and both calls were done within the same
thread - "vm startup".
thanks,
Calvin
|
> |||
> ||
> ||- Ioi
> |
> On 08/08/2013 02:26 PM, Ioi Lam wrote:
>> |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/20130809/a67a0c45/attachment-0001.html
More information about the hotspot-runtime-dev
mailing list