You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Wendy Feng (JIRA)" <ji...@apache.org> on 2010/09/19 04:12:34 UTC
[jira] Created: (HARMONY-6651) Broken double checked locking in
DragSourceContext.java
Broken double checked locking in DragSourceContext.java
--------------------------------------------------------
Key: HARMONY-6651
URL: https://issues.apache.org/jira/browse/HARMONY-6651
Project: Harmony
Issue Type: Bug
Components: Classlib
Affects Versions: 6.0M1
Environment: Windows Xp
Reporter: Wendy Feng
I found broken double-checked locking in modules/nio_char/src/main/java/java/nio/charset/Charset.java
public abstract class Charset implements Comparable<Charset>{
...
public static SortedMap<String, Charset> availableCharsets() {
// Initialize the built-in charsets map cache if necessary
if (null == _builtInCharsets) {
synchronized (Charset.class) {
if (null == _builtInCharsets) {
_builtInCharsets = new TreeMap<String, Charset>(
IgnoreCaseComparator.getInstance());
_builtInProvider.putCharsets(_builtInCharsets);
}
}
}
...
}
...
}
The double checked locking idiom is broken in the code above. In current Java memory model (JMM), the writes initializing the TreeMap object and the write to the _builtInCharesets field could be reordered by the compiler, processor or memory system. It means the write to _builtInCharesets can happen before the writes in TreeMap object initialization.
Consequence:
When multiple threads access the code simultaneously, threads can see a non-null _builtInCharesets field, but the TreeMap can be partially constructed (e.g. The elementData array is not created yet). Then these threads invoke clone() method on the partially initialized TreeMap, which will result in undesired behavior, e.g. Throwing NullPointerException. The error doesn't manifest all the time due to the non-deterministic nature of multi-threading, but it would be too bad to leave the code depend on the undefined behavior.
In JDK 5 or above, declaring the _builtInCharesets field as volatile can fix the problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6651) Broken double checked locking in
DragSourceContext.java
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12912404#action_12912404 ]
Hudson commented on HARMONY-6651:
---------------------------------
Integrated in Harmony-1.5-head-linux-x86_64 #953 (See [https://hudson.apache.org/hudson/job/Harmony-1.5-head-linux-x86_64/953/])
Apply fix for HARMONY-6651: Broken double checked locking in DragSourceContext.java
> Broken double checked locking in DragSourceContext.java
> --------------------------------------------------------
>
> Key: HARMONY-6651
> URL: https://issues.apache.org/jira/browse/HARMONY-6651
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 6.0M1
> Environment: Windows Xp
> Reporter: Wendy Feng
> Assignee: Regis Xu
> Fix For: 5.0M16
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> I found broken double-checked locking in modules/nio_char/src/main/java/java/nio/charset/Charset.java
> public abstract class Charset implements Comparable<Charset>{
> ...
> public static SortedMap<String, Charset> availableCharsets() {
> // Initialize the built-in charsets map cache if necessary
> if (null == _builtInCharsets) {
> synchronized (Charset.class) {
> if (null == _builtInCharsets) {
> _builtInCharsets = new TreeMap<String, Charset>(
> IgnoreCaseComparator.getInstance());
> _builtInProvider.putCharsets(_builtInCharsets);
> }
> }
> }
> ...
> }
> ...
> }
> The double checked locking idiom is broken in the code above. In current Java memory model (JMM), the writes initializing the TreeMap object and the write to the _builtInCharesets field could be reordered by the compiler, processor or memory system. It means the write to _builtInCharesets can happen before the writes in TreeMap object initialization.
> Consequence:
> When multiple threads access the code simultaneously, threads can see a non-null _builtInCharesets field, but the TreeMap can be partially constructed (e.g. The elementData array is not created yet). Then these threads invoke clone() method on the partially initialized TreeMap, which will result in undesired behavior, e.g. Throwing NullPointerException. The error doesn't manifest all the time due to the non-deterministic nature of multi-threading, but it would be too bad to leave the code depend on the undefined behavior.
> In JDK 5 or above, declaring the _builtInCharesets field as volatile can fix the problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (HARMONY-6651) Broken double checked locking in
DragSourceContext.java
Posted by "Regis Xu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Regis Xu reassigned HARMONY-6651:
---------------------------------
Assignee: Regis Xu
> Broken double checked locking in DragSourceContext.java
> --------------------------------------------------------
>
> Key: HARMONY-6651
> URL: https://issues.apache.org/jira/browse/HARMONY-6651
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 6.0M1
> Environment: Windows Xp
> Reporter: Wendy Feng
> Assignee: Regis Xu
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> I found broken double-checked locking in modules/nio_char/src/main/java/java/nio/charset/Charset.java
> public abstract class Charset implements Comparable<Charset>{
> ...
> public static SortedMap<String, Charset> availableCharsets() {
> // Initialize the built-in charsets map cache if necessary
> if (null == _builtInCharsets) {
> synchronized (Charset.class) {
> if (null == _builtInCharsets) {
> _builtInCharsets = new TreeMap<String, Charset>(
> IgnoreCaseComparator.getInstance());
> _builtInProvider.putCharsets(_builtInCharsets);
> }
> }
> }
> ...
> }
> ...
> }
> The double checked locking idiom is broken in the code above. In current Java memory model (JMM), the writes initializing the TreeMap object and the write to the _builtInCharesets field could be reordered by the compiler, processor or memory system. It means the write to _builtInCharesets can happen before the writes in TreeMap object initialization.
> Consequence:
> When multiple threads access the code simultaneously, threads can see a non-null _builtInCharesets field, but the TreeMap can be partially constructed (e.g. The elementData array is not created yet). Then these threads invoke clone() method on the partially initialized TreeMap, which will result in undesired behavior, e.g. Throwing NullPointerException. The error doesn't manifest all the time due to the non-deterministic nature of multi-threading, but it would be too bad to leave the code depend on the undefined behavior.
> In JDK 5 or above, declaring the _builtInCharesets field as volatile can fix the problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (HARMONY-6651) Broken double checked locking in
DragSourceContext.java
Posted by "Regis Xu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Regis Xu resolved HARMONY-6651.
-------------------------------
Fix Version/s: 5.0M16
Resolution: Fixed
Thanks Wendy!
The fix was applied at trunk r998822, please verify.
> Broken double checked locking in DragSourceContext.java
> --------------------------------------------------------
>
> Key: HARMONY-6651
> URL: https://issues.apache.org/jira/browse/HARMONY-6651
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 6.0M1
> Environment: Windows Xp
> Reporter: Wendy Feng
> Assignee: Regis Xu
> Fix For: 5.0M16
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> I found broken double-checked locking in modules/nio_char/src/main/java/java/nio/charset/Charset.java
> public abstract class Charset implements Comparable<Charset>{
> ...
> public static SortedMap<String, Charset> availableCharsets() {
> // Initialize the built-in charsets map cache if necessary
> if (null == _builtInCharsets) {
> synchronized (Charset.class) {
> if (null == _builtInCharsets) {
> _builtInCharsets = new TreeMap<String, Charset>(
> IgnoreCaseComparator.getInstance());
> _builtInProvider.putCharsets(_builtInCharsets);
> }
> }
> }
> ...
> }
> ...
> }
> The double checked locking idiom is broken in the code above. In current Java memory model (JMM), the writes initializing the TreeMap object and the write to the _builtInCharesets field could be reordered by the compiler, processor or memory system. It means the write to _builtInCharesets can happen before the writes in TreeMap object initialization.
> Consequence:
> When multiple threads access the code simultaneously, threads can see a non-null _builtInCharesets field, but the TreeMap can be partially constructed (e.g. The elementData array is not created yet). Then these threads invoke clone() method on the partially initialized TreeMap, which will result in undesired behavior, e.g. Throwing NullPointerException. The error doesn't manifest all the time due to the non-deterministic nature of multi-threading, but it would be too bad to leave the code depend on the undefined behavior.
> In JDK 5 or above, declaring the _builtInCharesets field as volatile can fix the problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6651) Broken double checked locking in
DragSourceContext.java
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12912410#action_12912410 ]
Hudson commented on HARMONY-6651:
---------------------------------
Integrated in Harmony-select-1.5-head-linux-x86_64 #113 (See [https://hudson.apache.org/hudson/job/Harmony-select-1.5-head-linux-x86_64/113/])
Apply fix for HARMONY-6651: Broken double checked locking in DragSourceContext.java
> Broken double checked locking in DragSourceContext.java
> --------------------------------------------------------
>
> Key: HARMONY-6651
> URL: https://issues.apache.org/jira/browse/HARMONY-6651
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 6.0M1
> Environment: Windows Xp
> Reporter: Wendy Feng
> Assignee: Regis Xu
> Fix For: 5.0M16
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> I found broken double-checked locking in modules/nio_char/src/main/java/java/nio/charset/Charset.java
> public abstract class Charset implements Comparable<Charset>{
> ...
> public static SortedMap<String, Charset> availableCharsets() {
> // Initialize the built-in charsets map cache if necessary
> if (null == _builtInCharsets) {
> synchronized (Charset.class) {
> if (null == _builtInCharsets) {
> _builtInCharsets = new TreeMap<String, Charset>(
> IgnoreCaseComparator.getInstance());
> _builtInProvider.putCharsets(_builtInCharsets);
> }
> }
> }
> ...
> }
> ...
> }
> The double checked locking idiom is broken in the code above. In current Java memory model (JMM), the writes initializing the TreeMap object and the write to the _builtInCharesets field could be reordered by the compiler, processor or memory system. It means the write to _builtInCharesets can happen before the writes in TreeMap object initialization.
> Consequence:
> When multiple threads access the code simultaneously, threads can see a non-null _builtInCharesets field, but the TreeMap can be partially constructed (e.g. The elementData array is not created yet). Then these threads invoke clone() method on the partially initialized TreeMap, which will result in undesired behavior, e.g. Throwing NullPointerException. The error doesn't manifest all the time due to the non-deterministic nature of multi-threading, but it would be too bad to leave the code depend on the undefined behavior.
> In JDK 5 or above, declaring the _builtInCharesets field as volatile can fix the problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.