[
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.install.1="${bundle.root}/lib/ext/osgi.compendium.jar"
org.osgi.framework.startlevel.beginning=3
felix.auto.start.1="${bundle.root}/lib/ext/felix.log.jar"
felix.auto.start.2="${bundle.root}/lib/ext/httpjetty.jar" \
"${bundle.root}/lib/vt/watchdog.jar"
felix.auto.start.3="${bundle.root}/lib/ext/shell.jar" \
"${bundle.root}/lib/ext/shelltui.jar"
# we'll start this transient so we have something to clean up
test.bundle=file:c:/mnt/data/vtmp/lib/shell.gui.jar
===
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 jar:
C:\mnt\Data\runvt>vtmp
Removing transient bundle: org.apache.felix.shell.gui [7]
-> Framework error, bundle: org.apache.felix.shell.gui [7]
java.lang.NullPointerException
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()
{
try
{
resolve(null);
}
catch (Exception ex)
{
((BundleImpl) m_bundle).getFramework().getLogger().log(
Logger.LOG_ERROR, "Error releasing revision: " +
ex.getMessage(), ex);
}
//if (m_content != null)
//{
m_content.close();
//}
m_content = null;
for (int i = 0; (m_contentPath != null) && (i < m_contentPath.size());
i++)
{
m_contentPath.get(i).close();
}
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
