[GLASSFISH-18968] Possible atomicity violations because of misusing ConcurrentHashMap Created: 01/Aug/12  Updated: 01/Aug/12

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: 3.1.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: jacklondongood Assignee: prasads
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File glassfish-3.1.2-amx.patch    


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 possible misuses of ConcurrentHashMap in amx
component of GlassFish 3.1.2, which may result in potential atomicity
violation bugs.

The code below is a snapshot of the code in file
from line 85 to 164

L85 public ObjectName resolvePath(final String path) {
L86 ObjectName result = mPathnameCache.get(path);
L87 if (result != null)

{ L88 return result; L89 }

... // create "objectName"
L159 if (objectName != null)

{ L160 //cdebug( "Matched " + path + " to " + objectName); L161 mPathnameCache.put(path, objectName); L162 }

L164 return objectName;
L165 }

In the code above, there might be an atomicity violation: suppose a
thread T1 executes line 86 and finds out the concurrent hashmap
"mPathnameCache" does not contain the key "path". Before it
gets to execute line 161, another thread T2 puts a pair <path, v>
in the map "mPathnameCache". 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, and thread T2 will
return an "objectName" that is not in the map "mPathnameCache". May this
thread interleaving happen? Will it result in buggy behavior?

Similar problem can be found in
line 434.

This issue is related to GLASSFISH-18964. I attach a patch to fix the problem.

Generated at Thu Oct 08 20:20:10 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.