[
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
