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

ClassLoader.getResource and loadClass deadlock when signed jar is verified

    Details

    • Subcomponent:
    • CPU:
      generic, x86
    • OS:
      generic, windows_vista

      Backports

        Description

        FULL PRODUCT VERSION :
        java version "1.6.0_20"
        Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
        Java HotSpot(TM) Client VM (build 16.3-b01, mixed mode, sharing)

        ADDITIONAL OS VERSION INFORMATION :
        Microsoft Windows [Version 6.0.6002]

        EXTRA RELEVANT SYSTEM CONFIGURATION :
        ActivClient CAC x64 6.2.0.50

        -- LIBRARY VERSION --

        CSP Library:
        Name: accsp.dll
        Version: 5-1-0-20

        P11 Library:
        Name: acpkcs211.dll
        Version: 5-1-0-22

        BSI Library:
        Name: acbsi21.dll
        Version: 5-1-0-11

        PIV Library:
        Name: acpivapi.dll
        Version: 4-4-0-7


        A DESCRIPTION OF THE PROBLEM :
        An unsandboxed multithreaded swing client will deadlock on startup. At the point when the app deadlocks, the EDT is trying to execute "new Foo()", which results in ClassLoader.loadClass while the main thread is trying to locate a resource file on the local disk using Class.getResource. If the main thread triggers a jar verify of a signed jar (bsi21classes.jar) while the EDT is trying to load a class, the deadlock occurs. If all jars in the classpath are unsigned, like in the previous version of ActivClient, the deadlock does not occur.

        STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
        1. Use a classpath order = %programfiles%\ActivIdentity\ActivClient\bsi21classes.jar;%programfiles%\ActivIdentity\ActivClient\bsi21interf.jar;%programfiles%\ActivIdentity\ActivClient\acjsys.jar;app\unindexed unsigned.jars*;app\a folder with resources

        2. Create a unsigned unindex jar to load classes from.
        3. Create a folder with a file resource.
        4. Make one thread call loadClass while the another thread triggers a signed jar verify.

        EXPECTED VERSUS ACTUAL BEHAVIOR :
        EXPECTED -
        No deadlock.
        ACTUAL -
        Output is attached seperatly

        REPRODUCIBILITY :
        This bug can be reproduced often.

        CUSTOMER SUBMITTED WORKAROUND :
        1. Don't call Class.getResource until most of the classes have been loaded.
        2. Synch on the classloader prior to calling getResource.

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  valeriep Valerie Peng
                  Reporter:
                  ndcosta Nelson Dcosta
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  2 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:
                    Imported:
                    Indexed: