Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Date: Fri, 2 Dec 2011 10:05:39 +0000 (UTC)
From: "Rob Walker (Commented) (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Message-ID: 
 <296198669.34382.1322820339899.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1818737061.5007.1318426511815.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (FELIX-3160) NPE in BundleRevisionImpl.close()
 when uninstalling a bundle
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Rob Walker commented on FELIX-3160:
-----------------------------------

Well - I've only figured how to recreate it, not actually fix the underlying cause. Baby steps ;)

Have attached a ZIP with the worked example. Afraid it's a Windows BAT file, should be hard to alter for .SH though.

I've set it up so that only the custom bundles are present (including the original example). The felix standard bundles load from the SVN tree to save upload, and also make it easier to retest when fixed. Just alter the following env var to set where felix is rooted:

set FELIX_HOME=C:/mnt/MiscProjs/felix


First you need a cold run to get things going:

   >go clean

Initial bundles will load, then a few seconds later the gui plugin will get loaded (that's really the only purpose of my main.Main class now - to autoload this to make recreating less typing). My output trace looks as follows:

===
C:\mnt\tmp\Felix3160>go clean

C:\mnt\tmp\Felix3160>set EXAMPLE_HOME=C:\mnt\tmp\Felix3160\/.

C:\mnt\tmp\Felix3160>set FELIX_HOME=C:/mnt/MiscProjs/felix

C:\mnt\tmp\Felix3160>set CLEAN=none

C:\mnt\tmp\Felix3160>if "clean" == "clean" set CLEAN=onFirstInit

C:\mnt\tmp\Felix3160>"C:\Program Files (x86)\Java\jdk1.6.0_27\bin\java" -Dfelix.home=C:/mnt/MiscProjs/felix -Dexample.home="C:\mnt\t
mp\Felix3160\/."  -Dclean=onFirstInit -Dconfig="C:\mnt\tmp\Felix3160\/./conf/config.properties" -cp C:/mnt/MiscProjs/felix/main/targ
et/org.apache.felix.main-4.1.0-SNAPSHOT.jar;C:\mnt\tmp\Felix3160\/./lib/main.jar main.Main
initializeAdmin: org.apache.felix.framework.PackageAdminImpl@b8f82d
bundleChanged: watchdog [4]
-> bundleChanged: org.osgi.service.obr [5]
bundleChanged: org.osgi.service.obr [5]
bundleChanged: org.apache.felix.shell [6]
bundleChanged: org.apache.felix.shell.tui [1]
bundleChanged: org.apache.felix.shell.tui [1]
bundleChanged: org.apache.felix.shell.gui [2]
bundleChanged: org.apache.felix.shell.gui [2]
bundleChanged: org.apache.felix.framework [0]
bundleChanged: org.apache.felix.shell.gui.plugin [9]
bundleChanged: org.apache.felix.shell.gui.plugin [9]
bundleChanged: org.apache.felix.shell.gui.plugin [9]
===

At this stage Ctrl-C exit. The restart "warm"

>go

It seems to be the refreshPackages call that triggers the NPE - which as above, only happens if the auto uninstalled bundle had no exports

My output trace from the warm start:

===
C:\mnt\tmp\Felix3160>go

C:\mnt\tmp\Felix3160>set EXAMPLE_HOME=C:\mnt\tmp\Felix3160\/.

C:\mnt\tmp\Felix3160>set FELIX_HOME=C:/mnt/MiscProjs/felix

C:\mnt\tmp\Felix3160>set CLEAN=none

C:\mnt\tmp\Felix3160>if "" == "clean" set CLEAN=onFirstInit

C:\mnt\tmp\Felix3160>"C:\Program Files (x86)\Java\jdk1.6.0_27\bin\java" -Dfelix.home=C:/mnt/MiscProjs/felix -Dexample.home="C:\mnt\t
mp\Felix3160\/."  -Dclean=none -Dconfig="C:\mnt\tmp\Felix3160\/./conf/config.properties" -cp C:/mnt/MiscProjs/felix/main/target/org.
apache.felix.main-4.1.0-SNAPSHOT.jar;C:\mnt\tmp\Felix3160\/./lib/main.jar main.Main
initializeAdmin: org.apache.felix.framework.PackageAdminImpl@b8f82d
bundleChanged: watchdog [4]
bundleChanged: org.osgi.service.obr [5]
bundleChanged: org.osgi.service.obr [5]
bundleChanged: org.apache.felix.shell [6]
bundleChanged: org.apache.felix.shell.tui [1]
bundleChanged: org.apache.felix.shell.tui [1]
bundleChanged: org.apache.felix.shell.gui [2]
-> bundleChanged: org.apache.felix.shell.gui [2]
bundleChanged: org.apache.felix.framework [0]
Removing transient bundle: org.apache.felix.shell.gui.plugin [9]
bundleChanged: org.apache.felix.shell.gui.plugin [9]
bundleChanged: org.apache.felix.shell.gui.plugin [9]
refresh: org.apache.felix.shell.gui.plugin [9]
Framework error, bundle: org.apache.felix.shell.gui.plugin [9]
java.lang.NullPointerException
        at org.apache.felix.framework.BundleRevisionImpl.close(BundleRevisionImpl.java:639)
        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:4648)
        at org.apache.felix.framework.Felix.refreshPackages(Felix.java:3960)
        at org.apache.felix.framework.FrameworkWiringImpl.run(FrameworkWiringImpl.java:172)
        at java.lang.Thread.run(Thread.java:662)
===


> 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, Felix3160.zip
>
>
> 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