-
Bug
-
Resolution: Fixed
-
P2
-
1.3.0, 1.3.1
-
01
-
generic, sparc
-
generic
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2046053 | 1.4.0 | Everett Anderson | P2 | Closed | Fixed | beta3 |
Symptom:
MARSHAL or IOException explaining that the repository IDs of the received and local versions of a class are different when unmarshaling in RMI-IIOP.
This bug is due to a race condition present in
com.sun.corba.se.internal.io.ObjectStreamClass
Details (based on com.sun.corba.se.internal.io.ObjectStreamClass):
ObjectStreamClass maintains a cache in a static array called descriptorFor. People get instances of ObjectStreamClass by calling the static lookup factory method.
This method does the following:
1. Synchronizes on the static descriptorFor array
2. Checks the array for the desired instance, returns if available
3. If an instance doesn't exist in the array, it creates one and puts
it in the array. It is uninitialized at this point.
4. * EXITS the synchronized block for descriptorFor *
5. Calls init() to fill in all the info of the class
5a. Synchronizes on a member variable "lock" and initializes data
Note: "lock" is only used in the init() method and accessor methods are
not synchronized
Thus, I believe that there's a situation in which a thread looks up and
uses an instance of an ObjectStreamClass while another thread is
initializing it.
When I change ObjectStreamClass to do the init() in the synchronized
block in my JDK 1.3.1_01 workspace, ECperf doesn't seem to have the same error.
Also, when putting in a Thread.sleep in the init() call, a simple test case shows that other threads can gain access to uninitialized instances with -1 for the SUID.
Note that the java.io.ObjectStreamClass always calls the init method, thus ensuring that all threads have initialized copies no matter what, even if multiple threads perform the init.
********************************************************************************
###@###.### 2001-09-28
fix verified ok
with build
j2sdk-1_4_0-beta3-bin-b81-solsparc-27_sep_2001
j2sdk-1_3_1_01-fcs-bin-solsparc-08_aug_2001
by code inspection for
com/sun/corba/se/internal/io/ObjectStreamClass.java
********************************************************************************
MARSHAL or IOException explaining that the repository IDs of the received and local versions of a class are different when unmarshaling in RMI-IIOP.
This bug is due to a race condition present in
com.sun.corba.se.internal.io.ObjectStreamClass
Details (based on com.sun.corba.se.internal.io.ObjectStreamClass):
ObjectStreamClass maintains a cache in a static array called descriptorFor. People get instances of ObjectStreamClass by calling the static lookup factory method.
This method does the following:
1. Synchronizes on the static descriptorFor array
2. Checks the array for the desired instance, returns if available
3. If an instance doesn't exist in the array, it creates one and puts
it in the array. It is uninitialized at this point.
4. * EXITS the synchronized block for descriptorFor *
5. Calls init() to fill in all the info of the class
5a. Synchronizes on a member variable "lock" and initializes data
Note: "lock" is only used in the init() method and accessor methods are
not synchronized
Thus, I believe that there's a situation in which a thread looks up and
uses an instance of an ObjectStreamClass while another thread is
initializing it.
When I change ObjectStreamClass to do the init() in the synchronized
block in my JDK 1.3.1_01 workspace, ECperf doesn't seem to have the same error.
Also, when putting in a Thread.sleep in the init() call, a simple test case shows that other threads can gain access to uninitialized instances with -1 for the SUID.
Note that the java.io.ObjectStreamClass always calls the init method, thus ensuring that all threads have initialized copies no matter what, even if multiple threads perform the init.
********************************************************************************
###@###.### 2001-09-28
fix verified ok
with build
j2sdk-1_4_0-beta3-bin-b81-solsparc-27_sep_2001
j2sdk-1_3_1_01-fcs-bin-solsparc-08_aug_2001
by code inspection for
com/sun/corba/se/internal/io/ObjectStreamClass.java
********************************************************************************
- backported by
-
JDK-2046053 Race condition leads to mismatched repIds (FFFFFFFFFFFFFFFF:FFFFFFFFFFFFFFFF)
- Closed
-
JDK-2046054 Race condition leads to mismatched repIds (FFFFFFFFFFFFFFFF:FFFFFFFFFFFFFFFF)
- Closed