org.mozilla.javascript.ClassCache non thread-safe use of HashMap with 1.7R3

RESOLVED FIXED

Status

P1
critical
RESOLVED FIXED
7 years ago
6 years ago

People

(Reporter: glavoie, Unassigned)

Tracking

Details

(Reporter)

Description

7 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20100101 Firefox/11.0
Build ID: 20120312181643

Steps to reproduce:

Two threads using the same scope made calls to Java functions returning objects of the same type. Rhino tried to wrap both object as NativeJavaObject at the same time.


Actual results:

One thread got stuck in an infinite loop in the JavaMembers.lookupClass() method, at the "members = ct.get(cl);" line.

The problem is caused by "ct" being a HashMap. This HashMap got accessed by the two threads and the HashMap class is NOT thread-safe. This problem was introduced when the following change was done in the ClassCache class to replace the Hashtable instances with WeakHashMap instances, that eventually got replaced by HashMap instances:
https://github.com/mozilla/rhino/commit/fac646cca584c234dad54ebddd2157039b0f39cf


Expected results:

Both threads should have been able to wrap the Java objects of the same class at the same time. All the HashMap instances of ClassCache should be reverted to Hashtable or replaced with ConcurrentHashMap instances.
(Reporter)

Comment 1

7 years ago
The following thread talks about the same issue:
http://groups.google.com/group/mozilla.dev.tech.js-engine.rhino/browse_thread/thread/5a51b7b96f33d274?pli=1
Severity: normal → major
(Reporter)

Updated

6 years ago
Severity: major → critical
Priority: -- → P1
Version: 1.7R1 → head

Comment 2

6 years ago
Fixed in e83014775c28dc4d884f37023e19b05136b2ac5e
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.