[
https://issues.apache.org/jira/browse/FELIX-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Walker updated FELIX-3160:
------------------------------
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.
was:
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
> 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
> Reporter: Rob Walker
> Assignee: Rob Walker
> Priority: Minor
>
> 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
