RFR: JDK-8014045 - test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java failing intermittently

Daniel Fuchs daniel.fuchs at oracle.com
Wed Jun 19 09:00:42 UTC 2013


On 6/13/13 10:05 PM, Mandy Chung wrote:
> Daniel,
>
> I wonder what the list of logger names (loggers1 and loggers2) returned
> by LoggingMXBean contains and that may include loggers in the running VM
> other than the ones created and kept a strong reference by the test. In
> other words,  would it be possible for the running VM that has loggers
> that are not created by the test and got GC'ed?

Hi Mandy,

I have added a System.out.println to print the list of logger names.
By running jtreg on my machine I could see that this list does contain
system logger names (mostly JMX loggers).
I believe those loggers are strongly referenced by JMX.
Other than those I could see "" and "global".

<http://cr.openjdk.java.net/~dfuchs/JDK-8014045/webrev.00/>

However - since this seems to be an intermittent failure - maybe the
logger that was causing the problem had already been gc'ed before
getLoggerNames() and therefore didn't appear in this list.
The test would fail when that 'transient' logger appears in the
list but is gc'ed before getLoggerLevel() is called.

Anyway - it's possible that some platform class
is calling:
    Logger log = Logger.getLogger(<some-name>);
    if (log.isLoggable(<some-leve>)) {...}
without keeping a strong reference to the logger in the class.

In that case I guess it would be possible for that <some-name>
to appear transiently in the logger's name list - and be gc'ed
just after...

-- daniel

>
> Mandy
>
> On 6/13/2013 6:47 AM, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find below an attempt at fixing
>> test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java
>>
>> This is an intermittent failure which I haven't managed to reproduce,
>> so I am reduced to figure out what could have gone wrong by analyzing
>> the code.
>>
>> AFAICT the NPE is thrown when LoggingMXBean.getLogerLevel(logger)
>> returns null - which I believe can only happen
>> when LogManager.getLogger() returns null.
>>
>> I see that LogManager uses weak references to hold loggers - so my
>> suspicion is that one of the logger whose name had been returned by
>> getLoggerNames() has been gc'ed in between the two calls.
>>
>> I have modified the code to accept this possibility - excluding the
>> two loggers for which the test itself holds a strong reference, as
>> these should not have been gc'ed.
>>
>> I can't guarantee that it will fix the issue, but if it does not,
>> we will at least be able to disregard this possibility :-)
>>
>> <http://cr.openjdk.java.net/~dfuchs/JDK-8014045/webrev.00/>
>>
>> -- daniel
>




More information about the core-libs-dev mailing list