Felix
  1. Felix
  2. FELIX-3160

NPE in BundleRevisionImpl.close() when uninstalling a bundle

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: framework-4.0.0
    • Fix Version/s: framework-4.2.0
    • Component/s: Framework
    • Labels:
      None

      Description

      There seems to be a case where m_content can be null when uninstalling a bundle, causing the following code to throw an NPE:

      synchronized void close()
      {
      try

      { resolve(null); }

      catch (Exception ex)

      { ((BundleImpl) m_bundle).getFramework().getLogger().log( Logger.LOG_ERROR, "Error releasing revision: " + ex.getMessage(), ex); }

      m_content.close();

      I've added a simple check for null around the close in my version to avoid the exception, which I'll check in.

      I'm not sure of the scenarios where this can legally be null at this point, and whether there's some nastier underlying circumstance that needs investigating. We see it under the following circumstances:

      • we register a listener that looks for framework STARTED
      • when triggered, this iterates all bundles and performs an uninstall on ones which we determine are zombies leftover from a previous run

      Aside from the fact we're calling uninstall from inside an event handling method, there doesn't anything else unusual about this code.

      1. Felix3160.zip
        23 kB
        Rob Walker
      2. Activator.java
        9 kB
        Rob Walker

        Activity

        Rob Walker created issue -
        Rob Walker made changes -
        Field Original Value New Value
        Description There seems to be a case where m_content can be null when uninstalling a bundle, causing the following code to throw an NPE:

            synchronized void close()
            {
                try
                {
                    resolve(null);
                }
                catch (Exception ex)
                {
                    ((BundleImpl) m_bundle).getFramework().getLogger().log(
                        Logger.LOG_ERROR, "Error releasing revision: " + ex.getMessage(), ex);
                }
                
               m_content.close();


        I've added a simple check for null around the close in my version to avoid the exception, which I'll check in.

        I'm not sure of the scenarios where this can legally be null at this point, and whether there's some nastier underlying circumstance that needs investigating. We see it under the following circumstances:

        * we register a listener that looks for framework STARTED
        * when triggered, this iterates all bundles and performs an uninstall on ones which we determine are zombies leftover from a previous run

        Aside from the fact we're calling uninstall from inside an event handling method, there doesn't anything else unusual about this code.



        clears the exception. I'll check this i
        There seems to be a case where m_content can be null when uninstalling a bundle, causing the following code to throw an NPE:

            synchronized void close()
            {
                try
                {
                    resolve(null);
                }
                catch (Exception ex)
                {
                    ((BundleImpl) m_bundle).getFramework().getLogger().log(
                        Logger.LOG_ERROR, "Error releasing revision: " + ex.getMessage(), ex);
                }
                
               m_content.close();


        I've added a simple check for null around the close in my version to avoid the exception, which I'll check in.

        I'm not sure of the scenarios where this can legally be null at this point, and whether there's some nastier underlying circumstance that needs investigating. We see it under the following circumstances:

        * we register a listener that looks for framework STARTED
        * when triggered, this iterates all bundles and performs an uninstall on ones which we determine are zombies leftover from a previous run

        Aside from the fact we're calling uninstall from inside an event handling method, there doesn't anything else unusual about this code.
        Rob Walker made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        Richard S. Hall made changes -
        Fix Version/s framework-4.2.0 [ 12317972 ]
        Affects Version/s framework-4.0.0 [ 12316287 ]
        Rob Walker made changes -
        Attachment Activator.java [ 12503365 ]
        Rob Walker made changes -
        Attachment Felix3160.zip [ 12505866 ]
        Richard S. Hall made changes -
        Status In Progress [ 3 ] Closed [ 6 ]
        Assignee Rob Walker [ walkerr ] Richard S. Hall [ rickhall ]
        Resolution Fixed [ 1 ]

          People

          • Assignee:
            Richard S. Hall
            Reporter:
            Rob Walker
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development