Uploaded image for project: 'JBoss JMX'
  1. JBoss JMX
  2. JBJMX-45

ConcurrentModificationException in UnifiedLoaderRepository3

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      SourceForge Submitter: stottos .
      The getResourceFromRepository method in
      UnifiedLoaderRepository3 does not synchronize access to
      the packagesMap and classLoaders fields, unlike all
      other accesses to those fields. As a result, if
      classes are being loaded at the same time as a resource
      is being looked up, a ConcurrentModificationException
      can be triggered.

      I have attached a proposed patch for this bug. The fix
      wraps the uses of packagesMap and classLoaders fields
      in the appropriate synchronized blocks. If the all of
      the class loaders need to be searched, a copy of the
      classLoaders field is made to avoid having to
      synchronize while performing the search. The existing
      code is inconsistent in the way it makes a copy of the
      classLoaders field: new HashSet(classLoaders) versus
      classLoaders.clone(). I arbitrarily chose the former,
      but whoever fixes the bug might consider making the
      code consistent one way or the other.

      I suspect that there is a second order synchronization
      problem in the processing of any HashSet retrieved from
      the packagesMap. The retrieved HashSet may be
      concurrently modified if a class loader is added or
      removed while the set is being processed. The
      modifications to the HashSet's in the packagesMap
      performed in the add/remove class loader code path are
      performed while holding the packagesMap lock, but the
      code in getResourceFromRepository and
      LoadMgr3.beginLoadTask, which retrieves a package set
      using the getPackageClassLoaders method, is
      unsynchronized. Unless there is some other lock that
      makes this a non-issue, I suspect that fixing the
      problem will require either making a copy of the
      HashSet or a moderate amount of code restructuring.

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                starksm64 Scott Stark
                Reporter:
                sourceforge-user SourceForge legacy user
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: