celix-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Broekhuis (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CELIX-219) Memory Leaks
Date Wed, 11 Feb 2015 13:45:12 GMT

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

Alexander Broekhuis commented on CELIX-219:

I've been working on those issues, to summarize:
- Fixed several small issues (see commits related to this issue).
- Updated framework destroy to close bundles and libraries. This results in the removal of
the modules in the resolver. This change also takes care of emptying the installedBundleMap,
so in the destroy the keys/values can be left untouched.

- With the call to bundle_close, modules are now removed. If the module list is empty, the
lists are destroyed/NULLed. Also updated the bundle to not add a module multiple times, which
would have prevented the list from even being empty.
- I can't detect any other leaks using Valgrind, but the Resolver is currently not an ADT
and very verbose to read/understand, so I've create an issue for refactoring/rewriting it.

- bundle_closeModules is called by bundle_close. This call takes care of removing the modules
from the resolver. Previously bundle_close was never called, as mentioned I've added this
to framework.
- I've removed isUsed, if it is needed later on we can always resurrect it from SVN.
- bundle_closeModules closes the modules, it does not destroy them. That is done in bundle_destroy,
where the list is also destroyed. Are you seeing any problems with this currently?

Not sure if I now missed something, if there are still some leaks, feel free to comment to
this issue (or open a new one).

> Memory Leaks
> ------------
>                 Key: CELIX-219
>                 URL: https://issues.apache.org/jira/browse/CELIX-219
>             Project: Celix
>          Issue Type: Bug
>            Reporter: Daniel Parker
>            Priority: Minor
> framework.c:
>    framework_create() allocates memory for logger, but framework_destroy does not free()
>    framework_destroy() when destroying framework->installedBundleMap should set the
second argument to true in order to free the memory allocated for the keys.
>    framework_destroy() should destroy the mutexes/conditions created by framework_create().
>    framework_loadLibrary() should clear the entire libraryPath string before using it.
>    fw_uninstallBundle() should only call fw_stopBundle() if the bundle is in the OSGI_FRAMEWORK_BUNDLE_ACTIVE
>    The proxy/endpoint bundles get uninstalled correctly, but the normal bundles do not
get uninstalled.  This might be resolved by letting framework_shutdown() call fw_uninstallBundle()
for every bundle (except for the system framework bundle) in the installedBundleMap after
it's done stopping all of the bundles.  Alternately, the bundles could be uninstalled in framework_destroy(),
but fw_uninstallBundle() (and bundle_uninstall() ) wouldn't work at this point because the
dispatcherThread would already have been canceled.
> bundle.c:
>    The function bundle_addModule() does not have a corresponding bundle_removeModule().
 This is because modules are added one at a time but removed all at once.  However, the code
which remove the modules in bundle_destroy() needs to call resolver_removeModule() in order
for this to work properly.
>    The function bundle_isUsed() looks incorrect/incomplete in how it uses module_getDependents().
 However, the function isn't actually used so it's probably easier to just remove it than
to try to fix it.
>    bundle_closeModules() looks like it should be calling module_destroy() rather than
module_setWires().  And it looks like it should call arrayList_clear(bundle->modules) when
it's done.
> resolver.c:
>    m_modules is created but never destroyed.  Perhaps it could be destroyed whenever
it's empty?
>    m_unresolvedServices/m_resolvedServices are never destroyed and none of the elements
added to them are ever destroyed either.  Perhaps each element should be destroyed if they
become empty and m_unresolvedServices/m_resolvedServices should be destroyed once it contains
no elements?

This message was sent by Atlassian JIRA

View raw message