RFR: 8156153: java/lang/System/LoggerFinder/jdk/DefaultLoggerBridgeTest/DefaultLoggerBridgeTest.java fails with java.lang.RuntimeException

Daniel Fuchs daniel.fuchs at oracle.com
Fri May 6 14:22:13 UTC 2016


Hi,

This is a fix for a subtle test bug caused by a logger being GCed.

bug id:
https://bugs.openjdk.java.net/browse/JDK-8156153
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8156153/webrev/

This test has been seen failing in hs integration with the following
error:

----------------------------------------
...
*** With Security Manager, without permissions
...
----------System.err:(24/1937)----------
java.lang.RuntimeException: identical backend loggers
	at DefaultLoggerBridgeTest.test(DefaultLoggerBridgeTest.java:404)
...
----------------------------------------

The main runs the same test sequentially in 3 different configurations:

- without security manager,
- with security manager and no permissions granted,
- with security manager and permissions granted.

The test attempts to first create a lazy logger for a system class,
then a logger for an application class. It expects that the second
concrete logger will be created first - because it should not be
wrapped in a lazy logger.

However, since the loggers are not referenced outside of the test
method, then it can happen that the application logger gets garbage
collected between one scenario and the next, which will invert the
creation sequence (or more exactly pseudo-creation sequence in
this case) in the next scenario.

To fix this I propose to run each scenario in its own VM - by using
three different @run main lines. This way each scenario will start
with a clean slate.

best regards,

-- daniel




More information about the core-libs-dev mailing list