SUGGESTED FIX

I have deleted the lmdd.Mar6.tar from attachment as it is incorrect fix.
Please, see another webrev lmd.Apr7.tar in attachment.
                                     

SUGGESTED FIX

Please, see the webrev lmdd.Mar6.tar in attachments.
                                     

EVALUATION

Big thanks to Mattnias who provided the testcase from SAP.
Now I'm able too reproduce the problem.
This is the deadlock reproducible with the tescase:

Thread #13:
java/util/logging/LogManager.<clinit>() ->
    java/security/AccessController.doPrivileged() -> ... -> JVM_DoPrivileged ->
    java/util/logging/LogManager$1.run() ->
    InterpreterRuntime::_new() -> BLOCKED
    Related lines of the source code:
       LogManager.java(L169) : manager.rootLogger = manager.new RootLogger();
       LogManager.java(L961) : private class RootLogger extends Logger {

Thread #14
java/util/logging/Logger.<clinit>() ->
    java/util/logging/getLogger() ->
    java/util/logging/LogManager.getLogManager() -> BLOCKED
    Related line of the source code:
       Logger.java(L228) : LogManager manager = LogManager.getLogManager();

Concurrent creating the rootLogger object at the LogManager class
initialization in the Thread #13 and a Logger object in the Thread #14
causes a deadlock. The LogManager.<clinit> creates an object of the
RootLogger class which is a subclass of the Logger class.
The Logger.<clinit> invokes the LogManager static method getLogManager(),
and so, both class initializations are waiting for each other to complete.

Please, see a pstack output in attachments: Logmanager_deadlock.pstk.
                                     

EVALUATION

The description says:
"The following two threads deadlock each other (the lock info in the thread
 dump is not very accurate).
 ...
 Basically "Thread-591" locks LogManager.manager and waits for the class
 initializer of LogManager to be finished. But "Thread-453" is inside the
 class initializer of LogManager and it wants to lock LogManager.manager."

It is not correct.
I think the thread dump is correct (but maybe not complete), and both
threads "Thread-591" and "Thread-453" are waiting to lock the same
LogManager.manager monitor.

But it is completely unclear from the thread dump (from attachment) what
thread holds the LogManager.manager lock.
The sample example in the description is very interesting but it looks
like it is unrelated to the real reason of the deadlock.

The most important part of analysis is reproducing this problem with
the real test.
I was not able to reproduce it with the nsk/stress/jck12a/jck12a014.
There is no info in the description on how to reproduce the bug
and its reproducibility rate.
It is possible that the test was modified to workaround this bug because
this scenarious stress test can be needed to catch other problems.
It would be nice to run the old version of the test from the old testbase.

This is a preliminar input because more analysis is still needs to be done.
                                     

CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
dragon


                                     

EVALUATION

This is related to the change in 1.4.2 to move logging initialization out of the system class. (see 4770189 and others)

The difference in 1.5 is that logging is automatically enabled by awt. It may be possible to reduce the rate of occurance by a small amount of tweaking.

###@###.### 2004-02-13

The cleaner thread is the cause of this deadlock, I can narrow down the lock scope however as this is due to a stress test it is probably too risky to integrated at this point in the schedule. I'll carry on testing it for the next update

###@###.### 2004-03-04