RFR: JDK-8014045 - test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java failing intermittently
Daniel Fuchs
daniel.fuchs at oracle.com
Wed Jun 19 09:03:01 UTC 2013
On 6/19/13 11:00 AM, Daniel Fuchs wrote:
> 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/>
^^^^
<http://cr.openjdk.java.net/~dfuchs/JDK-8014045/webrev.01/>
sorry...
-- daniel
>
> 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