You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Yu Lin (JIRA)" <ji...@apache.org> on 2012/07/10 05:02:33 UTC
[jira] [Created] (WICKET-4646) atomicity violation bugs of using
concurrent collections
Yu Lin created WICKET-4646:
------------------------------
Summary: atomicity violation bugs of using concurrent collections
Key: WICKET-4646
URL: https://issues.apache.org/jira/browse/WICKET-4646
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.5.7
Reporter: Yu Lin
My name is Yu Lin. I'm a Ph.D. student in the CS department at
UIUC. I'm currently doing research on mining Java concurrent library
misusages. I found some misusages of ConcurrentHashMap in wicket
1.5.7, which may result in potential atomicity violation bugs.
The code below is a snapshot of the code in file
src/wicket-core/src/main/java/org/apache/wicket/request/resource/PackageResourceReference.java from line 152 to 157
L152 UrlAttributes value = urlAttributesCacheMap.get(key);
L153 if (value == null)
L154 {
L155 value = getUrlAttributes(locale, style, variation);
L156 urlAttributesCacheMap.put(key, value);
L157 }
In the code above, an atomicity violation may occur between lines <154
and 156>. Suppose a thread T1 executes line 152 and finds out the
concurrent hashmap does not contain the key "key". Before it gets to
execute line 156, another thread T2 puts a pair <key, v> in the
concurrent hashmap "urlAttributesCacheMap". Now thread T1 resumes
execution and it will overwrite the value written by thread T2. Thus,
the code no longer preserves the "put-if-absent" semantics. By using
putIfAbsent method, we can eliminated this atomicity violation (see
patch).
I found some similar atomicity violations in other files:
In
src/wicket-core/src/main/java/org/apache/wicket/util/lang/PropertyResolver.java,
atomicity violation may occur if thread T2 puts a value to the map
between lines <385 and 522> or <234 and 260>. However, it seems map
"getAndSetters" is not always a ConcurrentHashMap that the first
atomicity violation at line 522 cannot be fixed by using putIfAbsent,
so should we use synchronized?
In
src/wicket-core/src/main/java/org/apache/wicket/session/DefaultPageFactory.java,
atomicity violation may occur if thread T2 puts a value to the map
between lines <124 and 131> or <234 and 260>.
In
src/wicket-core/src/test/java/org/apache/wicket/versioning/InMemoryPageStore.java,
atomicity violation may occur if thread T2 puts a value to the map
between lines <95 and 97>.
In
src/wicket-spring/src/main/java/org/apache/wicket/spring/injection/annot/AnnotProxyFieldValueFactory.java,
atomicity violation may occur if thread T2 puts a value to the map
between lines <127 and 142> or <165 and 170>.
In
src/wicket-util/src/main/java/org/apache/wicket/util/convert/converter/AbstractIntegerConverter.java,
atomicity violation may occur if thread T2 puts a value to the map
between lines <47 and 51>.
In
src/wicket-util/src/main/java/org/apache/wicket/util/watch/ModificationWatcher.java,
atomicity violation may occur if thread T2 puts a value to the map
between lines <95 and 107>.
Meanwhile, there may be an atomicty violation between lines <190 and 200> in
src/wicket-core/src/main/java/org/apache/wicket/feedback/FeedbackMessages.java.
Suppose thread T1 finds list "messages" is not empty at line
187. Before T1 removes "toDelete" from "messages" at line 200, T1
suspends and another thread T2 removes the same "toDelete" from "messages".
When T1 resumes, it will remove nothing and "clear" will return the wrong value (in
this case, "clear" method should return 0). Though I'm not sure whether this scenario
will happen, I also provide a patch for this atomicty violation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (WICKET-4646) atomicity violation bugs of using
concurrent collections
Posted by "Martin Grigorov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Grigorov reassigned WICKET-4646:
---------------------------------------
Assignee: Martin Grigorov
> atomicity violation bugs of using concurrent collections
> --------------------------------------------------------
>
> Key: WICKET-4646
> URL: https://issues.apache.org/jira/browse/WICKET-4646
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.5.7
> Reporter: Yu Lin
> Assignee: Martin Grigorov
> Labels: patch
> Attachments: fix-WICKET-4646.patch
>
> Original Estimate: 504h
> Remaining Estimate: 504h
>
> My name is Yu Lin. I'm a Ph.D. student in the CS department at
> UIUC. I'm currently doing research on mining Java concurrent library
> misusages. I found some misusages of ConcurrentHashMap in wicket
> 1.5.7, which may result in potential atomicity violation bugs.
> The code below is a snapshot of the code in file
> src/wicket-core/src/main/java/org/apache/wicket/request/resource/PackageResourceReference.java from line 152 to 157
> L152 UrlAttributes value = urlAttributesCacheMap.get(key);
> L153 if (value == null)
> L154 {
> L155 value = getUrlAttributes(locale, style, variation);
> L156 urlAttributesCacheMap.put(key, value);
> L157 }
> In the code above, an atomicity violation may occur between lines <154
> and 156>. Suppose a thread T1 executes line 152 and finds out the
> concurrent hashmap does not contain the key "key". Before it gets to
> execute line 156, another thread T2 puts a pair <key, v> in the
> concurrent hashmap "urlAttributesCacheMap". Now thread T1 resumes
> execution and it will overwrite the value written by thread T2. Thus,
> the code no longer preserves the "put-if-absent" semantics. By using
> putIfAbsent method, we can eliminated this atomicity violation (see
> patch).
> I found some similar atomicity violations in other files:
> In
> src/wicket-core/src/main/java/org/apache/wicket/util/lang/PropertyResolver.java,
> atomicity violation may occur if thread T2 puts a value to the map
> between lines <385 and 522> or <234 and 260>. However, it seems map
> "getAndSetters" is not always a ConcurrentHashMap that the first
> atomicity violation at line 522 cannot be fixed by using putIfAbsent,
> so should we use synchronized?
> In
> src/wicket-core/src/main/java/org/apache/wicket/session/DefaultPageFactory.java,
> atomicity violation may occur if thread T2 puts a value to the map
> between lines <124 and 131> or <234 and 260>.
> In
> src/wicket-core/src/test/java/org/apache/wicket/versioning/InMemoryPageStore.java,
> atomicity violation may occur if thread T2 puts a value to the map
> between lines <95 and 97>.
> In
> src/wicket-spring/src/main/java/org/apache/wicket/spring/injection/annot/AnnotProxyFieldValueFactory.java,
> atomicity violation may occur if thread T2 puts a value to the map
> between lines <127 and 142> or <165 and 170>.
> In
> src/wicket-util/src/main/java/org/apache/wicket/util/convert/converter/AbstractIntegerConverter.java,
> atomicity violation may occur if thread T2 puts a value to the map
> between lines <47 and 51>.
> In
> src/wicket-util/src/main/java/org/apache/wicket/util/watch/ModificationWatcher.java,
> atomicity violation may occur if thread T2 puts a value to the map
> between lines <95 and 107>.
> Meanwhile, there may be an atomicty violation between lines <190 and 200> in
> src/wicket-core/src/main/java/org/apache/wicket/feedback/FeedbackMessages.java.
> Suppose thread T1 finds list "messages" is not empty at line
> 187. Before T1 removes "toDelete" from "messages" at line 200, T1
> suspends and another thread T2 removes the same "toDelete" from "messages".
> When T1 resumes, it will remove nothing and "clear" will return the wrong value (in
> this case, "clear" method should return 0). Though I'm not sure whether this scenario
> will happen, I also provide a patch for this atomicty violation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-4646) atomicity violation bugs of using
concurrent collections
Posted by "Martin Grigorov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Grigorov resolved WICKET-4646.
-------------------------------------
Resolution: Fixed
Fix Version/s: 1.5.8
6.0.0
Thank you!
> atomicity violation bugs of using concurrent collections
> --------------------------------------------------------
>
> Key: WICKET-4646
> URL: https://issues.apache.org/jira/browse/WICKET-4646
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.5.7
> Reporter: Yu Lin
> Assignee: Martin Grigorov
> Labels: patch
> Fix For: 6.0.0, 1.5.8
>
> Attachments: fix-WICKET-4646.patch
>
> Original Estimate: 504h
> Remaining Estimate: 504h
>
> My name is Yu Lin. I'm a Ph.D. student in the CS department at
> UIUC. I'm currently doing research on mining Java concurrent library
> misusages. I found some misusages of ConcurrentHashMap in wicket
> 1.5.7, which may result in potential atomicity violation bugs.
> The code below is a snapshot of the code in file
> src/wicket-core/src/main/java/org/apache/wicket/request/resource/PackageResourceReference.java from line 152 to 157
> L152 UrlAttributes value = urlAttributesCacheMap.get(key);
> L153 if (value == null)
> L154 {
> L155 value = getUrlAttributes(locale, style, variation);
> L156 urlAttributesCacheMap.put(key, value);
> L157 }
> In the code above, an atomicity violation may occur between lines <154
> and 156>. Suppose a thread T1 executes line 152 and finds out the
> concurrent hashmap does not contain the key "key". Before it gets to
> execute line 156, another thread T2 puts a pair <key, v> in the
> concurrent hashmap "urlAttributesCacheMap". Now thread T1 resumes
> execution and it will overwrite the value written by thread T2. Thus,
> the code no longer preserves the "put-if-absent" semantics. By using
> putIfAbsent method, we can eliminated this atomicity violation (see
> patch).
> I found some similar atomicity violations in other files:
> In
> src/wicket-core/src/main/java/org/apache/wicket/util/lang/PropertyResolver.java,
> atomicity violation may occur if thread T2 puts a value to the map
> between lines <385 and 522> or <234 and 260>. However, it seems map
> "getAndSetters" is not always a ConcurrentHashMap that the first
> atomicity violation at line 522 cannot be fixed by using putIfAbsent,
> so should we use synchronized?
> In
> src/wicket-core/src/main/java/org/apache/wicket/session/DefaultPageFactory.java,
> atomicity violation may occur if thread T2 puts a value to the map
> between lines <124 and 131> or <234 and 260>.
> In
> src/wicket-core/src/test/java/org/apache/wicket/versioning/InMemoryPageStore.java,
> atomicity violation may occur if thread T2 puts a value to the map
> between lines <95 and 97>.
> In
> src/wicket-spring/src/main/java/org/apache/wicket/spring/injection/annot/AnnotProxyFieldValueFactory.java,
> atomicity violation may occur if thread T2 puts a value to the map
> between lines <127 and 142> or <165 and 170>.
> In
> src/wicket-util/src/main/java/org/apache/wicket/util/convert/converter/AbstractIntegerConverter.java,
> atomicity violation may occur if thread T2 puts a value to the map
> between lines <47 and 51>.
> In
> src/wicket-util/src/main/java/org/apache/wicket/util/watch/ModificationWatcher.java,
> atomicity violation may occur if thread T2 puts a value to the map
> between lines <95 and 107>.
> Meanwhile, there may be an atomicty violation between lines <190 and 200> in
> src/wicket-core/src/main/java/org/apache/wicket/feedback/FeedbackMessages.java.
> Suppose thread T1 finds list "messages" is not empty at line
> 187. Before T1 removes "toDelete" from "messages" at line 200, T1
> suspends and another thread T2 removes the same "toDelete" from "messages".
> When T1 resumes, it will remove nothing and "clear" will return the wrong value (in
> this case, "clear" method should return 0). Though I'm not sure whether this scenario
> will happen, I also provide a patch for this atomicty violation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4646) atomicity violation bugs of using
concurrent collections
Posted by "Yu Lin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Yu Lin updated WICKET-4646:
---------------------------
Attachment: fix-WICKET-4646.patch
This is a patch that can fix the atomicity violation bugs.
> atomicity violation bugs of using concurrent collections
> --------------------------------------------------------
>
> Key: WICKET-4646
> URL: https://issues.apache.org/jira/browse/WICKET-4646
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.5.7
> Reporter: Yu Lin
> Labels: patch
> Attachments: fix-WICKET-4646.patch
>
> Original Estimate: 504h
> Remaining Estimate: 504h
>
> My name is Yu Lin. I'm a Ph.D. student in the CS department at
> UIUC. I'm currently doing research on mining Java concurrent library
> misusages. I found some misusages of ConcurrentHashMap in wicket
> 1.5.7, which may result in potential atomicity violation bugs.
> The code below is a snapshot of the code in file
> src/wicket-core/src/main/java/org/apache/wicket/request/resource/PackageResourceReference.java from line 152 to 157
> L152 UrlAttributes value = urlAttributesCacheMap.get(key);
> L153 if (value == null)
> L154 {
> L155 value = getUrlAttributes(locale, style, variation);
> L156 urlAttributesCacheMap.put(key, value);
> L157 }
> In the code above, an atomicity violation may occur between lines <154
> and 156>. Suppose a thread T1 executes line 152 and finds out the
> concurrent hashmap does not contain the key "key". Before it gets to
> execute line 156, another thread T2 puts a pair <key, v> in the
> concurrent hashmap "urlAttributesCacheMap". Now thread T1 resumes
> execution and it will overwrite the value written by thread T2. Thus,
> the code no longer preserves the "put-if-absent" semantics. By using
> putIfAbsent method, we can eliminated this atomicity violation (see
> patch).
> I found some similar atomicity violations in other files:
> In
> src/wicket-core/src/main/java/org/apache/wicket/util/lang/PropertyResolver.java,
> atomicity violation may occur if thread T2 puts a value to the map
> between lines <385 and 522> or <234 and 260>. However, it seems map
> "getAndSetters" is not always a ConcurrentHashMap that the first
> atomicity violation at line 522 cannot be fixed by using putIfAbsent,
> so should we use synchronized?
> In
> src/wicket-core/src/main/java/org/apache/wicket/session/DefaultPageFactory.java,
> atomicity violation may occur if thread T2 puts a value to the map
> between lines <124 and 131> or <234 and 260>.
> In
> src/wicket-core/src/test/java/org/apache/wicket/versioning/InMemoryPageStore.java,
> atomicity violation may occur if thread T2 puts a value to the map
> between lines <95 and 97>.
> In
> src/wicket-spring/src/main/java/org/apache/wicket/spring/injection/annot/AnnotProxyFieldValueFactory.java,
> atomicity violation may occur if thread T2 puts a value to the map
> between lines <127 and 142> or <165 and 170>.
> In
> src/wicket-util/src/main/java/org/apache/wicket/util/convert/converter/AbstractIntegerConverter.java,
> atomicity violation may occur if thread T2 puts a value to the map
> between lines <47 and 51>.
> In
> src/wicket-util/src/main/java/org/apache/wicket/util/watch/ModificationWatcher.java,
> atomicity violation may occur if thread T2 puts a value to the map
> between lines <95 and 107>.
> Meanwhile, there may be an atomicty violation between lines <190 and 200> in
> src/wicket-core/src/main/java/org/apache/wicket/feedback/FeedbackMessages.java.
> Suppose thread T1 finds list "messages" is not empty at line
> 187. Before T1 removes "toDelete" from "messages" at line 200, T1
> suspends and another thread T2 removes the same "toDelete" from "messages".
> When T1 resumes, it will remove nothing and "clear" will return the wrong value (in
> this case, "clear" method should return 0). Though I'm not sure whether this scenario
> will happen, I also provide a patch for this atomicty violation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira