felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Walker (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-3160) NPE in BundleRevisionImpl.close() when uninstalling a bundle
Date Fri, 11 Nov 2011 11:26:51 GMT

    [ https://issues.apache.org/jira/browse/FELIX-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13148431#comment-13148431

Rob Walker commented on FELIX-3160:

Just as I was about to give up - I think I got it!

Adding 1 more bundle to the startup set seemed to trigger it (http)

This is the bundle set I load:




felix.auto.start.2="${bundle.root}/lib/ext/httpjetty.jar" \

felix.auto.start.3="${bundle.root}/lib/ext/shell.jar" \

# we'll start this transient so we have something to clean up

All the above bundles are standard from felix SVN, except my watchdog bundle. Will attach
source for that.

Steps I take are:

1 - start cold with the above bundle set

2 -  from shell TUI start the shell.gui.jar transient (my activator code looks for this symbolic
name on restart) e.g.

     -> install file:c:/mnt/data/vtmp/lib/shell.gui.jar
     Bundle ID: 7
     -> start -t 7

3 - kill the framework (I used Ctrl-C in fact, rather than clean shutdown)

4 - start the framework warm this time. NPE occurs after the auto uninstall of the shell GUI

     Removing transient bundle: org.apache.felix.shell.gui [7]
     -> Framework error, bundle: org.apache.felix.shell.gui [7]
             at org.apache.felix.framework.BundleRevisionImpl.close(BundleRevisionImpl.java:642)
             at org.apache.felix.framework.BundleImpl.closeRevisions(BundleImpl.java:154)
             at org.apache.felix.framework.BundleImpl.closeAndDelete(BundleImpl.java:138)
             at org.apache.felix.framework.Felix$RefreshHelper.refreshOrRemove(Felix.java:4640)
             at org.apache.felix.framework.Felix.refreshPackages(Felix.java:3952)
             at org.apache.felix.framework.FrameworkWiringImpl.run(FrameworkWiringImpl.java:172)
             at java.lang.Thread.run(Thread.java:662)


Remember to comment out the workaround checked in to SVN to ensure the NPE appears:

    synchronized void close()
        catch (Exception ex)
            ((BundleImpl) m_bundle).getFramework().getLogger().log(
                Logger.LOG_ERROR, "Error releasing revision: " + ex.getMessage(), ex);
        //if (m_content != null)
        m_content = null;
        for (int i = 0; (m_contentPath != null) && (i < m_contentPath.size());
        m_contentPath = null;

> NPE in BundleRevisionImpl.close() when uninstalling a bundle
> ------------------------------------------------------------
>                 Key: FELIX-3160
>                 URL: https://issues.apache.org/jira/browse/FELIX-3160
>             Project: Felix
>          Issue Type: Bug
>          Components: Framework
>    Affects Versions: framework-4.0.0
>            Reporter: Rob Walker
>            Assignee: Rob Walker
>            Priority: Minor
>             Fix For: framework-4.2.0
>         Attachments: Activator.java
> 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.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message