Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

purge meta objects within the graveyard if the library is unassociated #200

Closed
wants to merge 1 commit into from
Closed

purge meta objects within the graveyard if the library is unassociated #200

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions src/class_loader_core.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 .

} else {
CONSOLE_BRIDGE_logDebug(
"class_loader.impl: "
Expand Down