RFR(M): 8203826: Chain class initialization exceptions into later NoClassDefFoundErrors
Peter Levart
peter.levart at gmail.com
Mon Jul 9 07:22:30 UTC 2018
Hi David,
On 07/09/2018 03:37 AM, David Holmes wrote:
> Hi Peter,
>
> On 7/07/2018 2:10 AM, Peter Levart wrote:
>> Hi,
>>
>> On 07/05/2018 01:01 AM, David Holmes wrote:
>>> I dispute "they will understand this might have happened in another
>>> thread".
>>
>> What if the stack trace was like the following...
>
> Yes your suggestion makes it much clearer.
>
> But ... my whole objection here is doing all this extraneous execution
> of Java code in response to the initial exception. The more Java code
> we execute the more likely we will hit secondary exceptions and the
> greater the possibility of unintended interactions that might lead
> back to the class that can't be initialized. I just don't think this
> level of effort is warranted. I
I agree that more classes are involved, but they are all JDK classes and
their number is constant. Meaning, if they are OK and don't fail when
initializing, there's no danger of unintended interactions that would be
caused by initialization errors in other classes. And even if those
additional needed classes had problems in their initialization, I think
that the consequences would be under control.
Let's see what additional classes are needed when the presented patch is
used as opposed to classes needed in current logic:
In step 7, when super class/interface initialization fails and in steps
10/11 when the class initialization fails, we record the error thrown
(record_init_exception). In addition to previously needed classes we
also need:
- ClassLoader,
- ClassLoader$InitExceptionSubst (with dependencies: RuntimeException,
Exception),
- ClassLoaderValue (with dependencies: AbstractClassLoaderValue,
AbstractClassLoaderValue$Sub, AbstractClassLoaderValue$Memoizer,
ConcurrentHashMap + deps)
When we throw NoClassDefFoundError, we don't need any other additional
classes that wouldn't already be needed originally.
So I can see that when above additional classes had problems
initializing themselves, there would be errors thrown from their usage
when recording initial initialization exception of some unrelated class,
but such errors would be ignored (step 7):
979 // Record the exception thrown from super class/interface
initialization so that
980 // it can be chained into potential later
NoClassDefFoundErrors.
981 class_loader_data()->record_init_exception(java_mirror_handle(),
e, THREAD);
982 // Locks object, set state, and notify all waiting threads
983 set_initialization_state_and_notify(initialization_error, THREAD);
984 *CLEAR_PENDING_EXCEPTION*;
steps 10/11:
1037 // Record the exception that originally caused <clinit> to
fail so
1038 // it can be chained into potential later NoClassDefFoundErrors.
1039 class_loader_data()->record_init_exception(java_mirror_handle(), e,
THREAD);
1040 // Locks object, set state, and notify all waiting threads
1041 set_initialization_state_and_notify(initialization_error,
THREAD);
1042 *CLEAR_PENDING_EXCEPTION*;
It might be that those ignored exceptions would cause later use of those
additional classes to throw NoClassDefFoundError instead of
ExceptionInInitializerError (depending on whether it was an initial
attempt to initialize those additional classes or not), but I can't see
any other undesirable consequence. Do you?
I'll try to provoke initialization errors in those additional classes to
see what happens. Will get back when I have results of the experiment...
Regards, Peter
P.S.
Executing java code as part of VM logic plays well in Jigsaw for
example. If there is an acceptable fallback in case of java logic
failure, everything seems to be OK.
> Cheers,
> David
> -----
>
>> Before patch:
>>
>> 1st attempt [ForkJoinPool.commonPool-worker-3]:
>>
>> java.lang.ExceptionInInitializerError
>> at ClinitFailure.lambda$main$0(ClinitFailure.java:20)
>> at
>> java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1736)
>>
>> at
>> java.base/java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1728)
>>
>> at
>> java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
>> at
>> java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
>>
>> at
>> java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
>> at
>> java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
>>
>> at
>> java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177)
>>
>> Caused by: java.lang.RuntimeException: Can't get it!
>> at ClinitFailure$Faulty.<clinit>(ClinitFailure.java:12)
>> ... 8 more
>> Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 1 out of
>> bounds for length 0
>> at ClinitFailure$Faulty.<clinit>(ClinitFailure.java:10)
>> ... 8 more
>>
>> 2nd attempt [ForkJoinPool.commonPool-worker-5]:
>>
>> java.lang.NoClassDefFoundError: Could not initialize class
>> ClinitFailure$Faulty
>> at ClinitFailure.lambda$main$1(ClinitFailure.java:28)
>> at
>> java.base/java.util.concurrent.CompletableFuture$UniRun.tryFire(CompletableFuture.java:783)
>>
>> at
>> java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:479)
>>
>> at
>> java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
>> at
>> java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
>>
>> at
>> java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
>> at
>> java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
>>
>> at
>> java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177)
>>
>>
>>
>> After patch:
>>
>> 1st attempt [ForkJoinPool.commonPool-worker-3]:
>>
>> java.lang.ExceptionInInitializerError
>> at ClinitFailure.lambda$main$0(ClinitFailure.java:18)
>> at
>> java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1736)
>>
>> at
>> java.base/java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1728)
>>
>> at
>> java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
>> at
>> java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
>>
>> at
>> java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
>> at
>> java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
>>
>> at
>> java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177)
>>
>> Caused by: java.lang.RuntimeException: Can't get it!
>> at ClinitFailure$Faulty.<clinit>(ClinitFailure.java:10)
>> ... 8 more
>> Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 1 out of
>> bounds for length 0
>> at ClinitFailure$Faulty.<clinit>(ClinitFailure.java:8)
>> ... 8 more
>>
>> 2nd attempt [ForkJoinPool.commonPool-worker-5]:
>>
>> java.lang.NoClassDefFoundError: Could not initialize class
>> ClinitFailure$Faulty
>> at
>> java.base/java.lang.ClassLoader.throwReinitException(ClassLoader.java:3062)
>> at ClinitFailure.lambda$main$1(ClinitFailure.java:25)
>> at
>> java.base/java.util.concurrent.CompletableFuture$UniRun.tryFire(CompletableFuture.java:783)
>>
>> at
>> java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:479)
>>
>> at
>> java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
>> at
>> java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
>>
>> at
>> java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
>> at
>> java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
>>
>> at
>> java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177)
>>
>> Caused by: java.lang.ExceptionInInitializerError: 11 ms ago in thread
>> ForkJoinPool.commonPool-worker-3
>> at ClinitFailure.lambda$main$0(ClinitFailure.java:18)
>> at
>> java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1736)
>>
>> at
>> java.base/java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1728)
>>
>> ... 5 more
>> Caused by: java.lang.RuntimeException: Can't get it!
>> at ClinitFailure$Faulty.<clinit>(ClinitFailure.java:10)
>> ... 8 more
>> Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 1 out of
>> bounds for length 0
>> at ClinitFailure$Faulty.<clinit>(ClinitFailure.java:8)
>> ... 8 more
>>
>>
>>
>> This is what gets printed by the sample program:
>>
>> public class ClinitFailure {
>>
>> static class Faulty {
>> static {
>> try {
>> int i = (new int[0])[1];
>> } catch (Exception e) {
>> throw new RuntimeException("Can't get it!", e);
>> }
>> }
>> }
>>
>> public static void main(String[] args) throws Exception {
>> CompletableFuture.runAsync(() -> {
>> try {
>> new Faulty();
>> } catch (Throwable e) {
>> System.out.printf("\n1st attempt [%s]:\n\n",
>> Thread.currentThread().getName());
>> e.printStackTrace(System.out);
>> }
>> }).thenRunAsync(() -> {
>> try {
>> new Faulty();
>> } catch (Throwable e) {
>> System.out.printf("\n2nd attempt [%s]:\n\n",
>> Thread.currentThread().getName());
>> e.printStackTrace(System.out);
>> }
>> }).join();
>> }
>> }
>>
>>
>> When the following patch is applied:
>>
>> http://cr.openjdk.java.net/~plevart/jdk-dev/8203826_NoClassDefFoundError.cause/webrev.01/
>>
>>
>>
>> I took Volker's patch and modified it a bit:
>>
>> - The logic to construct and throw NoClassDefFoundError and to record
>> initial <clinit> exception is in java now. It uses ClassLoaderValue
>> internal API to save the chains of exception(s) for faulty classes.
>> It is easier to do such logic in Java and less error prone.
>> - The chain of original <clinit> exception(s) is replaced with
>> substitutes that mimic .toString() and .printStackTrace() methods of
>> original chain, but don't reference any classes outside bootstrap
>> class loader
>> - The replacement chain of original exceptions adds a custom message
>> insert into the top exception as a hint to the user:
>>
>> java.lang.ExceptionInInitializerError: 11 ms ago in thread
>> ForkJoinPool.commonPool-worker-3
>>
>>
>> So, what do you think of this one?
>>
>> Regards, Peter
>>
>>
More information about the hotspot-runtime-dev
mailing list