Bug ID: JDK-6921073 Most of the CTS tests fail against glassfish v3u1 b01 using jdk 1.6.0

Type: Bug
Component: core-libs
Sub-Component: java.util.logging
Affected Version: 6u18

Priority: P3
Status: Closed
Resolution: Duplicate
OS: solaris
CPU: sparc

Submitted: 2010-01-28
Updated: 2011-05-13
Resolved: 2010-09-22

About 50% or more of all of the compatibility test suite will fail with NULL pointer exceptions.

This is a typical stack:

   [runcts] OUT => [javatest.batch] java.lang.NullPointerException
   [runcts] OUT => [javatest.batch]     at org.glassfish.appclient.client.acc.ACCLogger$1.run(ACCLogger.java:149)
   [runcts] OUT => [javatest.batch]     at java.security.AccessController.doPrivileged(Native Method)
   [runcts] OUT => [javatest.batch]     at org.glassfish.appclient.client.acc.ACCLogger.reviseLogger(ACCLogger.java:146)
   [runcts] OUT => [javatest.batch]     at org.glassfish.appclient.client.acc.ACCLogger.init(ACCLogger.java:93)
   [runcts] OUT => [javatest.batch]     at org.glassfish.appclient.client.acc.ACCLogger.<init>(ACCLogger.java:80)
   [runcts] OUT => [javatest.batch]     at org.glassfish.appclient.client.AppClientFacade.createBuilder(AppClientFacade.java:360)
   [runcts] OUT => [javatest.batch]     at org.glassfish.appclient.client.AppClientFacade.prepareACC(AppClientFacade.java:247)
   [runcts] OUT => [javatest.batch]     at org.glassfish.appclient.client.acc.agent.AppClientContainerAgent.premain(AppClientContainerAgent.java:75)
   [runcts] OUT => [javatest.batch]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   [runcts] OUT => [javatest.batch]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   [runcts] OUT => [javatest.batch]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   [runcts] OUT => [javatest.batch]     at java.lang.reflect.Method.invoke(Method.java:597)
   [runcts] OUT => [javatest.batch]     at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:323)
   [runcts] OUT => [javatest.batch]     at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:338)


# java -version
java version "1.6.0_18"
Java(TM) SE Runtime Environment (build 1.6.0_18-b07)
Java HotSpot(TM) Client VM (build 16.0-b13, mixed mode)

Fails with glassfish v3u1 b01 & glassfish v3u1 b02.

EVALUATION The JavaDoc changes have been made via the following bug: 6949710 3/3 the GC'able nature of Logging objects needs to be made brutally clear I am closing this bug as a duplicate of 6949710.
22-09-2010
EVALUATION It looks like the above "missing" change was elided because the caller of LogManager.getLoggerNames() still has to check the return value from LogManager.getLogger(name) for NULL. All the above change did was reduce the window for returning the name of a Logger that was GC'ed; the above change did not (and cannot) eliminate that window. It is looking like the only change that I need to make using this bug is an update to the JavaDoc for LogManager.getLoggerNames() and LogManager.getLogger(name). Consequently, I'm lowering the priority from P2 to P3.
10-02-2010
EVALUATION Serguei logged diffs for the proposed fix for 6274920 on 2006.08.30 and the note was last updated on 2006.09.04. According to my e-mail archive for 6274920, the original code review was sent out on 2006.10.04 and changes were made during the code review cycle. I've compared Serguei's original proposed fix to the current code and I only see the following missing: ************* * 555,560 **** --- 549,567 ---- * @return enumeration of logger name strings */ public synchronized Enumeration<String> getLoggerNames() { + Enumeration<String> keys = loggers.keys(); + + // This loop is needed for consistency. Some of the loggers + // can be GC-ed, so we usually delete them in such a case. + // However, we want this function to return the corresponding state. + while (keys.hasMoreElements()) { + String key = (String) keys.nextElement(); + WeakReference ref = loggers.get(key); + if (loggers.get(key).get() == null) { + // Stale reference - delete the entry + loggers.remove(key); + } + } return loggers.keys(); } I'm trying to dig up Serguei's original webrev that was sent out on 2006.10.04 so I can see if the above change went missing by that point in time or not. I'm trying to figure out if the change was intentionally dropped and, if so, for what reason.
09-02-2010
EVALUATION It looks like part of the fix for: 6274920 4/3 JDK logger holds strong reference to java.util.logging.Logger instances is missing. I'm investigating how this happened. Update: Just to be clear: the missing code will make it less likely that a LogManager.getLogger(name) call will return NULL when closely following a LogManager.getLoggerNames() call. However, the missing code cannot guarantee that NULL won't be returned. LogManager.getLoggerNames() returns an enumeration of Strings. It does not return references to the actual Loggers so the getLoggerNames() API cannot prevent an used Logger from being GC'ed before the call to LogManager.getLogger(name). I agree that the JavaDoc could be more clear about this.
09-02-2010