purge meta objects within the graveyard if the library is unassociated #200
Conversation
Co-authored-by: shshlei <shshlei@hust.edu.cn> Signed-off-by: Chen Lihui <lihui.chen@sony.com>
|
@gbiggs @mjcarroll either of you, could you take a look at this? this is to address memory leak. |
iuhilnehc-ynos
changed the title
| @@ -538,6 +538,7 @@ void unloadLibrary(const std::string & library_path, ClassLoader * loader) | |||
|
|
|||
| library->unload_library(); | |||
| itr = open_libraries.erase(itr); | |||
| purgeGraveyardOfMetaobjects(library_path, loader, true); | |||
There was a problem hiding this comment.
While this definitely fixes the leak for me, I'll say that it I'm somewhat concerned about the impact of this. Just above, we are calling destroyMetaObjectsForLibrary, which may end up placing the meta-objects for this library into the graveyard. Then we are immediately purging them here. That begs the question: why put them into the graveyard at all?
Further, there is this comment in destroyMetaObjectsForLibrary:
// Insert into graveyard
// We remove the metaobject from its factory map, but we don't destroy it...instead it
// saved to a "graveyard" to the side.
// This is due to our static global variable initialization problem that causes factories
// to not be registered when a library is closed and then reopened.
// This is because it's truly not closed due to the use of global symbol binding i.e.
// calling dlopen with RTLD_GLOBAL instead of RTLD_LOCAL.
// We require using the former as the which is required to support RTTI
Which suggests that maybe we need to do additional testing about closing/reopening libraries with this? I'm honestly not sure, but I'm not too familiar with this repository. It would be great to have feedback from one of the maintainers @gbiggs or @mjcarroll .
|
Close in favor of #201 |
It seems that #196 is not updated as suggested by the maintainer for a few months. I would like to add @shshlei a
co-authorto create this PR to fix ros2/rcl#1009.If this is not the correct way, please feel free to close it.
Co-authored-by: shshlei shshlei@hust.edu.cn
Signed-off-by: Chen Lihui lihui.chen@sony.com