-
Bug
-
Resolution: Fixed
-
P4
-
7
-
b143
-
b01
-
generic
-
generic
-
Verified
Here's part of David's reply to my reply:
Right - the most likely thing to fail because of this is a test that
wants to see the IllegalArgumentException. Even then the test would
have to be deliberately attempting this via multiple threads - which
seems unlikely. A basic test of the form:
getLogger("A", "foo");
try {
getLogger("A", "bar");
fail();
}
catch (IllegalArgumentException iae) {
// success
}
will be ok.
The only other thing, I just checked, is whether two threads racing
to define the same logger will encounter a problem. Other than
consuming time unnecessarily it appears that findResourceBundle is
idempotent if called with the same bundle name. So this seems to be
safe as well (famous last words)
Here's part of my reply to David's sighting e-mail:
My gut says that this race is not that critical because
in a properly functioning system one of the threads would
get an IllegalArgumentException. Please let me know if
I'm misunderstanding what you're saying here...
The fix for the following bug:
6977677 3/2 Deadlock on logging subsystem initialization
has introduced a race condition in ResourceBundle initialization.
Here's the sighting info from David H:
But this method now has a race condition:
372 // Synchronization is not required here. All synchronization for
373 // adding a new Logger object is handled by LogManager.addLogger().
374 public static Logger getLogger(String name, String resourceBundleName) {
375 LogManager manager = LogManager.getLogManager();
376 Logger result = manager.demandLogger(name);
377 if (result.resourceBundleName == null) {
378 // Note: we may get a MissingResourceException here.
379 result.setupResourceInfo(resourceBundleName);
380 } else if (!result.resourceBundleName.equals(resourceBundleName)) {
381 throw new IllegalArgumentException(result.resourceBundleName +
382 " != " + resourceBundleName);
383 }
384 return result;
385 }
Two threads calling this method with the same name but different resource bundle names can both see null at line 377 and install their different resource bundles. That section needs to be atomic.
Right - the most likely thing to fail because of this is a test that
wants to see the IllegalArgumentException. Even then the test would
have to be deliberately attempting this via multiple threads - which
seems unlikely. A basic test of the form:
getLogger("A", "foo");
try {
getLogger("A", "bar");
fail();
}
catch (IllegalArgumentException iae) {
// success
}
will be ok.
The only other thing, I just checked, is whether two threads racing
to define the same logger will encounter a problem. Other than
consuming time unnecessarily it appears that findResourceBundle is
idempotent if called with the same bundle name. So this seems to be
safe as well (famous last words)
Here's part of my reply to David's sighting e-mail:
My gut says that this race is not that critical because
in a properly functioning system one of the threads would
get an IllegalArgumentException. Please let me know if
I'm misunderstanding what you're saying here...
The fix for the following bug:
6977677 3/2 Deadlock on logging subsystem initialization
has introduced a race condition in ResourceBundle initialization.
Here's the sighting info from David H:
But this method now has a race condition:
372 // Synchronization is not required here. All synchronization for
373 // adding a new Logger object is handled by LogManager.addLogger().
374 public static Logger getLogger(String name, String resourceBundleName) {
375 LogManager manager = LogManager.getLogManager();
376 Logger result = manager.demandLogger(name);
377 if (result.resourceBundleName == null) {
378 // Note: we may get a MissingResourceException here.
379 result.setupResourceInfo(resourceBundleName);
380 } else if (!result.resourceBundleName.equals(resourceBundleName)) {
381 throw new IllegalArgumentException(result.resourceBundleName +
382 " != " + resourceBundleName);
383 }
384 return result;
385 }
Two threads calling this method with the same name but different resource bundle names can both see null at line 377 and install their different resource bundles. That section needs to be atomic.
- relates to
-
JDK-6977677 Deadlock on logging subsystem initialization
- Closed
-
JDK-8005899 Logger.getLogger(name, null) should not allow to reset a non-null resource bundle
- Closed