Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4488137

Race condition leads to mismatched repIds (FFFFFFFFFFFFFFFF:FFFFFFFFFFFFFFFF)

    Details

    • Subcomponent:
    • Resolved In Build:
      01
    • CPU:
      generic, sparc
    • OS:
      generic
    • Verification:
      Verified

      Backports

        Description

        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

        ********************************************************************************



          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  eandersosunw Everett Anderson (Inactive)
                  Reporter:
                  eandersosunw Everett Anderson (Inactive)
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  0 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:
                    Imported:
                    Indexed: